1

I'm not experienced with IP tables but it's something I'll be looking into if this is plausible. I'm looking to set up a system to inspect packets and look for a pattern similar to korek's chop chop attack. Is there a way to set up the IP tables to defend against this attack?

Thanks

Chris
  • 109
  • 5

2 Answers2

1

WEP operates at OSI Layer 2. Iptables operates at Layer 3, so it will not be able to properly deal with this specific type of attack. You could possibly check out ebtables, though, which enables some level of filtering at the bridge level.

EEAA
  • 109,363
  • 18
  • 175
  • 245
  • interesting. and as another perspective, it wouldn't be possible to filter traffic by reading each packet, and then at the application layer somehow blacklist them? – Chris Apr 06 '10 at 05:07
  • @Chris This is a very common practice. The mechanism is usually to LOG suspicious traffic and then use an application to watch the logs and blacklist accordingly (either with iptables rules or with routes) – tylerl Apr 06 '10 at 05:11
  • Thanks for the reply. So setting the flags to log the suspicious traffic happens at the application level too? So really, it's a matter of writing a program that takes in packets and inspects them like wireshark (but without the manual inspection) and taking note of packets that follow the pattern. – Chris Apr 06 '10 at 05:14
  • @Chris @tylerl The issue is not whether or not it's possible to log traffic and take action on it. That's certainly possible with Layer 3 traffic. The problem is that this exploit works in Layer 2, which iptables knows nothing about, so this logging/blocking paradigm won't work in this specific instance. As mentioned, it may be possible with ebtables (which works at a lower level than iptables). I have very little experience with ebtables, though, so I can offer any more specifics. – EEAA Apr 06 '10 at 12:31
0

I use iptables to block some SIP messages that come from my provider to my asterisk.

# iptables -A INPUT -s @provider -p udp -m udp --dport 5060 -m string --string "Cirpack KeepAlive Packet" --algo bm --to 65535 -j DROP

These messages are not 100% sip compatible, and they generate a lot of logs on the asterisk server. So I drop them, thanks to iptables.

It doesn't generate much system load, but I never tried to test it under heavy network load.

petrus
  • 5,297
  • 26
  • 42