Defending ARP Spoofing

Hi all,

I want to build up a resource containing all possibilities to defend ARP
spoofing. As I think ARP spoofing is one of the most powerful, easiest
and underestimated attacks I want to know all your tricks, patches,
anything that you know/apply to defend ARP spoofing.

I know the standard things to do (like static ARP entries and so on),
what I want to know from you is something like:

-OS x has a patch y which helps preventing ARP spoofing (like antidote)
or
-OS x in version y has a small built in ARP prevention (like SunOS)
or
-Firewall/IDS x is able to prevent/detect ARP spoofing

Also welcome are new thoughts about ARP spoofing prevention (like S-ARP
or Secure Link Layer).

Give me all your information, tricks and tips, so I can build up a
complete resource.

Thanks a lot,
Chris

Re: Defending ARP Spoofing

In article , chrismc911@hotmail.com
says...
> Hi all,
>
> I want to build up a resource containing all possibilities to defend ARP
> spoofing. As I think ARP spoofing is one of the most powerful, easiest
> and underestimated attacks I want to know all your tricks, patches,
> anything that you know/apply to defend ARP spoofing.
>
> I know the standard things to do (like static ARP entries and so on),
> what I want to know from you is something like:
>
> -OS x has a patch y which helps preventing ARP spoofing (like antidote)
> or
> -OS x in version y has a small built in ARP prevention (like SunOS)
> or
> -Firewall/IDS x is able to prevent/detect ARP spoofing
>
> Also welcome are new thoughts about ARP spoofing prevention (like S-ARP
> or Secure Link Layer).
>
> Give me all your information, tricks and tips, so I can build up a
> complete resource.
>
> Thanks a lot,
> Chris
>
Quote...
Using IPv6, IPsec or static ARP records can be effective methods of defence
against ARP spoofing attacks.
end quote..
http://en.wikipedia.org/wiki/ARP_spoofing

Re: Defending ARP Spoofing

Chris writes:

>Also welcome are new thoughts about ARP spoofing prevention

Don't put things together in a single LAN, which don't belong together
in a single LAN.

ARP spoofing prevented. You can close your survey.

best regards
Patrick

Re: Defending ARP Spoofing

In de.comp.security.misc Chris wrote:
> I want to build up a resource containing all possibilities to defend ARP
> spoofing.

Then use 802.1X and fixed MACs on each port.

Yours,
VB.
--
"Ich bin ein freier Mensch und werde jetzt von meinen Freiheitsrechten
Gebrauch machen - und zwar ausgiebig - natürlich nur in dem Rahmen, den
Otto Schily mir noch zur Verfügung stellt."
Wolfgang Clement am 10.10.05 als Noch-Superminister

Re: Defending ARP Spoofing

Casey Klc wrote:
> Quote...
> Using IPv6, IPsec or static ARP records can be effective methods of defence
> against ARP spoofing attacks.
> end quote..
> http://en.wikipedia.org/wiki/ARP_spoofing

Oh, we have to change that.

Yours,
VB.
--
"Ich bin ein freier Mensch und werde jetzt von meinen Freiheitsrechten
Gebrauch machen - und zwar ausgiebig - natürlich nur in dem Rahmen, den
Otto Schily mir noch zur Verfügung stellt."
Wolfgang Clement am 10.10.05 als Noch-Superminister

Re: Defending ARP Spoofing

> Don't put things together in a single LAN, which don't belong together
> in a single LAN.

As this is not always possible (university, company networks) this is
not a solution in every case.

Regards,
Chris

Re: Defending ARP Spoofing

Hi,

> Then use 802.1X and fixed MACs on each port.

Although this can be done, using fixed MACs is a hughe effort if you
think of company networks or universitys with thousands of computers in.

Regards,
Chris

Re: Defending ARP Spoofing

Chris wrote:
> > Then use 802.1X and fixed MACs on each port.
> Although this can be done, using fixed MACs is a hughe effort if you
> think of company networks or universitys with thousands of computers in.

This is a process, which can be automated. Additionally, we're talking
about preventing ARP spoofing. This will not work, if one doesn't know,
which MAC address is valid for which device, respectively.

