up vote 1 down vote favorite
1
share [g+] share [fb]

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

link|improve this question
feedback

2 Answers

up vote 1 down vote

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.

link|improve this answer
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 6 '10 at 5: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 6 '10 at 5: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 6 '10 at 5: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. – ErikA Apr 6 '10 at 12:31
feedback
up vote 0 down vote

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.

link|improve this answer
feedback

Your Answer

 
or
required, but never shown
discard

Not the answer you're looking for? Browse other questions tagged or ask your own question.