ACL for SYN Attack? Wha? (ISCW)
redwarrior
Member Posts: 285
in CCNP
I ran into a really tough practice exam question over the weekend. Unfortunately, I didn't get the exact question written down, but it was basically showing a static ACL and asking what type of vulnerability the ACL was configured to protect against. Since the ACL showed a "deny ip" statement for the address range of the inside network for traffic coming in the outside interface, I chose "IP spoofing" as the attack the ACL was designed to block, but the practice exam gave "TCP SYN Attack" as the correct answer. Now, I'm more than willing to admit either I or the practice exam were wrong, but I'm wondering if anyone has any good resources for identifying what kinds of vulnerabilities certain types of static ACL's are designed to block...I kinda feel like I'm flying blind there...
Thanks!
Thanks!
CCNP Progress
ONT, ISCW, BCMSN - DONE
BSCI - In Progress
http://www.redwarriornet.com/ <--My Cisco Blog
Comments
-
dtlokee Member Posts: 2,378 ■■■■□□□□□□From what you describe it sounds like you are correct and their answer is wrong.The only easy day was yesterday!
-
redwarrior Member Posts: 285The thing that makes me uneasy is that I'm not sure what an ACL designed to protect against a TCP SYN attack *would* look like...sounds more like CBAC stuff to me, like a tcp inspect rule. I think my eyes are crossing.
CCNP Progress
ONT, ISCW, BCMSN - DONE
BSCI - In Progress
http://www.redwarriornet.com/ <--My Cisco Blog -
dtlokee Member Posts: 2,378 ■■■■□□□□□□Well since an acl isn't going to track the number of SYN packets received, an ACL is a poor choice for dynamically preventing a syn attack. You could use an ACL to deny any TCP packets which are syn packets from the outside (meaning the initial outbound packet would have a syn in it) like this:
access-list 100 permit tcp any any established
access-list 100 deny tcp any any
interface fa0/0
ip access-group 100 in
assuming interface fa0/0 is facing the Internet (or where the syn attack would come from) this will deny any inbound syn packets. Now would this design work for a web server on the inside that you want to have accessible from the Internet? No it won't because you need to allow the initial inbound syn packet. This is a case where CBAC or legacy TCP intercept would be applied to keep track of the number of half open TCP sessions and begin to deny or close them when it exceeds your threshold.The only easy day was yesterday! -
GT-Rob Member Posts: 1,090Ya I usually answer TCP intercept or CBAC of some sort for protection against SYN attacks.
TCP intercept can act as a proxy between the 2 devices, or it can 'watch' the open connections and send a reset to the server in the case it has hit its timeout.
Otherwise like DT said, an ACL can't really watch for half open connections and reset/stop them based on a certain amount. It still has to let them through (or else TCP wont work) initially. -
redwarrior Member Posts: 285You guys are awesome, as always! I did more digging last night because this one was like a bee in my bonnet until I figured it out.
Basically, yes, there was a portion of the ACL beyond the RFC filtering rules that did only allow established connections in from the outside, so this would block a SYN attack, although it seems like a very crude way to do so. I'm thinking that it was a bad practice question to lump so much into that ACL that could have gone for either type of attack, but on the bright side, it did make me do more digging into a topic that could very well end up being important.
I think in the real world, I'd probably use an IPS to protect against a SYN attack using attack signatures that I'd have a little more granular control over, but it's good to know other methods that might work in a pinch.
CCNP Progress
ONT, ISCW, BCMSN - DONE
BSCI - In Progress
http://www.redwarriornet.com/ <--My Cisco Blog -
dtlokee Member Posts: 2,378 ■■■■□□□□□□Yes using the established keyword is very crude. Using a stateful firewall like CBAC, zone based or a hardware firewall like a PIX or ASA is a better choie because they all track the state of the connection. You don't really need an IP for that function.The only easy day was yesterday!