Yours,
VB.
--
"Ich bin ein freier Mensch und werde jetzt von meinen Freiheitsrechten
Gebrauch machen - und zwar ausgiebig - natürlich nur in dem Rahmen, den
Otto Schily mir noch zur Verfügung stellt."
Wolfgang Clement am 10.10.05 als Noch-Superminister

Re: Defending ARP Spoofing

["Followup-To:" header set to comp.security.misc.]

Multi-Language Hierarchy crossposting. Please feel free to fup in the
language and hierarchy you prefer.

Chris :
> I want to build up a resource containing all possibilities to defend ARP
> spoofing. As I think ARP spoofing is one of the most powerful, easiest
> and underestimated attacks I want to know all your tricks, patches,
> anything that you know/apply to defend ARP spoofing.

The very best defense against ARP spoofing is to make sure your
network design and security concept does not rely on MAC addresses for
any of the following: Authentication, Authorisation, Identification.

> I know the standard things to do (like static ARP entries and so on),

Apparently not. The standard thing to do is to make your
network design (and security concept) immune to this kind of threat.

> what I want to know from you is something like:
>
> -OS x has a patch y which helps preventing ARP spoofing (like antidote)
> or

What makes you think the bad guy would install such a patch? How would
you enforce installation? How can you enforce that only stations with
such a patch participate in your network?

> -OS x in version y has a small built in ARP prevention (like SunOS)
> or

What are your talking about?

> -Firewall/IDS x is able to prevent/detect ARP spoofing

Unlikely if the spoofing entity has any brains at all. (i.e. you can
only catch complete dorks this way ;)

> Also welcome are new thoughts about ARP spoofing prevention (like S-ARP
> or Secure Link Layer).

Simply seperate your Authentication and Authorisation from Ethernet
layer parameters. This has been the way to make yourself immune against
ARP spoofing attacks for decades now. IPSEC is one of the many
technical solutions to accomplish this goal.

> Give me all your information, tricks and tips, so I can build up a
> complete resource.

Give me all your money, bonds and deeds, so I can provide you with a
complete response ;-)

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

Re: Defending ARP Spoofing

["Followup-To:" header set to comp.security.misc.]

Multi-Language Hierarchy crossposting. Please feel free to fup in the
language and hierarchy you prefer.

Chris :
> I want to build up a resource containing all possibilities to defend ARP
> spoofing. As I think ARP spoofing is one of the most powerful, easiest
> and underestimated attacks I want to know all your tricks, patches,
> anything that you know/apply to defend ARP spoofing.

The very best defense against ARP spoofing is to make sure your
network design and security concept does not rely on MAC addresses for
any of the following: Authentication, Authorisation, Identification.

> I know the standard things to do (like static ARP entries and so on),

Apparently not. The standard thing to do is to make your
network design (and security concept) immune to this kind of threat.

> what I want to know from you is something like:
>
> -OS x has a patch y which helps preventing ARP spoofing (like antidote)
> or

What makes you think the bad guy would install such a patch? How would
you enforce installation? How can you enforce that only stations with
such a patch participate in your network?

> -OS x in version y has a small built in ARP prevention (like SunOS)
> or

What are your talking about?

> -Firewall/IDS x is able to prevent/detect ARP spoofing

Unlikely if the spoofing entity has any brains at all. (i.e. you can
only catch complete dorks this way ;)

> Also welcome are new thoughts about ARP spoofing prevention (like S-ARP
> or Secure Link Layer).

Simply seperate your Authentication and Authorisation from Ethernet
layer parameters. This has been the way to make yourself immune against
ARP spoofing attacks for decades now. IPSEC is one of the many
technical solutions to accomplish this goal.

> Give me all your information, tricks and tips, so I can build up a
> complete resource.

Give me all your money, bonds and deeds, so I can provide you with a
complete response ;-)

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)

Re: Defending ARP Spoofing

> The very best defense against ARP spoofing is to make sure your
> network design and security concept does not rely on MAC addresses for
> any of the following: Authentication, Authorisation, Identification.

But what about people having to work in a not secure network
design/concept? How can you protect yourself if there is no security in
the network you are in at all and you are just the one using the
network, not the one to make a secure design?

Regards,
Chris

Re: Defending ARP Spoofing

>>-OS x in version y has a small built in ARP prevention (like SunOS)
>>or
>
>
> What are your talking about?

Quote from http://www.infosecwriters.com/text_resources/pdf/arp_spoofin g.pdf

