Any reasons to filter ARP packets?
Mikhail Zotov
I have read a number of docs devoted to ARP packets and haven't seen a
way they can do any harm to a machine (except for the case of arp
flooding). Are there any reasons one would like to filter ARP packets
other than just hiding a machine from (a part of) its LAN neighbours?
Thanks!
Mikhail
Tobias Klausmann
I've seen setups with completely static ARP entries and arp
filtering that drops everything from a certain interface.
That way, you can counter some of the problems of publicly
available network jacks.
Regards,
Tobias
PS: Of course, for a comprehensive solution in this case, more
needs to be done.
--
You don't need eyes to see, you need vision.
Moe Trin
<1143553434.5...@v46g2000cwv.googlegroups.com>, Mikhail Zotov wrote:
>I have read a number of docs devoted to ARP packets and haven't seen a
>way they can do any harm to a machine (except for the case of arp
>flooding).
There might be others, but it depends on your setup and your threat model.
>Are there any reasons one would like to filter ARP packets other than
>just hiding a machine from (a part of) its LAN neighbours?
ARP filtering would not hid the system by itself. On broadcast media
(coax, twisted pairs with hubs, wireless) all traffic is detectable
anyway. On switched media, the switch has to know all, even if ARP
is disabled, never mind filtered.
Packets on Ethernet style networks (includes wireless) are moved using
MAC addresses. Some O/S monitor traffic and complain if another host is
detected using "my" MAC address. Look up "ARP spoofing".
ARP is one of two methods used to translate between IP and MAC addresses.
On a static network, you can disable ARP by using hard-coded data (ethers
files), /sbin/arp -s, and /sbin/ifconfig -arp. This may or may not improve
your security, but is usually a pain in the a$$ to set up and maintain.
Hardware addresses (and IP itself) is only as secure as your control of
access to the network, though encryption helps quite a bit. If you are
concerned about attack mechanisms using ARP or hardware addresses, you
need to be looking at other problems as well.
Old guy
Ertugrul Soeylemez
Well, the ARP filter has a very good reason to be. It's ARP poisoning.
This is an attack, which allows you to redirect network traffic as you
like, if the network is not protected against it. This is the case,
when the hosts in the network use dynamic ARP tables.
Now whether you really need the ARP filter depends on the operating
systems used. Given you have operating systems, where static ARP
entries cannot be changed remotely (i.e. not Windows), there is no
reason for ARP filtering. If you don't use static ARP entries, then you
are going to need ARP anyway, so you can't filter it effectively. If
you do, then you don't need it at all.
However, if there is even a single Windows machine in the network, then
I strongly recommend setting up static ARP tables on that host and
filtering any ARP packets from it. Windows allows static ARP entries,
but they are only static in terms of they don't have any timeout and
they (should) survice reboots. They can be overridden remotely.
Unfortunately, Windows doesn't have any ARP filter.
In all cases, use static ARP tables, if possible, to prevent ARP
poisoning. This attack is worse than ARP flooding, because it allows
for MITM attacks easily. Several command line utilities are available
to take over SSH connections and the like.
A much better setup would be one, where you don't rely on consistent ARP
tables at all. For example, use key-based authentication, if possible.
This makes ARP poisoning useless, because there is no MITM attack
against key-based authentication protocols.
Regards.
Mikhail Zotov
Gentlemen, I am posting a reply to the post of my own because this is a
reply to all three posts of yours.
First of all, thank you for the enlightening answers.
Let me explain the motivation for my question. This will hopefully
clarify what I am worrying about.
My home Linux machine is connected to a big LAN, which consists of
hundreds and maybe even thousands machines. All machines have IP
addresses from the 10/8 pool. I am running a simple iptables firewall
on my machine but it is useless most of the time because there seems to
be very little threat from (mostly Windows) machines in the LAN.
Packets blocked by the firewall are, as a rule, just Windoops noise.
If I observe probes of different ports on my machine I just call the
ISP and the problem is solved.
At the same time, the network device is open for ARP packets since
filtering of ARP packets is not supported by netfilter. Thus I wanted
to understand whether ARP packets can be used to put anything to my
machine (say, spyware) or get anything from it or just get any type of
access to it. According to the docs I have found so far, this is
impossible because ARP packets don't have place for anything "useful".
By posting my question, I wanted to make sure that my understanding is
correct.
Thanks again for the replies!
Mikhail
Ertugrul Soeylemez
> My home Linux machine is connected to a big LAN, which consists of
> hundreds and maybe even thousands machines. All machines have IP
> addresses from the 10/8 pool. I am running a simple iptables firewall
> on my machine but it is useless most of the time because there seems
> to be very little threat from (mostly Windows) machines in the LAN.
> Packets blocked by the firewall are, as a rule, just Windoops noise.
> If I observe probes of different ports on my machine I just call the
> ISP and the problem is solved.
>
> At the same time, the network device is open for ARP packets since
> filtering of ARP packets is not supported by netfilter. Thus I wanted
> to understand whether ARP packets can be used to put anything to my
> machine (say, spyware) or get anything from it or just get any type of
> access to it. According to the docs I have found so far, this is
> impossible because ARP packets don't have place for anything "useful".
> By posting my question, I wanted to make sure that my understanding is
> correct.
Yes, this is correct. The ARP intentionally doesn't leave any space for
payloads in the packet. However, as every network packet, an ARP packet
has a 'size' field, which can well be set larger than the packet itself
really is. So, you _can_ transmit payload with ARP packets, but they
get just ignored (as long as there isn't some special purpose
application, or some classic network stack bug).
Now to the ARP itself. There are mainly two kinds of attacks via ARP.
They can be launched in every switched ethernet (very likely you are in
one of them). They are called ARP flooding and ARP poisoning.
ARP flooding: As you know, the ARP is used to resolve IP addresses into
MAC addresses. All network hosts and the switch itself keep track of an
internal ARP table containing such resolutions, which have already taken
place. The size of this internal table is limited. Most switches
switch to a hub-like mode, when it gets overflown. This allows an
attacker to easily intercept _any_ traffic in the network.
ARP poisoning: Essentially the goal of this attack is similar, but the
method is quite different. You can always send arbitrarily constructed
ARP packets, and other hosts in the network will honour them. So with
forged ARP packets, you can redirect network traffic to other machines
and let them act as routers. This allows the interception attack
mentioned above, too, but also a few other attacks. By redirecting
network traffic intended for the internet gateway to a non-existent
machine, you can isolate it completely, making internet access
impossible (for a short period of time, until the ARP entries expire).
You can also redirect traffic for other hosts to your machine, and then
act as a router to send them to the real destination.
The latter method allows an attack, which is called the 'man in the
middle' (MITM) attack. With this one, you can not only intercept
network traffic, but even manipulate it. As a funny attack, you could
intercept a chat session and also write forged messages for your victim,
without him noticing this. Now, there is a much more serious MITM
attack. If not set up properly (i.e. in the default configuration), you
can decrypt almost _any_ encrypted connection. Yes, this includes
SSH/SSL connections, so you can very well get access to remote machines
(via SSH) or steal credit card information (via SSL, e.g. via HTTPS).
In other words: The insecurity of the ARP protocol is a major threat in
every switched ethernet. You can overcome this problem by using static
ARP tables. If you use static ARP tables on your host, then outgoing
traffic cannot be intercepted or manipulated anymore. Incoming traffic
from a host using dynamic ARP tables, however, can be. And there is a
case, where static ARP tables are even not possible: When the hosts
have dynamic IP addresses.
There are two ways to defend yourself (but not others) against ARP
poisoning, so that _your_ traffic cannot be intercepted. Don't rely on
the expiration time of ARP entries. You could lower it. Luckily, when
an MITM attack gets out of synchronization (i.e. not _all_ packets get
caught by the attacker), then it is lost in most cases. This way, you
can force a desynchronization sooner or later, and detect the attack.
Secondly, add a static ARP entry for 'important' hosts like the router.
They are going to have static addresses in most cases.
The other way is not to use ARP and MAC addressing at all, effectively
turning your interface to a broadcast interface. That will increase
network traffic, and you can't defend yourself against interception with
this. But it makes an MITM attack impossible. You can turn MAC
addressing on and off, so I recommend doing this for the setup phase of
encrypted connections. After the connection is established, you can
return to normal behaviour.
Regards.
Mikhail Zotov
First, thank you for the comprehensive explanation of the subject. I
think, it can make a good article on securityfocus or a similar site. I
wonder why this topic isn't covered in any popular security HOWTO.
> Now to the ARP itself. There are mainly two kinds of attacks via ARP.
> They can be launched in every switched ethernet (very likely you are in
> one of them).
Yes, this is the case.
> They are called ARP flooding and ARP poisoning.
[ ARP poisoning: ]
> The latter method allows an attack, which is called the 'man in the
> middle' (MITM) attack. With this one, you can not only intercept
> network traffic, but even manipulate it. As a funny attack, you could
> intercept a chat session and also write forged messages for your victim,
> without him noticing this. Now, there is a much more serious MITM
> attack. If not set up properly (i.e. in the default configuration), you
> can decrypt almost _any_ encrypted connection. Yes, this includes
> SSH/SSL connections, so you can very well get access to remote machines
> (via SSH) or steal credit card information (via SSL, e.g. via HTTPS).
Does this mean in particular that the ISP can decrypt almost any
encrypted traffic of us, its clients?
> There are two ways to defend yourself (but not others) against ARP
> poisoning, so that _your_ traffic cannot be intercepted. Don't rely on
> the expiration time of ARP entries. You could lower it.
Do you mean a sysctl setting? I didn't find a suitable one.
> Secondly, add a static ARP entry for 'important' hosts like the router.
> They are going to have static addresses in most cases.
Thanks for the idea. Seems to be easy to implement (via arp and
/etc/ethers).
> The other way is not to use ARP and MAC addressing at all, effectively
> turning your interface to a broadcast interface.
I am afraid this is impossible in my case because the ISP relates IP
addresses of its client machines to their MAC addresses. In other
words, I expect I won't be able to use the connection if I turn off
MAC addressing. Anyway, it seems worth trying. :-)
Regards,
Mikhail
Newsbox
> Does this mean in particular that the ISP can decrypt almost any
> encrypted traffic of us, its clients?
Yes.
Ertugrul Soeylemez
> First, thank you for the comprehensive explanation of the subject. I
> think, it can make a good article on securityfocus or a similar
> site. I wonder why this topic isn't covered in any popular security
> HOWTO.
There are lots of good papers covering this topic. My favorite one can
be found at <http://www.arp-sk.org/>, including experimental command
line utilities for both ARP poisoning and MITM attacks. Unfortunately,
this site seems to be down at the moment. Maybe I will write some kind
of paper about that topic.
> > The latter method allows an attack, which is called the 'man in the
> > middle' (MITM) attack. With this one, you can not only intercept
> > network traffic, but even manipulate it. As a funny attack, you
> > could intercept a chat session and also write forged messages for
> > your victim, without him noticing this. Now, there is a much more
> > serious MITM attack. If not set up properly (i.e. in the default
> > configuration), you can decrypt almost _any_ encrypted connection.
> > Yes, this includes SSH/SSL connections, so you can very well get
> > access to remote machines (via SSH) or steal credit card information
> > (via SSL, e.g. via HTTPS).
>
> Does this mean in particular that the ISP can decrypt almost any
> encrypted traffic of us, its clients?
Exactly. But if your ISP did this more often, then sooner or later, you
were going to detect it, at least when comparing key fingerprints by
hand.
You can overcome that problem by using key-based authentication, where
no MITM attack is possible.
> > There are two ways to defend yourself (but not others) against ARP
> > poisoning, so that _your_ traffic cannot be intercepted. Don't rely
> > on the expiration time of ARP entries. You could lower it.
>
> Do you mean a sysctl setting? I didn't find a suitable one.
If there is no particular sysctl setting, then you might have to change
some headers in the kernel source. I have not done this myself, because
we have other means securing the network here.
> > The other way is not to use ARP and MAC addressing at all,
> > effectively turning your interface to a broadcast interface.
>
> I am afraid this is impossible in my case because the ISP relates IP
> addresses of its client machines to their MAC addresses. In other
> words, I expect I won't be able to use the connection if I turn off
> MAC addressing. Anyway, it seems worth trying. :-)
Maybe your ISP is going to do this via ARP. ;)
Regards.
Mikhail Zotov
> > HOWTO.
>
> There are lots of good papers covering this topic. My favorite one can
> be found at <http://www.arp-sk.org/>, including experimental command
> line utilities for both ARP poisoning and MITM attacks. Unfortunately,
> this site seems to be down at the moment. Maybe I will write some kind
> of paper about that topic.
It would be nice :-)
...
> > Does this mean in particular that the ISP can decrypt almost any
> > encrypted traffic of us, its clients?
>
> Exactly. But if your ISP did this more often, then sooner or later, you
> were going to detect it, at least when comparing key fingerprints by
> hand.
>
> You can overcome that problem by using key-based authentication, where
> no MITM attack is possible.
AFAIU, key-based authentication doesn't exist, e.g., for pop3s or
https, does it?
> > > The other way is not to use ARP and MAC addressing at all,
> > > effectively turning your interface to a broadcast interface.
> >
> > I am afraid this is impossible in my case because the ISP relates IP
> > addresses of its client machines to their MAC addresses. In other
> > words, I expect I won't be able to use the connection if I turn off
> > MAC addressing. Anyway, it seems worth trying. :-)
>
> Maybe your ISP is going to do this via ARP. ;)
I created /etc/ethers with MAC addresses of the gateway and a couple of
other local hosts and added
arp -f /etc/ethers -i $ext_device
ifconfig $ext_device -arp
to the script that starts the network interface. I have noticed no
difference in operation thus far. In particular, iptables is still
registering connection attempts. AFAIU, this means other hosts do have
a way to get to know the MAC address of my network device, right?
Thank you for the communication!
Regards,
Mikhail
Menno Duursma
> Ertugrul Soeylemez wrote:
>> You can overcome that problem by using key-based authentication, where
>> no MITM attack is possible.
>
> AFAIU, key-based authentication doesn't exist, e.g., for pop3s or
> https, does it?
SSL/TLS uses pub/priv certificates instead (for service integraty some
administrators could key the priv-cert for themselfs though) the
difference between a key and certificate here being identification
information is contained in the latter and not the former.
Thus for autentication a cert should be as good as any key (assuming the
same cipher was used to create them). The general problem is in getting
the public key/cert to clients (you) savely, as an ISP could manipulate
the exchange and MITM any session from there on.
So unless you got the keys/certs via some trusted means...
[...]
> I created /etc/ethers with MAC addresses of the gateway and a couple of
> other local hosts and added
>
> arp -f /etc/ethers -i $ext_device
> ifconfig $ext_device -arp
Maybe try also:
ip link set dev $ext_device arp off
> to the script that starts the network interface. I have noticed no
> difference in operation thus far. In particular, iptables is still
> registering connection attempts.
Idunno, but maybe clear the cache (using the 'arp' command).
Are they comming from the gateway MAC and out-site IP adresses? If so,
that might be expected (how else did you post here). Anyways, you could
try filtering using Netfilter like so:
# Load needed module
/sbin/modprobe ipt_mac
# Set default policy
/usr/sbin/iptables -P INPUT DROP
# Allow connections from Media Access Controllers we know about only
ETHERS=$(grep -v -e '^#' -e '^$' /etc/ethers |awk '{print $1}')
for MAC in $ETHERS; do
/usr/sbin/iptables -A INPUT -m mac --mac-source $MAC -j ACCEPT
done
(Not tested BTW).
> AFAIU, this means other hosts do have a way to get to know the MAC
> address of my network device, right?
I'd think so, i'd play arround some with 'arping' and 'tcpdump'. (Even
though i don't see security enhancement in disallowing others seeing you).
I think some off the sysctl settings are tweakable too, look for arp in:
/usr/src/linux/Documentation/networking/ip-sysctl.txt
HTH
--
-Menno.
Mikhail Zotov
The thread is becoming more and more interesting :-)
Menno Duursma wrote:
> On Sat, 01 Apr 2006 10:05:58 -0800, Mikhail Zotov wrote:
> > Ertugrul Soeylemez wrote:
>
> >> You can overcome that problem by using key-based authentication, where
> >> no MITM attack is possible.
> >
> > AFAIU, key-based authentication doesn't exist, e.g., for pop3s or
> > https, does it?
>
> SSL/TLS uses pub/priv certificates instead (for service integraty some
> administrators could key the priv-cert for themselfs though) the
> difference between a key and certificate here being identification
> information is contained in the latter and not the former.
..
> So unless you got the keys/certs via some trusted means...
Ah, I see. Thank you.
> [...]
> > I created /etc/ethers with MAC addresses of the gateway and a couple of
> > other local hosts and added
> >
> > arp -f /etc/ethers -i $ext_device
> > ifconfig $ext_device -arp
>
> Maybe try also:
> ip link set dev $ext_device arp off
>
> > to the script that starts the network interface. I have noticed no
> > difference in operation thus far. In particular, iptables is still
> > registering connection attempts.
>
> I dunno, but maybe clear the cache (using the 'arp' command).
>
> Are they comming from the gateway MAC and out-site IP adresses? If so,
> that might be expected (how else did you post here). Anyways, you could
They are (were) coming from other hosts in the LAN. None of them
is/was specified in /etc/ethers.
As for the the cache, I thought it is cleared once an interface is
down. At least,
# arp -a
doesn't show anything in this case. I was probably wrong. After I
rebooted the machine, I don't observe any connection attempts any more.
For already an hour now :-) Will be checking more.
> Anyways, you could
> try filtering using Netfilter like so:
>
> # Load needed module
> /sbin/modprobe ipt_mac
>
> # Set default policy
> /usr/sbin/iptables -P INPUT DROP
>
> # Allow connections from Media Access Controllers we know about only
> ETHERS=$(grep -v -e '^#' -e '^$' /etc/ethers |awk '{print $1}')
> for MAC in $ETHERS; do
> /usr/sbin/iptables -A INPUT -m mac --mac-source $MAC -j ACCEPT
> done
I like the idea, thank you. The rules should probably be modified
slightly because I am not going to ACCEPT all packets originating from
ISP's router. ;-) Anyway, this gonna be an interesting excercise. :-)
> > AFAIU, this means other hosts do have a way to get to know the MAC
> > address of my network device, right?
>
> I'd think so, i'd play arround some with 'arping' and 'tcpdump'. (Even
> though i don't see security enhancement in disallowing others seeing you).
>
> I think some off the sysctl settings are tweakable too, look for arp in:
> /usr/src/linux/Documentation/networking/ip-sysctl.txt
You can be sure I did :-)
Thanks for the reply and the ideas!
Regards,
Mikhail
Menno Duursma
> Menno Duursma wrote:
>> On Sat, 01 Apr 2006 10:05:58 -0800, Mikhail Zotov wrote:
>> > Ertugrul Soeylemez wrote:
[Snip: encription]
Userfriendly programs (to test this) would be:
http://monkey.org/~dugsong/dsniff/
http://ettercap.sourceforge.net/
Although a combination for small utilities is more flexible (and fun):
http://www.phenoelit.de/arpoc/
http://www.rtfm.com/ssldump/
Also maybe read this bugtraq post, (and Ethereal dump that traffic):
http://cert.uni-stuttgart.de/archive/bugtraq/2002/11/msg00261.html
> I like the idea, thank you. The rules should probably be modified
> slightly because I am not going to ACCEPT all packets originating from
> ISP's router. ;-) Anyway, this gonna be an interesting excercise. :-)
Maybe checkout the Arptables for some more filter options from here:
http://prdownloads.sourceforge.net/ebtables/arptables-v0.0.3-2.tar.gz
>> > AFAIU, this means other hosts do have a way to get to know the MAC
>> > address of my network device, right?
>>
>> I'd think so, i'd play arround some with 'arping' and 'tcpdump'. (Even
>> though i don't see security enhancement in disallowing others seeing you).
>>
>> I think some off the sysctl settings are tweakable too, look for arp in:
>> /usr/src/linux/Documentation/networking/ip-sysctl.txt
>
> You can be sure I did :-)
>
> Thanks for the reply and the ideas!
Sure thing. You may want to mess about the netwox in testing too:
http://www.laurentconstantin.com/en/netw/
Have fun.
--
-Menno.
Ertugrul Soeylemez
> > There are lots of good papers covering this topic. My favorite one
> > can be found at <http://www.arp-sk.org/>, including experimental
> > command line utilities for both ARP poisoning and MITM attacks.
> > Unfortunately, this site seems to be down at the moment. Maybe I
> > will write some kind of paper about that topic.
>
> It would be nice :-)
I've started working on one now. I hope, it's going to be useful.
> > You can overcome that problem by using key-based authentication,
> > where no MITM attack is possible.
>
> AFAIU, key-based authentication doesn't exist, e.g., for pop3s or
> https, does it?
Theoretically yes. The client and server programs have to support it as
well, though. The server always identifies itself with a certificate,
but only few clients have the ability to identify themselves, too.
Now, as Menno Duursma has pointed out, the big problem is the secure
delivery of the keys/certificates to and from the particular servers.
Unfortunately, many people (including server administrators) just don't
care.
> I created /etc/ethers with MAC addresses of the gateway and a couple
> of other local hosts and added
>
> arp -f /etc/ethers -i $ext_device
> ifconfig $ext_device -arp
>
> to the script that starts the network interface. I have noticed no
> difference in operation thus far. In particular, iptables is still
> registering connection attempts. AFAIU, this means other hosts do have
> a way to get to know the MAC address of my network device, right?
I guess, you got me wrong here. There is no problem about others
determining your MAC address, because they are going to do so anyway, as
long as you don't want to broadcast all packets to all hosts in the
network. I meant, secure your communications properly, instead of
relying on ARP filtering. In a network of the size of the one you're
part of, it would be silly to filter out ARP packets anyway.
Just add static ARP entries for 'important' hosts, like the router. By
this, you can defend against MITM attacks for packets from you to the
router (but not the other way), and sometimes this speeds up
communication. But you don't gain any further security; especially you
cannot defend against sniffing in a switched ethernet. The attacker
always has the ability to do ARP flooding, effectively turning the
switch into a broadcast device. There is nothing you could do about
that.
Regards.
Mikhail Zotov
> "Mikhail Zotov" <mux...@lenta.ru> (06-04-01 10:05:58):
>
> > > There are lots of good papers covering this topic. My favorite one
> > > Unfortunately, this site seems to be down at the moment. Maybe I
> > > will write some kind of paper about that topic.
> >
> > It would be nice :-)
>
> I've started working on one now. I hope, it's going to be useful.
Great. I know a web-zine that will undoubtedly be glad to publish your
article:
It's next issue is in work right now :-)
> > > You can overcome that problem by using key-based authentication,
> > > where no MITM attack is possible.
> >
> > AFAIU, key-based authentication doesn't exist, e.g., for pop3s or
> > https, does it?
>
> Theoretically yes. The client and server programs have to support it as
> well, though. The server always identifies itself with a certificate,
> but only few clients have the ability to identify themselves, too.
Ah, I see.
> > I created /etc/ethers with MAC addresses of the gateway and a couple
> > of other local hosts and added
> >
> > arp -f /etc/ethers -i $ext_device
> > ifconfig $ext_device -arp
> >
> > to the script that starts the network interface. I have noticed no
> > difference in operation thus far. In particular, iptables is still
> > registering connection attempts. AFAIU, this means other hosts do have
> > a way to get to know the MAC address of my network device, right?
>
> I guess, you got me wrong here. There is no problem about others
> determining your MAC address, because they are going to do so anyway, as
> long as you don't want to broadcast all packets to all hosts in the
> network.
I've been observing further how these settings influence operation and
found that "ifconfig device -arp" seems to disable replies about the
MAC address of the network device. With this setting, I do only
observe probes originating from a couple of hosts that are likely to
belong to the ISP. As a drawback, my friends have lost the possibility
to connect to my machine. Their machines are running windoops and I
don't know how to tell windoops about the MAC address of my machine. No
other problems with operation are observed thus far.
> Just add static ARP entries for 'important' hosts, like the router.
Yes, I did this. Put them in /etc/ethers. Still I'm going to try
arpfilter as suggested by Menno Duursma. It seems arpfilter can solve
the problem with connections originating from a few "friendly" hosts.
> By this, you can defend against MITM attacks for packets from you to the
> router (but not the other way), and sometimes this speeds up
> communication. But you don't gain any further security; especially you
> cannot defend against sniffing in a switched ethernet. The attacker
> always has the ability to do ARP flooding, effectively turning the
> switch into a broadcast device. There is nothing you could do about
> that.
Thus one can sniff traffic of whole districts with hundreds of thousand
people living there. :-(
Thank you for the communication!
Mikhail
Newsbox
> Ertugrul Soeylemez wrote:
>> "Mikhail Zotov" <mux...@lenta.ru> (06-04-01 10:05:58):
>>[...]
> Thank you for the communication!
>
> Mikhail
He did you right.
Smart, friendly, informative man.
You should archive this thread, not just for its content, but as an
premier example of what what a helpful, knowledgeable thread should look
like.
What a nice man, with a strange-sounding (to [parochial] me) name to have
given such good information. And you, too Mikhail Zotov asked highly
intelligent questions and understood answers so well.
As a "low-level" protocol, ARP will always be important to security. As
more areas (did I recently see Macedonia [name?] and areas of the NW USA
in the news?) try to adopt wide area wireless access, these exact issues
will become even more important to thousands and millions of users.
You both did well. I enjoyed reading your posts. I wish you both well.
I hope to read some more from you. Both.
Thanks
Write some more if you choose. :)
Ertugrul Soeylemez
> > I've started working on one now. I hope, it's going to be useful.
>
> Great. I know a web-zine that will undoubtedly be glad to publish
> your article:
>
> http://slackworld.berlios.de/
>
> It's next issue is in work right now :-)
Great information. Thank you. =)
> > I guess, you got me wrong here. There is no problem about others
> > determining your MAC address, because they are going to do so
> > anyway, as long as you don't want to broadcast all packets to all
> > hosts in the network.
>
> I've been observing further how these settings influence operation and
> found that "ifconfig device -arp" seems to disable replies about the
> MAC address of the network device. With this setting, I do only
> observe probes originating from a couple of hosts that are likely to
> belong to the ISP. As a drawback, my friends have lost the
> possibility to connect to my machine. Their machines are running
> windoops and I don't know how to tell windoops about the MAC address
> of my machine. No other problems with operation are observed thus far.
I would just leave all ARP replies enabled. You still can add static
ARP entries for your friends, but there is really no need to disable ARP
replies for other machines, unless you would like to completely suppress
communication between you and those hosts. But even then, there are
much better means of filtering, because ARP filtering cannot prevent
communication. It is easy for someone to get to your MAC address.
The very big problem about Windows users is that they effectively cannot
use static ARP entries. On Windows, a 'static' entry is static in terms
of surviving a reboot. You can still override it with forged ARP
replies to that machine. This is something, I have already tested in a
medium-scale office network. The attack works against every NT version
of Windows (NT, 2000, XP, 2003). I didn't have the opportunity to test
it against 95-based Windows versions (95, 98, ME).
So I have to repeat: Forget ARP filtering; secure your connections
otherwise, using cryptographic techniques. To prevent sniffing, you
need encryption. To prevent MITM attacks (which include sniffing), you
need proper authentication (i.e. key/certificate-based). In other
words: You need both. Personally I don't use certificates, because
they are effectively the same as keys, but unlike keys they include
identity information. There is nothing bad about that, but using keys
is simpler, and more widely supported (example: SSH cannot handle
certificates).
> > Just add static ARP entries for 'important' hosts, like the router.
>
> Yes, I did this. Put them in /etc/ethers. Still I'm going to try
> arpfilter as suggested by Menno Duursma. It seems arpfilter can solve
> the problem with connections originating from a few "friendly" hosts.
If it works for you, then it's good and might provide a further layer of
security by obscurity, making some attacks harder, though not
impossible. But please remember the above fact that in Windows, there
are no 'static' ARP entries. An attacker is always able to be the MITM
(man in the middle) for one side of the communication. You are going to
use cryptography anyway, making the arpfilter useless.
> > By this, you can defend against MITM attacks for packets from you to
> > the router (but not the other way), and sometimes this speeds up
> > communication. But you don't gain any further security; especially
> > you cannot defend against sniffing in a switched ethernet. The
> > attacker always has the ability to do ARP flooding, effectively
> > turning the switch into a broadcast device. There is nothing you
> > could do about that.
>
> Thus one can sniff traffic of whole districts with hundreds of
> thousand people living there. :-(
As long as they are directly connected by some kind of network. This is
a very old issue. Virtually anyone sitting in front of the
administration panel of an internet router can sniff all traffic going
through it. Again, this is old.
The very big problem about switched ethernet networks is the way hosts
distribute their MAC addresses. This makes one further and much more
dangerous attack possible: the MITM attack. That goes beyond sniffing
and allows to even break and intercept encrypted connections, and/or
inject forged packets into them.
The only way to defend against the MITM is key- or cert-based
authentication. Just to encrypt everything is not enough. And you need
some secure channel to distribute your key. It's best to meet your
friends personally and give them a floppy disk. Do not distribute your
key via internet, because the MITM is waiting there. ;)
Regards.
Ertugrul Soeylemez
> He did you right.
> Smart, friendly, informative man.
>
> You should archive this thread, not just for its content, but as an
> premier example of what what a helpful, knowledgeable thread should look
> like.
>
> What a nice man, with a strange-sounding (to [parochial] me) name to
> have given such good information. And you, too Mikhail Zotov asked
> highly intelligent questions and understood answers so well.
I guess, you mean me. I live in Germany, but the name is Turkish. I
don't like it, though. =)
> As a "low-level" protocol, ARP will always be important to security.
> As more areas (did I recently see Macedonia [name?] and areas of the
> NW USA in the news?) try to adopt wide area wireless access, these
> exact issues will become even more important to thousands and millions
> of users.
Proper understanding about everything you use has always been important.
It is no computer technology or networking issue. To use a saw properly
you need to understand, how and why it works. Unfortunately, that's
something most people miss.
> You both did well. I enjoyed reading your posts. I wish you both
> well. I hope to read some more from you. Both.
Thank you. On the other hand, I hope the informations were useful to
everyone, not only to Mikhail. One reason for me to switch from forums
to the Usenet was that it's much older and there are much less trolls,
as well as much more knowledgable people.
Regards.
Menno Duursma
> "Mikhail Zotov" <mux...@lenta.ru> (06-04-03 23:21:49):
> The very big problem about Windows users is that they effectively cannot
> use static ARP entries. On Windows, a 'static' entry is static in terms
> of surviving a reboot.
No its not, its 'static' in that it doesn't time-out.
> You can still override it with forged ARP replies to that machine. This
> is something, I have already tested in a medium-scale office network.
> The attack works against every NT version of Windows (NT, 2000, XP,
> 2003).
Right... Make that every NT version of MS-Windows up until XP/2003 ? :
http://seclists.org/lists/vuln-dev/2003/Feb/0032.html
> I didn't have the opportunity to test it against 95-based Windows
> versions (95, 98, ME).
Neither did i (or care to), presumably they acts as NT4 though.
> So I have to repeat: Forget ARP filtering; secure your connections
> otherwise, using cryptographic techniques.
I'd say: don't put all your eggs in one bucket...
(It sure would be a _great_ improvement if providers DNSSEC thier zones.)
> To prevent sniffing, you need encryption. To prevent MITM attacks
> (which include sniffing), you need proper authentication (i.e.
> key/certificate-based).
No to prevent MITM, you just need to ensure connection integrity. To make
sniffing ineffective use encryption. (Autentication is basically just
identification integrity checking).
> In other words: You need both. Personally I don't use certificates,
> because they are effectively the same as keys, but unlike keys they
> include identity information. There is nothing bad about that, but
> using keys is simpler, and more widely supported
I'd think this the other way around (think: HTTPS, IMAPS, FTPS, etc.)
> (example: SSH cannot handle certificates).
Sure it can. Probably you mean the OpenSSH implementation doesn't ship
with support... Well, it can be patched with that:
http://roumenpetrov.info/openssh/
>> > Just add static ARP entries for 'important' hosts, like the router.
>>
>> Yes, I did this. Put them in /etc/ethers. Still I'm going to try
>> arpfilter as suggested by Menno Duursma. It seems arpfilter can solve
>> the problem with connections originating from a few "friendly" hosts.
>
> If it works for you, then it's good and might provide a further layer of
> security by obscurity, making some attacks harder, though not impossible.
???
[...]
> Just to encrypt everything is not enough. And you need some secure
> channel to distribute your key. It's best to meet your friends
> personally and give them a floppy disk. Do not distribute your key via
> internet, because the MITM is waiting there. ;)
IME this utterly sucks when traveling (what makes SSH so usefull is the
'access your boxen from the road' option). Now password autentication
though can be farly secure whist utilizing something like Kerberos.
(However one may consider it overkill to configure a KDC for but a few
Telnet/SSH sessions).
SRP might be a rather nice solution to this though:
http://srp.stanford.edu/
Only (free) SSH server that i know supports it is LSH (v2.0.2):
http://www.lysator.liu.se/~nisse/archive/
--
-Menno.
Ertugrul Soeylemez
> > The very big problem about Windows users is that they effectively
> > cannot use static ARP entries. On Windows, a 'static' entry is
> > static in terms of surviving a reboot.
>
> No its not, its 'static' in that it doesn't time-out.
They also did survive reboots, at least on Win2003.
> > You can still override it with forged ARP replies to that machine.
> > This is something, I have already tested in a medium-scale office
> > network. The attack works against every NT version of Windows (NT,
> > 2000, XP, 2003).
>
> Right... Make that every NT version of MS-Windows up until XP/2003 ? :
> http://seclists.org/lists/vuln-dev/2003/Feb/0032.html
My memory might be wrong, but as far as I remember, it worked against
WinXP as well. I can say for sure, that it works against Win2003 and
Win2000.
> > I didn't have the opportunity to test it against 95-based Windows
> > versions (95, 98, ME).
>
> Neither did i (or care to), presumably they acts as NT4 though.
I wouldn't be surprised, if they used some proprietary protocol for MAC
address lookup. =)
> > So I have to repeat: Forget ARP filtering; secure your connections
> > otherwise, using cryptographic techniques.
>
> I'd say: don't put all your eggs in one bucket...
> (It sure would be a _great_ improvement if providers DNSSEC thier
> zones.)
Well, every communication is subject to a number of attacks. From
(properly) encrypted connections I can say that bruteforce is the best
attack available for now. That might change for a particular cipher,
but then you can just switch to another one.
> > To prevent sniffing, you need encryption. To prevent MITM attacks
> > (which include sniffing), you need proper authentication (i.e.
> > key/certificate-based).
>
> No to prevent MITM, you just need to ensure connection integrity. To
> make sniffing ineffective use encryption. (Autentication is basically
> just identification integrity checking).
You cannot ensure connection integrity in networks, unless you have
complete physical control over them, which I assume isn't the case for
Mikhail. Key-based authentication makes MITM attacks effectively
impossible, as long as the keys were distributed securely.
> > In other words: You need both. Personally I don't use
> > certificates, because they are effectively the same as keys, but
> > unlike keys they include identity information. There is nothing bad
> > about that, but using keys is simpler, and more widely supported
>
> I'd think this the other way around (think: HTTPS, IMAPS, FTPS, etc.)
Do you have (cryptographic) client-authentication in HTTPS or IMAPS?
How many people do use SFTP? I'm talking about protocols, where
client-authentication is realistic.
> > (example: SSH cannot handle certificates).
>
> Sure it can. Probably you mean the OpenSSH implementation doesn't ship
> with support... Well, it can be patched with that:
> http://roumenpetrov.info/openssh/
Oh well, yes. I thought, at least the libraries were full-featured. I
was wrong. =)
> >> > Just add static ARP entries for 'important' hosts, like the
> >> > router.
> >>
> >> Yes, I did this. Put them in /etc/ethers. Still I'm going to try
> >> arpfilter as suggested by Menno Duursma. It seems arpfilter can
> >> solve the problem with connections originating from a few
> >> "friendly" hosts.
> >
> > If it works for you, then it's good and might provide a further
> > layer of security by obscurity, making some attacks harder, though
> > not impossible.
>
> ???
What I meant was that ARP filtering is just not enough to secure
communications.
> > Just to encrypt everything is not enough. And you need some secure
> > channel to distribute your key. It's best to meet your friends
> > personally and give them a floppy disk. Do not distribute your key
> > via internet, because the MITM is waiting there. ;)
>
> IME this utterly sucks when traveling (what makes SSH so usefull is
> the 'access your boxen from the road' option). Now password
> autentication though can be farly secure whist utilizing something
> like Kerberos. (However one may consider it overkill to configure a
> KDC for but a few Telnet/SSH sessions).
My opinion is that Kerberos is harder to configure than key-based
authentication. But to be honest, I have not tried it myself, but just
read about it. Key auth is enabled by default anyway, you just need to
create a key, make it authorized and take it with you.
Regards.
Mikhail Zotov
I am sorry for the huge delay with the reply. I've been very busy at
work, had no time to play Linux.
Menno Duursma wrote:
> Userfriendly programs (to test this) would be:
> http://monkey.org/~dugsong/dsniff/
> http://ettercap.sourceforge.net/
>
> Although a combination for small utilities is more flexible (and fun):
> http://www.phenoelit.de/arpoc/
> http://www.rtfm.com/ssldump/
Thank you for the links. They are impressing and ... slightly
depressing.
> Maybe checkout the Arptables for some more filter options from here:
> http://prdownloads.sourceforge.net/ebtables/arptables-v0.0.3-2.tar.gz
Thank you. I plan to try arptables this weekend.
> Sure thing. You may want to mess about the netwox in testing too:
> http://www.laurentconstantin.com/en/netw/
The only thing I need to try all these tools is time. I wonder how
many lives have you spent to get to know about all these programs. :-)
>
> Have fun.
>
Sure, you too.
:-)
--
Mikhail
Mikhail Zotov
> On Mon, 03 Apr 2006 23:21:49 -0700, Mikhail Zotov wrote:
>
> > Ertugrul Soeylemez wrote:
> >> "Mikhail Zotov" <mux...@lenta.ru> (06-04-01 10:05:58):
> >>[...]
> > Thank you for the communication!
> >
> > Mikhail
>
> He did you right.
> Smart, friendly, informative man.
Definitely YES.
> You should archive this thread, not just for its content, but as an
> premier example of what what a helpful, knowledgeable thread should look
> like.
Yes, I did. I plan to link it from our web-zine.
> What a nice man, with a strange-sounding (to [parochial] me) name to have
> given such good information. And you, too Mikhail Zotov asked highly
> intelligent questions and understood answers so well.
Thank you for the kind words.
> Write some more if you choose. :)
I need time to check the ideas and try the tools suggested by Menno
Duursma and Ertugrul Soeylemez. Otherwise I'll become a troll. :-)
Meanwhile, I can say having a fast connection at home is an eye-opening
experience for a person who (like me) has a little idea about the
fundamentals of IP networking.
Thank you for the stimulating post!
--
Mikhail
Mikhail Zotov
> > your article:
> >
> > http://slackworld.berlios.de/
> >
> > It's next issue is in work right now :-)
>
> Great information. Thank you. =)
You can find the contact address at the bottom of this page:
http://slackworld.berlios.de/links.html
> I would just leave all ARP replies enabled.
...
> It is easy for someone to get to your MAC address.
Hm. How can one get my MAC address if I enable the device with
"ifconfig $device -arp"?
> The only way to defend against the MITM is key- or cert-based
> authentication. Just to encrypt everything is not enough. And you need
> some secure channel to distribute your key. It's best to meet your
> friends personally and give them a floppy disk. Do not distribute your
> key via internet, because the MITM is waiting there. ;)
I am afraid I don't fully understand the point. Do you mean encryption
in the sense of the GNU Privacy Guard? IIRC, one of the good things
about it is that one does not have to worry about the way the public
part of his/her authentication key is distributed.
Thanks again for the very interesting communication.
Regards,
Mikhail
Newsbox
[...]
>
>> The only way to defend against the MITM is key- or cert-based
>> authentication. Just to encrypt everything is not enough. And you need
>> some secure channel to distribute your key. It's best to meet your
>> friends personally and give them a floppy disk. Do not distribute your
>> key via internet, because the MITM is waiting there. ;)
>
> I am afraid I don't fully understand the point. Do you mean encryption
> in the sense of the GNU Privacy Guard? IIRC, one of the good things
> about it is that one does not have to worry about the way the public
> part of his/her authentication key is distributed.
I am not the expert but maybe I can contribute my user-level
understanding. MITM is generally more likely on cable and wireless than
on completely "hard-wired" direct networks, but can occur as long as there
is even one node in the path that is not under your own direct control.
That is essentially all external communications.
The MITM can receive, send and alter anything you exchange with the remote
host. So if you are counting on encryption to protect your communication
across a public network, the _only_ secure method of key exchange is to
put your key on physical media (floppy, CD, memory stick, etc) and
personally place it in the hand of your correspondent. Anything less will
not protect you from MITM.
That is not to say that on-the-fly key negotiated encryption does not have
value, but just that it will not protect against MITM, at all.
Ertugrul Soeylemez
> You can find the contact address at the bottom of this page:
> http://slackworld.berlios.de/links.html
Again, thank you. But it will take some time to write it. Maybe two or
three weeks, as I get time to work on it.
> > I would just leave all ARP replies enabled.
> ...
> > It is easy for someone to get to your MAC address.
>
> Hm. How can one get my MAC address if I enable the device with
> "ifconfig $device -arp"?
You need to send your MAC address with each packet, otherwise other
hosts in the network are forced to reply to you via broadcast. Your
operating system does not want this, and thus sends your MAC address.
Certainly there are ways to disable that, but that's something you won't
want to do.
So getting your MAC address is as simple as sniffing. And we have seen
that it's possible in all cases.
> > The only way to defend against the MITM is key- or cert-based
> > authentication. Just to encrypt everything is not enough. And you
> > need some secure channel to distribute your key. It's best to meet
> > your friends personally and give them a floppy disk. Do not
> > distribute your key via internet, because the MITM is waiting there.
> > ;)
>
> I am afraid I don't fully understand the point. Do you mean
> encryption in the sense of the GNU Privacy Guard? IIRC, one of the
> good things about it is that one does not have to worry about the way
> the public part of his/her authentication key is distributed.
The GnuPG is a collective, universal program for encryption, signatures
and key management. It does its best to provide message privacy,
authenticity and integrity, but a few things have to be taken care of by
the user. This includes key distribution and trust. For example, GnuPG
does not guarantee that the key-server you use is fully trustful. A
malicious key-server administrator can do MITM attacks easily by
replacing keys. Another MITM might sit between you and the key-server.
And GnuPG is just one example. This holds for all asymmetric
cryptographic programs out there. You must distribute your key over
some secure channel, preferably handing it out on a floppy disk, USB
stick or the like. You get the point.
Regards.
Ertugrul Soeylemez
> I am not the expert but maybe I can contribute my user-level
> understanding. MITM is generally more likely on cable and wireless
> than on completely "hard-wired" direct networks, but can occur as long
> as there is even one node in the path that is not under your own
> direct control. That is essentially all external communications.
Theoretically this would be totally correct. So let's assume Alice
(person A) and Bob (person B) are communicating over a network. As long
as they have a direct connection, no MITM or sniffing attacks would be
possible. But unfortunately that's rather seldom. In the real world,
there are routers and other hosts between Alice and Bob. Every person
with access to those hosts could intercept the commnuication. Let's
call this person Eve (evasdropper). She cannot launch MITM attacks, but
just intercept. Encryption is appropriate here.
But now let's assume the worst case (which is most likely). Mallory
(the man in the middle), some user between Alice and Bob, is responsible
for delivery of packets between the two. He cannot only intercept the
communication, but also mangle it. He can freely inject forged packets
without Alice and Bob even noticing that. So far for the terminology.
Now to the 'hard-wired' direct networks. The big problem here is that
modern networks of this kind (e.g. ethernets) are switched networks
(i.e. direct peer-to-peer communication instead of broadcasts). Now
every single person in that network can act as Mallory, while in other
kinds of networks only certain people could do that.
> The MITM can receive, send and alter anything you exchange with the
> remote host. So if you are counting on encryption to protect your
> communication across a public network, the _only_ secure method of key
> exchange is to put your key on physical media (floppy, CD, memory
> stick, etc) and personally place it in the hand of your correspondent.
> Anything less will not protect you from MITM.
That's right. To throw some light over the MITM attack, I will present
a very realistic MITM scenario:
As above, Alice and Bob are communicating. Both have a private/public
key pair. Alice's private key is X and her public key is A. Bob's
private key is Y and his public key is B. Mallory has full control over
the channel between Alice and Bob. He has its own key pair, M being
his private key, and F is public key.
When Alice sends her public key A to Bob, Mallory replaces it with F, so
Bob actually receives F instead of A. Bob sends his public key to
Alice, which again gets replaced by F. Neither Alice nor Bob notice the
forgery. So now Mallory has A, B, M and F.
Alice wants to encrypt a message to Bob. But as she did not receive B,
but F instead, she encrypts it with F. Mallory captures that packet on
its way and decrypts it, thus being able to read its contents. Because
he also has B, he encrypts it with that key and forwards it to Bob. Bob
receives a valid message encrypted with his public key B, so he can
decrypt it using the corresponding private key Y. This means, he does
not notice anything weird. And Mallory can not only intercept the
communication. He can also inject his own packets, because he knows the
public keys of both Alice and Bob.
Now Alice and Bob cannot sign their keys, when sending them. Let's
assume, Alice signs her public key A with her private key X, sending the
signed packet X(A) to Bob. Mallory receives that signed key, stores A
and sends Bob a signed version of his own key, M(F). Bob verifies the
key to be correct. They cannot use hashing algorithms, because Mallory
can easily replace them, too.
By the current state of things, Mallory cannot be defeated, unless there
is some secure channel (e.g. handing out keys personally). Anyway,
methods are known to detect MITM attacks reliably. One of the methods
is to use the so-called interlock protocol. But now we are getting
beyond the scope.
> That is not to say that on-the-fly key negotiated encryption does not have
> value, but just that it will not protect against MITM, at all.
Exactly. Encryption not enough, unless you make sure that traffic
interception is the best network-oriented attack.
Regards.
Mikhail Zotov
> "Mikhail Zotov" <mux...@lenta.ru> (06-04-06 13:29:41):
>
> > You can find the contact address at the bottom of this page:
> > http://slackworld.berlios.de/links.html
>
> Again, thank you. But it will take some time to write it. Maybe two or
> three weeks, as I get time to work on it.
This is perfectly fine. The issue won't be ready sooner than in two or
three weeks.
> > > I would just leave all ARP replies enabled.
> > ...
> > > It is easy for someone to get to your MAC address.
> >
> > Hm. How can one get my MAC address if I enable the device with
> > "ifconfig $device -arp"?
>
> You need to send your MAC address with each packet, otherwise other
> hosts in the network are forced to reply to you via broadcast. Your
> operating system does not want this, and thus sends your MAC address.
> Certainly there are ways to disable that, but that's something you won't
> want to do.
It seems I cannot disable "broadcast" and/or "allmulti". Regardless of
whether I use "-arp" or not, ifconfig returns "Warning: Interface eth0
still in BROADCAST(ALLMULTI) mode."
> So getting your MAC address is as simple as sniffing. And we have seen
> that it's possible in all cases.
Perhaps, this is even easier. I have disabled "arp" on eth0, and the
log has been empty for some time. Then, records about new connection
attempts appeared. I am not quite sure about output of tcpdump but it
seems information about MAC addresses is provided by the router. Thus,
sniffing is not needed. Just ask the router. ;-)
[GnuPG]
Thank you for the explanation. I think I need to read their docs once
again.
Regards,
Mikhail
Ertugrul Soeylemez
> > > Hm. How can one get my MAC address if I enable the device with
> > > "ifconfig $device -arp"?
> >
> > You need to send your MAC address with each packet, otherwise other
> > hosts in the network are forced to reply to you via broadcast. Your
> > operating system does not want this, and thus sends your MAC
> > address. Certainly there are ways to disable that, but that's
> > something you won't want to do.
>
> It seems I cannot disable "broadcast" and/or "allmulti". Regardless of
> whether I use "-arp" or not, ifconfig returns "Warning: Interface eth0
> still in BROADCAST(ALLMULTI) mode."
I don't know, because I have never bothered to do so. My connections
are encrypted and authentic. =)
> > So getting your MAC address is as simple as sniffing. And we have
> > seen that it's possible in all cases.
>
> Perhaps, this is even easier. I have disabled "arp" on eth0, and the
> log has been empty for some time. Then, records about new connection
> attempts appeared. I am not quite sure about output of tcpdump but it
> seems information about MAC addresses is provided by the router. Thus,
> sniffing is not needed. Just ask the router. ;-)
Yes, as soon as the router gets its hands on your MAC address, it saves
that relation in an internal list. To prevent broadcasting it needs to
know, which MAC address is listening on which of its ports. However,
there is no default way of 'asking' the router. But you can do this
indirectly, which in turn requires sniffing.
Regards.
Mikhail Zotov
> > > seen that it's possible in all cases.
> >
> > Perhaps, this is even easier. I have disabled "arp" on eth0, and the
> > log has been empty for some time. Then, records about new connection
> > attempts appeared. I am not quite sure about output of tcpdump but it
> > seems information about MAC addresses is provided by the router. Thus,
> > sniffing is not needed. Just ask the router. ;-)
>
> Yes, as soon as the router gets its hands on your MAC address, it saves
> that relation in an internal list. To prevent broadcasting it needs to
> know, which MAC address is listening on which of its ports. However,
> there is no default way of 'asking' the router. But you can do this
> indirectly, which in turn requires sniffing.
Can't this be done in a simpler way? A program sends some SYN packets
to *all* hosts in the LAN, e.g., packets addressed to port 1433
(ms-sql-s) (which appears to be quite common in the LAN). Thus, it
needs to get to know MAC addresses of *all* hosts in the LAN. It seems
it is the router that provides this information since my host doesn't
reply to the requests. This is just a guess but I doubt so many
windoops winnies in the LAN obtain MAC addresses by sniffing the
traffic. (BTW, the ISP seems to be running FC).
Regards,
Mikhail
Ertugrul Soeylemez
> > Yes, as soon as the router gets its hands on your MAC address, it
> > saves that relation in an internal list. To prevent broadcasting it
> > needs to know, which MAC address is listening on which of its ports.
> > However, there is no default way of 'asking' the router. But you
> > can do this indirectly, which in turn requires sniffing.
>
> Can't this be done in a simpler way? A program sends some SYN packets
> to *all* hosts in the LAN, e.g., packets addressed to port 1433
> (ms-sql-s) (which appears to be quite common in the LAN). Thus, it
> needs to get to know MAC addresses of *all* hosts in the LAN. It seems
> it is the router that provides this information since my host doesn't
> reply to the requests. This is just a guess but I doubt so many
> windoops winnies in the LAN obtain MAC addresses by sniffing the
> traffic. (BTW, the ISP seems to be running FC).
In that case you are not asking the router, but the host itself. If
your machine would not reply to that SYN, then the requester wouldn't
get your MAC address. Remember, if you don't DROP that SYN in your
netfilter, then your host will reply with an RST packet, revealing your
MAC address. And there are always ways to get answers from your
machine. You cannot prevent everything without locking yourself out of
the network.
Further remember that the requester doesn't even have to use the
internet protocol. It can send packets in some unknown protocol, for
which your machine returns an error packet, again revealing your MAC
address.
Regards.
Menno Duursma
> Menno Duursma <p...@pc.desktop.lan> (06-04-05 11:03:14):
>> > Just to encrypt everything is not enough. And you need some secure
>> > channel to distribute your key. It's best to meet your friends
>> > personally and give them a floppy disk. Do not distribute your key
>> > via internet, because the MITM is waiting there. ;)
>>
>> IME this utterly sucks when traveling (what makes SSH so usefull is
>> the 'access your boxen from the road' option). Now password
>> autentication though can be farly secure whist utilizing something
>> like Kerberos. (However one may consider it overkill to configure a
>> KDC for but a few Telnet/SSH sessions).
>
> My opinion is that Kerberos is harder to configure than key-based
> authentication.
That is why is posted the SRP (RFC2945) links (which you snipped):
http://srp.stanford.edu/analysis.html
Apperently there _is_ a OpenSSH SRP patch too though:
http://srp.stanford.edu/links.html
Anyways the Heimdal implementation isn't all that hard to configuure IMO.
(Sorry to say: the MS-AD is even easier, and RH-FC clients sail smooth too).
> But to be honest, I have not tried it myself, but just read about it.
> Key auth is enabled by default anyway,
So is GSSAPI (krb5).
> you just need to create a key, make it authorized and take it with you.
^^^^^^^^^^^^^^^^
Not many people are actually gonna do that! (They'll enable passwords...)
--
-Menno.