I have annoying arp flood like this:
19.804989 JuniperN_32:00:c3 -> Broadcast ARP Who has 81.95.88.34? Tell 81.95.88.1
19.805593 JuniperN_32:00:c3 -> Broadcast ARP Who has 81.95.153.33? Tell 81.95.153.1
19.806004 JuniperN_32:00:c3 -> Broadcast ARP Who has 81.95.89.147? Tell 81.95.88.1
etc...
I tried ebtables -A INPUT -p ARP -j DROP, but ARP is still showing in tcpdump and ethereal.

Try :
To re-enable arp :

It doesn't work .

What does not work ?
Maybe try :

I still got arp traffic. I tried your next tip too but without success.

Hi,

I would have thought that your ebtables rule would have blocked arp...
maybe you should block in another chain than the input one... have a look at http://ebtables.sourceforge.net/br_f....html#section2 it explains how chains are linked together... maybe blocking at the brouting stage would be more efficient.

still, you'll need to be carefull about blocking arp, since if you're using ethernet you need to be able to resolve IP to MAC equivalences.

Usually tcpdump and ethereal put the network cards in promiscous mode. You can drop the arp packets all you want they are still floating through your network since arp requests are always sent to the ethernet broadcast address. If you want to swich that off you need to suppress the arp packages in some central location like a switch. That is, however, a very bad idea since it will render your network non-funtional unless you have static arp tables on all clients.

I don't know if this was resolved but I found the solution, here is an example http://www.usermadetutorials.com/201...ith-arptables/

Thanks.

I think the OP didn't know that arp is normal and needed. You don't want to stop those messages.

At this time, i had no clear idea what arp is.

Anyway, i always wonder if it's possible to "firewall" these .

Possible in a number of ways but not really ever used. I doubt anyone ever has a real system that is trying to block them. Some switches may have been configured with a sort of speedometer limit that blocks any or all types of traffic when traffic reaches a pre-set number. Say when http or tcp traffic gets to 60% then block all other until limit drops. At a box you could only ignore them but that doesn't help traffic. You'd only get a very very small processor increase for that task. May even result in more cpu time I'd think.

Look at your arp table:

Then look at the volume of arp request flowing through that interface. I'm guessing it has _zero_ effect on the arp entries you see.

That interface you're monitoring will only answer for arp requests for whatever IP addresses are assigned to it. Otherwise, it just doesn't matter. In order for someone to start poking around that interface, they'll have to have access to something within the broadcast domain assigned to that network.

In reality, all that entity would have to do is put their interface in promiscuous mode, sniff traffic, and wait. They'll see your arp request flowing through at one point or another.

That interface looks like a WAN interface on a firewall. Here is the capture of just a few seconds on my firewall on the WAN:

That doesn't concern me in the least.

That's been sanitized for my protection. Odd seeing the entry for the 192.168.1.100 host in there, that's on a IPSEC VPN tunnel. Guess I never really looked all that closely to the arp table.

Anyhow, there are considerably more important things to be concerned with. You could isolate accepted arp entries to the known gateway if you have a static IP and you never expect the network config to change, but that seems overboard. I'm paranoid. I don't like offering anything up via public services, because I've worked in the security sector, and know what can come of publicly available services.

But, to your credit, there are ways to poison arp entries, so there is some merit. I haven't looked at that vector in a while, but it is possible to inject bogus arp entries and set up a 'man in the middle' attack.

I dunno. I work now in a NOC that monitors a huge number of networks, and have seen the passwords on publicly accessible devices. They're not exactly challenging to guess. I'd be ashamed of the user/password combinations I've seen. For one of our clients, I'd say 50% of them are easily accessed. Nothing new, trust me, as those mindless practices have been around forever. Those devices would be a good platform from which one could devise a method, I suppose. Those devices are limited in their ability to capture traffic, but someone resourceful might be able to come up with something that would work. Might be able to devise a method of flashing a more capable firmware to do the job.

Hell. Yeah, definitely some merit.

But I'm paranoid. Big time.

Unfortunately, my paranoia isn't more common.

Oh, and something I thought I would add is that even though you see those arp request flowing in on that interface, the only ones your system will be the arp requests for your particular IP(s). It isn't responding to the rest of them. Also, even if you were filtering them, you will still see them coming in on the interface. There really isn't a way to stop them, well, if you don't have control over the upstream device. All the traffic I filter on my firewall inbound on the WAN still gets to it, it just drops it. That's just how they work.

! Thanks all for your responses !

+1 ^^

Usually tcpdump in addition to aeriform put the community cards in promiscous manner. You may shed a arp boxes all you need they may be still hanging as a result of your community considering arp needs will almost always be ship to this ethernet broadcast address. If you would like swich that off you need to control the actual arp deals in a few location being a transition. That is certainly, even so, an incredibly poor plan mainly because it will establish your multilevel non-funtional if you can't include fixed arp platforms on all of customers.