"There are some machines, for example SunOS, which make an ARP entry
only if there
is a request for the one or if that ip is already in the ARP table. We
can make them
request for particular IP address by sending them an ICMP Echo packet
from that IP
address."

This is already some kind of protection, although it can be easily passed.

Regards,
Chris

Re: Defending ARP Spoofing

Post removed (X-No-Archive: yes)

Re: Defending ARP Spoofing

Chris writes:

>> The very best defense against ARP spoofing is to make sure your
>> network design and security concept does not rely on MAC addresses for
>> any of the following: Authentication, Authorisation, Identification.

>But what about people having to work in a not secure network
>design/concept? How can you protect yourself if there is no security in
>the network you are in at all and you are just the one using the
>network, not the one to make a secure design?

You can't. You are open to all kinds of denial-of-service.

Quit that job, it has insane requirements.

best regards
Patrick

Re: Defending ARP Spoofing

Sebastian Gottschalk wrote:
> Juergen P. Meier wrote:
>
>
>>The very best defense against ARP spoofing is to make sure your
>>network design and security concept does not rely on MAC addresses for
>>any of the following: Authentication, Authorisation, Identification.
>
>
> What is about Denial of Service? In the sense of not being able to simply
> flood the network, but razor-sharp ARP cache deconstruction.

This is a good point and explains why I started this discussion. I am
aware that you can design your network more securely, but if this is not
the case and you are simple a user of this network, what can you do?

Re: Defending ARP Spoofing

Casey Klc wrote:
> Using IPv6,

Yeah, thats not used basically anywhere...


> IPsec

Same here.


> or static ARP records

So what? Attacker can always spoof MAC address and he's own IP. Whats
the point?

--
My computer security & privacy related homepage
http://www.markusjansson.net
Use HushTools or GnuPG/PGP to encrypt any email
before sending it to me to protect our privacy.

Re: Defending ARP Spoofing

In the Usenet newsgroup comp.security.misc, in article
, Chris wrote:

> I want to build up a resource containing all possibilities to defend ARP
> spoofing. As I think ARP spoofing is one of the most powerful, easiest
> and underestimated attacks I want to know all your tricks, patches,
> anything that you know/apply to defend ARP spoofing.

ARP is a protocol that only works on "this" network. The only way someone
from outside "this" network can do ARP spoofing is to gain control of a
computer on "this" network. One presumes that your firewall is set such
as to make this extremely difficult for "outsiders". This does mean that
your ordinary users are not running servers OF ANY KIND, and that your
servers do not allow users. (Server hardening is outside the scope of this
article. If your users need to run servers, they need to take full
responsibility for the security of these servers. If these servers are
personal - they belong in outside server facilities, not on the school
or company network.)

An application not normally accessible to ordinary users is needed to allow
ARP spoofing. Some operating systems have this application as part of the
normal tools (example, UNIX /sbin/ifconfig). Normal sanity is such that
this tool is not usable by ordinary users in that manner. Also, some network
cards do not accept MAC address alteration.

The days of the original 10Base5 and 10Base2 Ethernet is pretty much over
due in part to the growing number of systems that may be attached to a
network, and the increasing amount of "normal" network traffic. Our
original setup was 10Base5 with a 255.255.252.0 mask, allowing 1022 hosts
on a single collision domain. By the mid 1990s, we altered the physical
setup by adding network switches to break each network into more usable
chunks (no more than 50 systems on a single port). Later, we added new
100BaseT networks to slowly but surely replace the coax, and that in
turn is being superseded with Gigabit networks - copper and fiber. These
networks are ALL connected by switches, such that no more than 7 computers
can be on any port (normally only one), and that being a short term
exception while additional media is pulled in. The switches are
intelligent - they know what MAC addresses are on a given port. Think
about that one for a second. The switches are administered by a separate
network which gives no access to normal users or outsiders.

All users are allowed access to the network ON CONDITION. That is, there
are written policies that each user has seen and signed that indicate what
is acceptable, and what is not acceptable. Violation of these policies is
a disciplinary problem, and may be dealt with harshly. For students at a
university, this means loss of their computer privileges. This may cause
them to fail a course - tough bananas. In a work environment, the solution
may reach the level of termination for cause.

