03-27-2013 05:37 AM - edited 03-11-2019 06:20 PM
Hi
In order to mitigate syn-floods, syn-cookies are usefull tools, but I wonder how the count is.
F.ex if this security police from the configuration guide is applied to the outside interface:
hostname(config)# class-map CONNS
hostname(config-cmap)# match any
hostname(config-cmap)# policy-map CONNS
hostname(config-pmap)# class CONNS
hostname(config-pmap-c)# set connection conn-max 1000 embryonic-conn-max 3000
hostname(config-pmap-c)# set connection timeout idle 2:0:0 embryonic 0:40:0 half-closed 0:20:0 dcd
hostname(config-pmap-c)# service-policy CONNS interface outside
the syn-cookie/tcp-intercept will kick in when 3000 embryonic conns are seen from the outside, but is the count per ASA-box/module / per context og per IP-address ?
Thanks :-)
Jesper Joensen
Solved! Go to Solution.
03-27-2013 06:44 AM
Hello Jesper,
Regarding your question. Since you are using the commands:
conn-max n argument sets the maximum number of simultaneous TCP and/or UDP connections that are allowed, between 0 and 65535. The default is 0, which allows unlimited connections.
embryonic-conn-max
n argument sets the maximum number of simultaneous embryonic connections allowed, between 0 and 65535. The default is 0, which allows unlimited connections.
The count applies to the box or ASA if it is running single-context or to the specific context with the class configuration if running Multiple Context. You can also limit the connection and embryonic limit per IP by using the following commands:
The per-client-embryonic-max n argument sets the maximum number of simultaneous embryonic connections allowed per client, between 0 and 65535. The default is 0, which allows unlimited connections.
The per-client-max n argument sets the maximum number of simultaneous connections allowed per client, between 0 and 65535. The default is 0, which allows unlimited connections.
Hope this helped you out, don't forget to rate helpful posts.
Best Regards.
Eddy Duran
03-27-2013 12:33 PM
Hello Jesper,
If you want to protect thoudsands of IP's behind this ASA this is going to do it for you,
I mean you can be as specific as you want with the modular policy framework
Let's say you want to restrict SYN flood attacks to one of your SMTP servers ( In our scenario will be 10.1.1.10 that get's natted to 2.2.2.2 on the ASA)
access-list Julio permit tcp any host 2.2.2.2 eq 25
class-map SYN_Prevention_SMTP
match access-list Julio
exit
policy-map global_policy
class SYN_Prevention_SMTP
set connection per-client-embryonic-max 5
With this setup as soon as one client starts more than 5 TCP connections on port 25 to your server and the connections never get established the SYN-Cookie protection mechanism will be triggerd ( TCP intercept)
Do you follow me?
03-27-2013 06:44 AM
Hello Jesper,
Regarding your question. Since you are using the commands:
conn-max n argument sets the maximum number of simultaneous TCP and/or UDP connections that are allowed, between 0 and 65535. The default is 0, which allows unlimited connections.
embryonic-conn-max
n argument sets the maximum number of simultaneous embryonic connections allowed, between 0 and 65535. The default is 0, which allows unlimited connections.
The count applies to the box or ASA if it is running single-context or to the specific context with the class configuration if running Multiple Context. You can also limit the connection and embryonic limit per IP by using the following commands:
The per-client-embryonic-max n argument sets the maximum number of simultaneous embryonic connections allowed per client, between 0 and 65535. The default is 0, which allows unlimited connections.
The per-client-max n argument sets the maximum number of simultaneous connections allowed per client, between 0 and 65535. The default is 0, which allows unlimited connections.
Hope this helped you out, don't forget to rate helpful posts.
Best Regards.
Eddy Duran
03-27-2013 07:05 AM
Thanks Eddy
If I want to syn-flood protect thousands of IPs behind the ASA, but the per-client options don't apply as far as I can see - I need a per-server option ?
And this note from the configuration guide:
When you use TCP SYN cookie protection to protect servers from SYN attacks, you must set the embryonic connection limit lower than the TCP SYN backlog queue on the server that you want to protect. Otherwise, valid clients can nolonger access the server during a SYN attack.
I suppose, that the above can only be achieved, if you have an ACE for every single IP, then ?
Best regards Jesper
03-27-2013 12:33 PM
Hello Jesper,
If you want to protect thoudsands of IP's behind this ASA this is going to do it for you,
I mean you can be as specific as you want with the modular policy framework
Let's say you want to restrict SYN flood attacks to one of your SMTP servers ( In our scenario will be 10.1.1.10 that get's natted to 2.2.2.2 on the ASA)
access-list Julio permit tcp any host 2.2.2.2 eq 25
class-map SYN_Prevention_SMTP
match access-list Julio
exit
policy-map global_policy
class SYN_Prevention_SMTP
set connection per-client-embryonic-max 5
With this setup as soon as one client starts more than 5 TCP connections on port 25 to your server and the connections never get established the SYN-Cookie protection mechanism will be triggerd ( TCP intercept)
Do you follow me?
04-08-2013 12:14 AM
Hello jcarvaja
Thanks for your reply (I've been off line for a while).
I'm aware of the per-client opttion, but if you get hit by a syn-flood from 10-thounsands of (spoofed) IPs, your server(s) will be in trouble with the 'per-client-embryonic-max' option alone.
I had hoped, that the permit any access-list in the original example above, would trig a per inside IP threshold.
So, I suppose the only way to reach my objective, is to make a combination of embryonic-conn-max (the context/-box) and per-client-embryonic-max
Best regards Jesper
04-08-2013 09:35 AM
Hello Jesper,
Then you should use the maximum global statement ( that will cover all of the clients not just one)
Do you follow me?
04-11-2013 01:18 AM
Hello jcarvaja
No, I don't !
I'm operating with "inside servers" and "outside clients", and I want to protect inside servers with a generic embryonic-conn treshold per server. Limiting embryonic-conn per outside client is imho not so important since syn-flood attacks usually are distributed (and with a large amount of spoofed source IPs where syn-cookie applies)
And even if you set a global embryonic statement it applies to the box/context, not clients (acc to Eddy Duran above).
Agree ?
Thanks
Best regards Jesper
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide