Pfsense NAT security
-
Ok thanks for the info.
The allow all rule has the log option set and when doing a portscan from a german website it still reports all the connections to all those ports and ip's..
NAT is applied before the firewall.
So if you dont forward something it should just drop and never even hit the firewall.I'm afraid this isn't the case..the logging of these connections shouldn't appear in my logs/syslog according do your quote above..
Logging of these connections shouldn't happen since there are no NAT port forwarding options setup for the traffic displayed in the log.. (based on your quote above again..)
Example :
08-19-2008 22:20:17 Local0.Info Aug 19 22:20:17 pf: 000091 rule 126/0(match): pass in on fxp0: (tos 0x0, ttl 42, id 23383, offset 0, flags [none], proto: TCP (6), length: 44) 81.169.188.68.42007 > 80.85.1xx.1xx.40647: S, cksum 0xb99f (correct), 4103323198:4103323198(0) win 2048 <mss 1460="">08-19-2008 22:20:17 Local0.Info Aug 19 22:20:17 pf: 000022 rule 126/0(match): pass in on fxp0: (tos 0x0, ttl 41, id 25960, offset 0, flags [none], proto: TCP (6), length: 44) 81.169.188.68.42007 > 80.85.1xx.1xx.39585: S, cksum 0xc1c5 (correct), 4103323198:4103323198(0) win 1024 <mss 1460="">08-19-2008 22:20:17 Local0.Info Aug 19 22:20:17 pf: 007999 rule 126/0(match): pass in on fxp0: (tos 0x0, ttl 51, id 46408, offset 0, flags [none], proto: TCP (6), length: 44) 81.169.188.68.42007 > 80.85.1xx.1xx.39917: S, cksum 0xb879 (correct), 4103323198:4103323198(0) win 3072 <mss 1460="">08-19-2008 22:20:17 Local0.Info Aug 19 22:20:17 pf: 011843 rule 126/0(match): pass in on fxp0: (tos 0x0, ttl 44, id 64264, offset 0, flags [none], proto: TCP (6), length: 44) 81.169.188.68.42007 > 80.85.1xx.1xx.40651: S, cksum 0xb19b (correct), 4103323198:4103323198(0) win 4096 <mss 1460="">08-19-2008 22:20:17 Local0.Info Aug 19 22:20:17 pf: 000023 rule 126/0(match): pass in on fxp0: (tos 0x0, ttl 36, id 43846, offset 0, flags [none], proto: TCP (6), length: 44) 81.169.188.68.42007 > 80.85.1xx.1xx.40064: S, cksum 0xb3e6 (correct), 4103323198:4103323198(0) win 4096 <mss 1460="">08-19-2008 22:20:17 Local0.Info Aug 19 22:20:17 pf: 000064 rule 126/0(match): pass in on fxp0: (tos 0x0, ttl 34, id 23857, offset 0, flags [none], proto: TCP (6), length: 44) 81.169.188.68.42007 > 80.85.1xx.1xx.40478: S, cksum 0xba48 (correct), 4103323198:4103323198(0) win 2048 <mss 1460="">08-19-2008 22:20:17 Local0.Info Aug 19 22:20:17 pf: 000032 rule 126/0(match): pass in on fxp0: (tos 0x0, ttl 34, id 12381, offset 0, flags [none], proto: TCP (6), length: 44) 81.169.188.68.42007 > 80.85.1xx.1xx.39566: S, cksum 0xbdd8 (correct), 4103323198:4103323198(0) win 2048 <mss 1460="">08-19-2008 22:20:17 Local0.Info Aug 19 22:20:17 pf: 000024 rule 126/0(match): pass in on fxp0: (tos 0x0, ttl 38, id 60685, offset 0, flags [none], proto: TCP (6), length: 44) 81.169.188.68.42007 > 80.85.1xx.1xx.40086: S, cksum 0xbbd0 (correct), 4103323198:4103323198(0) win 2048</mss></mss></mss></mss></mss></mss></mss>And this is from the allow all rule with the log function switched on. It shouldnt' display a connection going to 80.85.1xx.1xx on port 40478 (there is no NAT service or port forward set up for that)
By the way.. I've posted it somewhere else.. but it's such a shame the syslog out put has the port number attached directly to the ip with a period. My dns resolve function in the syslog client doesn't work :( It doesn't accept ip's with 4 periods..
-
Ok thanks for the info.
The allow all rule has the log option set and when doing a portscan from a german website it still reports all the connections to all those ports and ip's..
NAT is applied before the firewall.
So if you dont forward something it should just drop and never even hit the firewall.I'm afraid this isn't the case..the logging of these connections shouldn't appear in my logs/syslog according do your quote above..
The last poster was incorrect. You are accepting the traffic and creating state on it. The firewall then has nowhere to send it, so those connections sit in the state table until timeout (about 5 seconds for embryonic connections I think, might be 45, can't recall the default). The packet filter works just fine without NAT as you've noticed, keep that in mind going forward.
By the way.. I've posted it somewhere else.. but it's such a shame the syslog out put has the port number attached directly to the ip with a period. My dns resolve function in the syslog client doesn't work :( It doesn't accept ip's with 4 periods..
That's how pflogd logs it. We haven't touched that code.
–Bill
-
The last poster was incorrect. You are accepting the traffic and creating state on it. The firewall then has nowhere to send it, so those connections sit in the state table until timeout (about 5 seconds for embryonic connections I think, might be 45, can't recall the default). The packet filter works just fine without NAT as you've noticed, keep that in mind going forward.
Hmm.
Could you explain that a bit more indepth?
I kind of remember reading multiple times that NAT is being applied before the firewall-rules.
Like here: http://forum.pfsense.org/index.php/topic,1903.msg10976/topicseen.html#msg10976 -
The last poster was incorrect. You are accepting the traffic and creating state on it. The firewall then has nowhere to send it, so those connections sit in the state table until timeout (about 5 seconds for embryonic connections I think, might be 45, can't recall the default). The packet filter works just fine without NAT as you've noticed, keep that in mind going forward.
Ok, that makes it more clear to me and that's why it's obviously being logged in my traffic logs with the syslogger.
Since it is filling up the actual tables with this information/connection even though it has no destination it would be better to drop or block these packets.
Because if I were to scan/connect to 2500 ports on a complete ip range(with hosts), 2500 states are created even though they don't do anything.
Would it be possible to make a rule for this " issue"? I haven't found the timeout option for these either.
That's how pflogd logs it. We haven't touched that code.
Could I alter this by any chance? Is this easy to do? I created a bounty for this but nobody replied.
-
The last poster was incorrect. You are accepting the traffic and creating state on it. The firewall then has nowhere to send it, so those connections sit in the state table until timeout (about 5 seconds for embryonic connections I think, might be 45, can't recall the default). The packet filter works just fine without NAT as you've noticed, keep that in mind going forward.
Hmm.
Could you explain that a bit more indepth?
I kind of remember reading multiple times that NAT is being applied before the firewall-rules.
Like here: http://forum.pfsense.org/index.php/topic,1903.msg10976/topicseen.html#msg10976Sure.
Inbound packet path to the kernel
NAT -> Filter -> kernel
Outbound packet path from the kernel
kernel -> NAT -> Filter
If you don't have a NAT entry that matches a packet, it'll still get to the filter. But for the purpose of filtering NAT'd connections, you need to understand that the filter is applied AFTER NAT, therefore a connection to a virtual address on the outside of your firewall will get NAT'd first, so the filter policy has to match the post NAT packet. Primarily, it's just important to know the order of the actions being applied to your traffic.
–Bill
-
Makes sense :)
Thank you for the explanation. -
Thanks for the info!
Unfort, the main issue I'm having now is that I can easiliy " kill " or ddos my pfsense with two Nnmap scans on a single public ip (not even selecting our whole public ip block).
The cpu usage stays at 2procent max.. throughput is only 1/2mb/sec and our wan is being used for 500kb/sec.
We have a 100mbit wan (fiber) and a 2GB/P43ghz machine.. so the hardware isn't the problem.
With further research, the whole problem right now is that the states fill up really fast (it seems each tcp port it scans with Nnap) get's a seperate entry in the table.
Let's say I scan 5000 tcp ports, twice with the port scan utilities on the internet.. the state tables are full :(
See images..(scan done at aprox 18.00hrs)
States..
Cpu usage..it's doing nothing…
States..in zabbix (our monitoring software)
Wan traffic (only 70/80kb/sec being recieved..so not the wan connection)
And bang.. the firewall stops taking other traffic/connections and thus causing a non working network..even our website is unreachable or really slow.
So anybody could annoy us by running Nmap, Nessus or an online port scanner and set it to scan 5000 ports or more.. and cause us to go down.. Major issue for us :(.
Now I could simply add another zero to the max states.. but I dont' think that would be a very good/safe idea..
To me this looks like a major feature request or maybe even a bug if you can't fix this? (correct me if I'm wrong).
If the firewall gives out one entry in the state table for each port which is scanned from the outside world, the firewall easily slows down.. or becomes unreachable..
Anybody have an idea on how to solve/prevent this without increasing the amount of states? In other words.. wouldn't it be so much better to drop packets instantly if they have no NAT rule set up?
-
The 'Advanced Options' tab at 'Firewall: Rules: Edit' hides some useful stuff for this.
You can alter:- Simultaneous client connection limit
- Maximum state entries per host
- Maximum new connections / per second
- State Timeout in seconds
there.
That should solve this problem for you.
-
Combined with what jahonix posted you can safely increase the statetable-size.
@http://www.pfsense.org/index.php?option=com_content&task=view&id=52&Itemid=49:
Large state tables - State table entries require about 1 KB of RAM each. The default state table, when full at 10,000 entries, takes up a little less than 10 MB RAM. For large environments requiring state tables with hundreds of thousands of connections, ensure adequate RAM is available.
It's not a problem to increase the statetable.
Just make sure you dont run out of ram. -
The 'Advanced Options' tab at 'Firewall: Rules: Edit' hides some useful stuff for this.
You can alter:- Simultaneous client connection limit
- Maximum state entries per host
- Maximum new connections / per second
- State Timeout in seconds
there.
That should solve this problem for you.
Thanks, didn't know this, but will this have any effect if NAT gets done first (and that's where the states max out with..)?
If these options are the answer to the problem, what options(amount/setting) do you suggest I use?
Also, maybe a stupid question.. let's say I use one of the settings..if I leave the rest blank.. it stays on the defaults I suppose?
Combined with what jahonix posted you can safely increase the statetable-size.
@http://www.pfsense.org/index.php?option=com_content&task=view&id=52&Itemid=49:
Large state tables - State table entries require about 1 KB of RAM each. The default state table, when full at 10,000 entries, takes up a little less than 10 MB RAM. For large environments requiring state tables with hundreds of thousands of connections, ensure adequate RAM is available.
It's not a problem to increase the statetable.
Just make sure you dont run out of ram.Although we have plenty of ram.. I'm still worried about the fact, doing a portscan on our ip block (50 public ip's) and scanning 5000 ports for each public ip would be 50x5000 states..=firewall overload..
The settings in the rules are useless if they are not used since the rules ares effected AFTER the NATing..
-
The 'Advanced Options' tab at 'Firewall: Rules: Edit' hides some useful stuff for this.
You can alter:- Simultaneous client connection limit
- Maximum state entries per host
- Maximum new connections / per second
- State Timeout in seconds
there.
That should solve this problem for you.
Thanks, didn't know this, but will this have any effect if NAT gets done first (and that's where the states max out with..)?
Generically, a state gets created for the NAT (no state for you right now) and a state gets created for the filter.
Although we have plenty of ram.. I'm still worried about the fact, doing a portscan on our ip block (50 public ip's) and scanning 5000 ports for each public ip would be 50x5000 states..=firewall overload..
The settings in the rules are useless if they are not used since the rules ares effected AFTER the NATing..
In your case you are allowing the traffic and generating state. We're a little more dynamic in the default state table size in 1.3 - I don't remember the formula offhand, but it scales with memory (I think it's 10% of ram). One thing you can do in your rule is limit the number of states a given address can use - just set the "Maximum state entries per host" variable in your "allow all" rule that you have on the wan to something "reasonable" (I'll leave it to you to determine what "reasonable" is). That will effectively restrict the amount of damage an nmap scan can do.
–Bill
-
So Maximum state entries per host option is sufficient?
Can I leave the other fields blank?
Regarding the amount, could you give me a suggestion on what to use? I don't want to limit any services running on our wan side.. what would be a reasonable amount?
-
So Maximum state entries per host option is sufficient?
Can I leave the other fields blank?
Regarding the amount, could you give me a suggestion on what to use? I don't want to limit any services running on our wan side.. what would be a reasonable amount?
Correct on the first two questions. The last really is site specific. It could be two, it could be a hundred, it could be more shrug. That's why I said, whatever is reasonable for you. I don't know what type of traffic you see.
–Bill