A wise policy is to not give privileged computer access ("root" or
"administrator") to normal users. We also expect that local privilege
escalation problems are corrected on a timely basis - making the task of
installing and/or running an ARP spoofing application that much more
difficult.

None of these solutions are within the user's realm of responsibility,
and are not normally even in that of the system/network administration.
This is policy level solution, and must be dealt with at the highest
levels. Convincing "The Powers That Be" that abuse is not to be tolerated
is usually easy - getting the policies in place is harder, but a viable
solution. Making the abuse more difficult (by network design, and smart
operating permissions) is secondary to this concept, though vital.

Old guy

Re: Defending ARP Spoofing

Defined Topology based access in the firewall. Most of the firewall
support this feature now - like pix , checkpoint etc.


Best regards,
NAVTEJ KOHLI

Re: Defending ARP Spoofing

"Chris" wrote in message
news:dklo1p$o1f$1@news2.rz.uni-karlsruhe.de...
> Hi all,
>
> I want to build up a resource containing all possibilities to defend ARP
> spoofing. As I think ARP spoofing is one of the most powerful, easiest
> and underestimated attacks I want to know all your tricks, patches,
> anything that you know/apply to defend ARP spoofing.
>
> I know the standard things to do (like static ARP entries and so on),
> what I want to know from you is something like:

Here are some:

Use IPSec / VPN to verify client identities;
Use any solution that includes client certificates, such as SSL;
Use "port security" on switches to control which MAC addresses can access
that switch port;
Use physical security and personnel security to ensure that people on your
internal network are relatively trusted;
Train users to recognize and report the possible symptoms of ARP spoofing
[this is rarely done in real life]; and/or,
Harden all your hosts as best you can against compromise using the usual
methods;
Accept ARP spoofing as a theoretical risk.

I do not believe ARP spoofing happens all that frequently in real life.
Generally, someone doing ARP spoofing has physical or remote access to a
host on your internal network. Someone that is in the position to do ARP
spoofing is usually in the position to do whatever they want to you given
enough time.

Before wasting a lot of time and money trying to defend against ARP
spoofing, be sure you've done enough to get rid of the more commonly
exploited vulnerabilities on your systems first. I don't know too many
people that can say they are in that position.

> -OS x has a patch y which helps preventing ARP spoofing (like antidote)
> or
> -OS x in version y has a small built in ARP prevention (like SunOS)
> or
> -Firewall/IDS x is able to prevent/detect ARP spoofing

None of these really exist as far as I know.

Re: Defending ARP Spoofing

"Chris" wrote in message
news:dklo1p$o1f$1@news2.rz.uni-karlsruhe.de...
> Hi all,
>
> I want to build up a resource containing all possibilities to defend ARP
> spoofing. As I think ARP spoofing is one of the most powerful, easiest
> and underestimated attacks I want to know all your tricks, patches,
> anything that you know/apply to defend ARP spoofing.
>
> I know the standard things to do (like static ARP entries and so on),
> what I want to know from you is something like:

Here are some:

Use IPSec / VPN to verify client identities;
Use any solution that includes client certificates, such as SSL;
Use "port security" on switches to control which MAC addresses can access
that switch port;
Use physical security and personnel security to ensure that people on your
internal network are relatively trusted;
Train users to recognize and report the possible symptoms of ARP spoofing
[this is rarely done in real life]; and/or,
Harden all your hosts as best you can against compromise using the usual
methods;
Accept ARP spoofing as a theoretical risk.

I do not believe ARP spoofing happens all that frequently in real life.
Generally, someone doing ARP spoofing has physical or remote access to a
host on your internal network. Someone that is in the position to do ARP
spoofing is usually in the position to do whatever they want to you given
enough time.

Before wasting a lot of time and money trying to defend against ARP
spoofing, be sure you've done enough to get rid of the more commonly
exploited vulnerabilities on your systems first. I don't know too many
people that can say they are in that position.

> -OS x has a patch y which helps preventing ARP spoofing (like antidote)
> or
> -OS x in version y has a small built in ARP prevention (like SunOS)
> or
> -Firewall/IDS x is able to prevent/detect ARP spoofing

None of these really exist as far as I know.

defined topology (was Re: Defending ARP Spoofing)

"NAVTEJ KOHLI" writes:

