Artur Grabowski wrote:
"Miroslav Kubik" <[EMAIL PROTECTED]> writes:
Hello
In our intranet is an attacker who flooding OpenBSD router by ARP requests.
Due to this we have trouble with internet connection. Is there a way how to
protect server against ARP poisoning attack?
Excuse me? You have an attacker inside your intranet?
The best way to protect against that kind of attack is a baseball bat.
Or security guards who show the person where the door is and a lawyer
who hands over the lawsuit.
This is a social problem, don't solve it with a technical solution.
//art
messages in /var/log/messages
Aug 6 23:33:53 host22 /bsd: arp info overwritten for 192.168.1.249 by
00:e0:98:be:d3:cd on rl0
Aug 6 23:33:53 host22 /bsd: arp info overwritten for 192.168.1.246 by
00:e0:98:c5:8b:b9 on rl0
Aug 6 23:33:53 host22 /bsd: arp info overwritten for 192.168.1.245 by
00:e0:98:c5:9b:c5 on rl0
Aug 6 23:33:53 host22 /bsd: arp info overwritten for 192.168.1.242 by
00:e0:98:c5:8b:b9 on rl0
and still continue
........
S pozdravem / Best Regards
Miroslav Kubik
IT Specialist
Enterprise Server Farms
Have not read all mails in this thread (sorry) but an easy solution to
this problem is to run 'static-mac' on all int on your switches a.k.a.
mac-lockdown (require that you can manage your sw and the sw have this
option). If you can't do that, you're in for a rough ride. If you can or
can get help to do so, read on.
For mac-lockdown to have max effect, you'll have to have a list of the
original MAC connected to each int on each sw = you can't trust the
current arp entries on the sw(s).
The alternative is to extract the arp entries from the sw and use it to
do the lockdown. If you allready have the fake MAC, then use the same
table to find the int where the box is connected to. Downside to this
approach is that you might lock a fake MAC to the int it is connected
to, but don't worry, you can correct this later.
Most (but not all) arp-cache-poisoning is done with a home-made script
or tool e.g. 'angst' and is trickered as a cronjob and then followed by
whatever the attacker will run with his/her new temporary 'identity'.
This automation can be to your advantage. This first time a MAC is
changed on a end-node after your've made the lockdown, the box will be
blocked from the network. This is irreverseable and will be written to
the security-log on the sw with date, int, MAC and so on and if the box
is accessed remotely then the hunting is over. If the attacker is
sitting in front of the box the MAC can be reversed, but it will not
help the poor suckers kneecaps when you kick down the door with a
slegdehammer in your hands. Happy hunting.
P.S. arp entries don't live forever in the arp-table. When you hunt
attackeres like this, move fast.
/per
[EMAIL PROTECTED]
