Re: [j-nsp] SRX: rate-limiting source NAT sources
You can limit flows per individual source IP (not NAT ports) using UTM https://www.juniper.net/techpubs/en_US/junos12.1/topics/reference/configuration-statement/security-edit-limit.html You'll need a UTM license. And if you are doing NAT on branch SRX, UTM is supported only on high-memory branch SRX boxes. Thanks Alex - Original Message - From: Jonathan Lassoff j...@thejof.com To: juniper-nsp@puck.nether.net Sent: Monday, October 29, 2012 9:55 PM Subject: [j-nsp] SRX: rate-limiting source NAT sources So, I'm working on tuning an SRX deployment and am wondering if something is possible. This deployment is doing a lot of source NAT for a wide variety of endpoints as they egress out to the Internet. Pretty vanilla configuration. Specific sources are mapped via NAT rules to specific egress IPs (for IP filtering in some places, outside of the SRXes in question). And once in a while, some endpoint will have a legitimate need to open up *many* connections (and then NAT states) that pass over this SRX deployment. Unfortunately, the rate of connection establishment relative to the application timeouts means that these heavy users can use up all of the ephemeral ports, blocking new flows from becoming established. We've been playing a bit of whack-a-mole, assigning more IP space to the various source NAT pools, but would like to find a more proper solution. So, my question is this: is there any mechanism anyone knows of to rate-limit or block-past-a-threshold a source NAT source if it starts making too many connections? I don't see anything obvious in the SRX documentation, so I figured I'd ask here for pointers. Right now, it's way to easy for one bad actor (malicious or benevolent) to max out a source NAT pool. Cheers, jof ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX: rate-limiting source NAT sources
You could limit the number of sessions each ip address in your internal zone can initiate. Here is an example on limiting an ip address in the zone trust to only be able to create 1 session. set security screen ids-option session-limit limit-session source-ip-based 1 set security zones security-zone trust screen session-limit There should be no license needed for this feature.Here is how to configure this: http://www.juniper.net/techpubs/en_US/junos12.1/topics/example/denial-of-service-firewall-source-based-session-limit-setting-cli.html -- Hans Kristian Eiken 2012/10/29 Jonathan Lassoff j...@thejof.com So, I'm working on tuning an SRX deployment and am wondering if something is possible. This deployment is doing a lot of source NAT for a wide variety of endpoints as they egress out to the Internet. Pretty vanilla configuration. Specific sources are mapped via NAT rules to specific egress IPs (for IP filtering in some places, outside of the SRXes in question). And once in a while, some endpoint will have a legitimate need to open up *many* connections (and then NAT states) that pass over this SRX deployment. Unfortunately, the rate of connection establishment relative to the application timeouts means that these heavy users can use up all of the ephemeral ports, blocking new flows from becoming established. We've been playing a bit of whack-a-mole, assigning more IP space to the various source NAT pools, but would like to find a more proper solution. So, my question is this: is there any mechanism anyone knows of to rate-limit or block-past-a-threshold a source NAT source if it starts making too many connections? I don't see anything obvious in the SRX documentation, so I figured I'd ask here for pointers. Right now, it's way to easy for one bad actor (malicious or benevolent) to max out a source NAT pool. Cheers, jof ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
Re: [j-nsp] SRX: rate-limiting source NAT sources
30.10.2012 01:55, Jonathan Lassoff wrote: Specific sources are mapped via NAT rules to specific egress IPs (for IP filtering in some places, outside of the SRXes in question). And once in a while, some endpoint will have a legitimate need to open up *many* connections (and then NAT states) that pass over this SRX deployment. Unfortunately, the rate of connection establishment relative to the application timeouts means that these heavy users can use up all of the ephemeral ports, blocking new flows from becoming established. Looks like session-limit SCREEN options is what you need: http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/security/software-all/security/topic-43929.html It's applied per-zone, so if you want to apply different limits to different NAT pools, you need to put users of different pools into different zones. Otherwise you only can have a single setting for all (maybe not that big issue). Older JUNOS version (10.1 at least, don't know when it's changed but looks like it did) applied source and dst-limits in a bunch, so if you needed to only limit per-src you also had to explicitly configure dst-limit to the maximum number (which is platform dependent) otherwise it would be applied with a very low default value. As of my quick check with 11.4, looks like it is changed and you can apply per-src and don't care per-dst, but I might be missing something, so you'd rather test it. It's maybe a good idea to also limit the rate of new sessions per second with tcp-syn knob. Be careful, most default screen option values are for server-side protection and very very rough, so completely inapplicable in you case and must be adjusted for each particular scenario. Another thing you might find useful is called aggressive-aging: http://www.juniper.net/techpubs/en_US/junos11.4/information-products/topic-collections/security/software-all/security/index.html?topic-60842.htm ___ juniper-nsp mailing list juniper-nsp@puck.nether.net https://puck.nether.net/mailman/listinfo/juniper-nsp