>Defined Topology based access in the firewall. Most of the firewall
>support this feature now - like pix , checkpoint etc.

What is this 'defined topology', technologically, that 'most firewalls'
support now?

Please be a bit specific about what is done, and under which external
conditions it will bear fruit. Keep in mind the original poster's
focus on nonchangeable campus networks. How will those be helped?

best regards
Patrick

Re: Defending ARP Spoofing

ibuprofin@painkiller.example.tld (Moe Trin) writes:

>Also, some network cards do not accept MAC address alteration.

Really? Which ones? Apart from software driver deficiencies, I mean.
Are there really cards which do not permit any host software to
change the MAC address the card uses as source MAC when sending
frames? Source MAC is forced to the card hardware value for each
and every frame?

I would want to avoid buying such cards, as they have less value.
For example, you can't build an ethernet bridge with cards of that
persuation. Ethernet bridges must pass through the original MAC.

[rest of posting snipped, because it was very fine :-]

best regards
Patrick

Re: Defending ARP Spoofing

NAVTEJ KOHLI wrote:
> Defined Topology based access in the firewall. Most of the firewall
> support this feature now - like pix , checkpoint etc.

can you please explain what you mean be "defined topology" and what kind
of security these firewalls implement? If you just mean that you can
define different networks you are on, this does not help much in
preventing ARP spoofing

Regards,
Chris

Re: Defending ARP Spoofing

Volker Birk wrote:
> This is a process, which can be automated. Additionally, we're talking
> about preventing ARP spoofing. This will not work, if one doesn't know,
> which MAC address is valid for which device, respectively.

can you tell me which tool exist that can automate this process? If the
tools also work on the ethernet network (which I think), they are must
be secured, otherwise they are also vulnerable to arp spoofing

regards,
Chris

Re: Defending ARP Spoofing

In the Usenet newsgroup comp.security.misc, in article
<43704b4e$0$6922$9b622d9e@news.freenet.de>, Patrick Schaaf wrote:

>ibuprofin@painkiller.example.tld (Moe Trin) writes:
>
>>Also, some network cards do not accept MAC address alteration.
>
> Really? Which ones? Apart from software driver deficiencies, I mean.

It's almost certainly a driver issue. Most drivers initialize the
stack by reading the hardware parameters from the card (there are
exceptions), and sticks this into kernel memory, which has much faster
access times. Some drivers don't accept MAC address alteration as part
of the configuration routine (example /sbin/ifconfig -hw). You may be
able to use a third party tool like macchanger. Remember, not all
people are comfortable hacking the driver code - I certainly wouldn't
bother trying.

>For example, you can't build an ethernet bridge with cards of that
>persuation. Ethernet bridges must pass through the original MAC.

Your bridge is running on a system that doesn't have ProxyARP?

Old guy

Re: Defending ARP Spoofing

In the Usenet newsgroup comp.security.misc, in article
, Chris wrote:

>Volker Birk wrote:

]Chris wrote:
]
]> Although this can be done, using fixed MACs is a hughe effort if you
]> think of company networks or universitys with thousands of computers in.

>> This is a process, which can be automated.

>can you tell me which tool exist that can automate this process?

Procedurally, we don't allow any computer onto our networks unless it has
been registered. This is both a security issue (we're an R&D facility, but
this procedure is enforced company wide), and a 'tax' issue (the Computer
and Network Services departments are funded by the users - in turn, it
repairs the computers "for free" and provides the network infrastructure).
The registration data is distributed to several data bases, and contains
MAC and IP, full equipment description (including serial numbers), location
(including room number and network drop information), and user name. The
databases are under a version control scheme (CVS) for history and auditing.
We use a locally made tool similar to arpsnmp or arpwatch that monitors the
network switches, routers, and some servers. Briefly, the ARP cache (and
for the switches, the port information) is dumped to monitor servers on a
regular basis ("very frequently" is all I'll say), where this information
is compared with "normal" data. Differences cause alarms. I haven't looked
at the "tools" lately, but most are simple shell scripts that any second
year CS student given a description of the task should be able to create
in a matter of minutes.

We still laugh over the first "victim" we caught, about a week after
corporate approved the policy. We get an alarm that a "rogue computer" is
on the network segment that serves "Mahogany Row" where all the bosses
live. This was in 1996, when we were still using 10Base5 there and network
switches to break the subnet into manageable sizes, so all we knew was that
it was in one of about 20 offices. Cue the "Thundering Herd" of network
administrators along with a few [armed] security guards. Took four or five
minutes to locate the rogue - a laptop used by the corporate CEO who was
visiting from the other side of the country, and had decided to check his
email. You can guess who it was who had signed the corporate policy just
a week earlier, right?

>If the tools also work on the ethernet network (which I think), they are
>must be secured, otherwise they are also vulnerable to arp spoofing

The initial "registration" is handled by the Computer and Network Services
department, when the new systems arrive (all of our systems are using
static addresses, rather than DHCP). System moves are also handle by
this department, so the registration data is reasonable accurate. The
monitoring tools use an isolated network to communicate. All alarms are
investigated, and the cause determined (and corrected).

Some may think this procedure to be a burden. As policy is in place, and
the users are aware of it, it's actually easier than you may think. While
we get new hardware in year-round, there is a period near the beginning and
end of the fiscal year when hardware changes peak. The on-going task of
monitoring is quite minor in comparison.

Old guy

Re: Defending ARP Spoofing

ARP is used to map IP addressing to MAC addresses in a local area
network segment where hosts of the same subnet reside. ARP attack
happens when someone is trying to change the ARP table of MAC and IP
addresses information without authorization.
So you can defined your firewall interface in Topology. so it only
process from that interface.

Regards,
NAVTEJ KOHLI

Re: Defending ARP Spoofing

ibuprofin@painkiller.example.tld (Moe Trin) writes:

>>For example, you can't build an ethernet bridge with cards of that
>>persuation. Ethernet bridges must pass through the original MAC.

>Your bridge is running on a system that doesn't have ProxyARP?

Maybe I think ProxyARP is a foolish thing to do, especially when
what I need is an ethernet bridge, which is a totally different
thing than a box running ProxyARP.

As a simple example, show me how you run PPPoE through a nonbridge
with ProxyARP. I think you'll find you need to invent MAC-layer NAT
for such a case, if you cannot permit the switching software to have
full control over the source MAC of the frames that it relays.
And I have never heard of MAC-layer NAT, thanks God.

ProxyARP, in all cases where I've seen it used, was the problem,
not the solution.

best regards
Patrick

Re: Defending ARP Spoofing

In the Usenet newsgroup comp.security.misc, in article
<43719f0c$0$4075$9b622d9e@news.freenet.de>, Patrick Schaaf wrote:

>Maybe I think ProxyARP is a foolish thing to do, especially when
>what I need is an ethernet bridge, which is a totally different
>thing than a box running ProxyARP.

The first generation of Ethernet switches we used did ProxyARP rather
than pure bridging. Worked (and still does on two subnets) quite well.

>As a simple example, show me how you run PPPoE through a nonbridge
>with ProxyARP.

We don't use PPPoE. Our POTS dialins do ProxyARP, but that's standard ppp.

Old guy

Re: Defending ARP Spoofing

ibuprofin@painkiller.example.tld (Moe Trin) writes:

>In the Usenet newsgroup comp.security.misc, in article
><43719f0c$0$4075$9b622d9e@news.freenet.de>, Patrick Schaaf wrote:

>>Maybe I think ProxyARP is a foolish thing to do, especially when
>>what I need is an ethernet bridge, which is a totally different
>>thing than a box running ProxyARP.

>The first generation of Ethernet switches we used did ProxyARP rather
>than pure bridging. Worked (and still does on two subnets) quite well.

>>As a simple example, show me how you run PPPoE through a nonbridge
>>with ProxyARP.

The key question is why in the world you would run pppoe for any reason
whatsoever.

>We don't use PPPoE. Our POTS dialins do ProxyARP, but that's standard ppp.

> Old guy

Re: Defending ARP Spoofing

Unruh writes:

>>>As a simple example, show me how you run PPPoE through a nonbridge
>>>with ProxyARP.

>The key question is why in the world you would run pppoe for any reason
>whatsoever.

No.

The key question is, why would anybody propose ProxyARP as a replacement
for ethernet bridging.

I've made my point of view clear. It's end of thread, for me.

best regards
Patrick

Re: Defending ARP Spoofing

Can't help much with the resource guide, but had a bit to add to the
other part of the discussion. I do think that you need to be careful
not to fall into the trap of trying to protect from the wrong threats
for the specific environment. As stated by others the network design
will help mitigate some risk. What are you protecting, the client or
the network? Your role will greatly change the types of technology
available to you.

My basic tenets for security design are to eliminate the un-necessary,
harden the rest, monitor everything, know where your weaknesses are and
modify behavior to pickup the slack.

You did state that your concern was as a client in an environment that
cannot be controlled. In that case, you will always be at some level
of risk because you have to trust something to tell you the truth
initially. To mitigate risks at this level use secure sessions with
cryptography and keys that you trust.

IMHO Denial of service protection is an unwinnable battle on the client
side. Only a tightly controlled network design are likely to be able
to work here. In a large network with thousands of hosts, you
prioritize. Put the extra efforts into protecting critical business
functions, and network services. Let the rest of the clients operate
at a higher level of risk.

Good luck
/D
Dion

Re: Defending ARP Spoofing

Chris wrote:
> Volker Birk wrote:
> > This is a process, which can be automated. Additionally, we're talking
> > about preventing ARP spoofing. This will not work, if one doesn't know,
> > which MAC address is valid for which device, respectively.
> can you tell me which tool exist that can automate this process?

There are many tools. They're called "scripting language" or "programming
language" ;-)

> tools also work on the ethernet network (which I think), they are must
> be secured, otherwise they are also vulnerable to arp spoofing

It is a good idea, to have an own management network for the active
network devices.

Yours,
VB.
--
"Ich bin ein freier Mensch und werde jetzt von meinen Freiheitsrechten
Gebrauch machen - und zwar ausgiebig - natürlich nur in dem Rahmen, den
Otto Schily mir noch zur Verfügung stellt."
Wolfgang Clement am 10.10.05 als Noch-Superminister

Re: Defending ARP Spoofing

>>>This is a process, which can be automated. Additionally, we're talking
>>>about preventing ARP spoofing. This will not work, if one doesn't know,
>>>which MAC address is valid for which device, respectively.
>>
>>can you tell me which tool exist that can automate this process?
>
>
> There are many tools. They're called "scripting language" or "programming
> language" ;-)

Unfortunately these "tools" used to distribute/update MAC-IP pairs to
the workstations will work over TCP/UDP or somethings that goes in the
end over ARP. Which means these management tools are also vulnerable to
ARP Spoofing attacks (if they are not properly secured) which closes the
circle.

Regards,
Chris

Re: Defending ARP Spoofing

Chris wrote:
> Unfortunately these "tools" used to distribute/update MAC-IP pairs to
> the workstations will work over TCP/UDP or somethings that goes in the
> end over ARP.

There is SSH, for example.

> Which means these management tools are also vulnerable to
> ARP Spoofing attacks (if they are not properly secured) which closes the
> circle.

No, they aren't.

Yours,
VB.
--
"Ich bin ein freier Mensch und werde jetzt von meinen Freiheitsrechten
Gebrauch machen - und zwar ausgiebig - natürlich nur in dem Rahmen, den
Otto Schily mir noch zur Verfügung stellt."
Wolfgang Clement am 10.10.05 als Noch-Superminister

Re: Defending ARP Spoofing

I think in the future we will see some form of CA solution with
certificates and all that with "trusted" host in some form of system
similar to DNS but for MAC-addresses. Right now there isn't a whole lot
you can do but to put up a big pile of hardware with rate control and
static ARP caches for high availability networks and hope that it will
keep your infrastructure away from heading down the toilet.

This is an example from my world:

- Each year, the InfoSec education i'm attending have done "ARP fun and
games" in a "capture the server" type event as a final exam for the
1'st year students.

- Each year the school network has been connected to the county
network.

- Each year, they've said; "We got security-flavour X; it will handle
up to it."

- Each year, the county have called and asked to have their network
back.

Re: Defending ARP Spoofing

In the Usenet newsgroup comp.security.misc, in article
<1131753098.448594.32010@g49g2000cwa.googlegroups.com>, Ichinin wrote:

>Right now there isn't a whole lot you can do but to put up a big pile of
>hardware with rate control and static ARP caches for high availability
>networks and hope that it will keep your infrastructure away from heading
>down the toilet.

I dunno about a "big pile of hardware", as managed switches aren't that
much bigger than unmanaged ones, but you are discussing a rather passive
response.

>This is an example from my world:
>
>- Each year, the InfoSec education i'm attending have done "ARP fun and
>games" in a "capture the server" type event as a final exam for the
>1'st year students.

Not a real life situation

>- Each year, they've said; "We got security-flavour X; it will handle
>up to it."

Managed switches will go a long way in fixing that - another is a line
of pikes along the walkway in from the parking lot to the building
entrance with the severed heads of malefactors impaled on them. Tends
to get the message across, though the local civil rights people tend
to go ballistic.

>- Each year, the county have called and asked to have their network
>back.

That's great. If there is no cost to the individuals who abuse your
network, any one can and will take it over. In the real world, we
don't often work like that. We disconnect people who abuse our network
(I'm in business - we fire 'em; schools can revoke the computer privileges
or kick the idiots out to the same effect). This tends to discourage
insiders from abuse. To keep outsiders from abusing your network, you
don't allow them in. Do they not teach that any more?

Old guy

Re: Defending ARP Spoofing

Moe Trin wrote:
> In the Usenet newsgroup comp.security.misc, in article
> (..blah-blah i'm the only one who know anything blah-blah-blah...)

I see CSM is still filled with trolls...

Good luck with this newsgroup and have a nice life. (unsubscribing)

Re: Defending ARP Spoofing

Chris wrote:
> Sebastian Gottschalk wrote:
>> Juergen P. Meier wrote:
>>
>>
>>> The very best defense against ARP spoofing is to make sure your
>>> network design and security concept does not rely on MAC addresses for
>>> any of the following: Authentication, Authorisation, Identification.
>>
>>
>> What is about Denial of Service? In the sense of not being able to simply
>> flood the network, but razor-sharp ARP cache deconstruction.
>
> This is a good point and explains why I started this discussion. I am
> aware that you can design your network more securely, but if this is not
> the case and you are simple a user of this network, what can you do?

As a simple user, it's your job to ask the administrator. :-)

As an administrator, you can either make the entire ARP table static
(and not allowing any dymanically created entries) on a static network
or you can try to limit the effects by carefully structuring your
network, including the usage of IEEE 802.X for authorization and to
track down potential disturbers to a network segment.

Re: Defending ARP Spoofing

Sebastian Gottschalk wrote:
> > This is a good point and explains why I started this discussion. I am
> > aware that you can design your network more securely, but if this is not
> > the case and you are simple a user of this network, what can you do?
> As a simple user, it's your job to ask the administrator. :-)
> As an administrator, you can either make the entire ARP table static
> (and not allowing any dymanically created entries) on a static network
> or you can try to limit the effects by carefully structuring your
> network, including the usage of IEEE 802.X for authorization and to
> track down potential disturbers to a network segment.

Unfortunately, with Microsoft Windows static ARP entries are overwritten
by receiving ARP replies, and you cannot prevent this.

Yours,
VB.
--
> My windows XP is updated for all critical updates including survive pack 2.
Norman Perry in c.s.f

Re: Defending ARP Spoofing

On Sat, 18 Feb 2006 20:54:22 +0100, Volker Birk wrote:
> Sebastian Gottschalk wrote:

>> As an administrator, you can either make the entire ARP table static
>> (and not allowing any dymanically created entries) on a static network
>> or you can try to limit the effects by carefully structuring your
>> network, including the usage of IEEE 802.X for authorization and to
>> track down potential disturbers to a network segment.
>
> Unfortunately, with Microsoft Windows static ARP entries are overwritten
> by receiving ARP replies, and you cannot prevent this.

Only w<2k do that. XP and 2k3 act as might expected:
http://seclists.org/lists/vuln-dev/2003/Feb/0032.html

--
-Menno.

Re: Defending ARP Spoofing

Menno Duursma wrote:
> > Unfortunately, with Microsoft Windows static ARP entries are overwritten
> > by receiving ARP replies, and you cannot prevent this.
> Only w<2k do that. XP and 2k3 act as might expected:
> http://seclists.org/lists/vuln-dev/2003/Feb/0032.html

Good to hear.

Yours,
VB.
--
> My windows XP is updated for all critical updates including survive pack 2.
Norman Perry in c.s.f