Pfsense NAT security
-
What does Pfsense do with connections to specific public(virtual ip) ips which do not have a nat port forward set up?
The reason why I'm asking this is because I don't have the option yet to use rules to block everything and then manually add the allow permissions.
So I'm not using block all + exception fw rules, but I'm using–> allow all (firewall rule) with specific blocks on certain ports, protocols. (netbios,ftp,telnet etc etc etc) and have NAT forwards set-up only for the services I need.
The main question with this is, how safe are we with this setup? And what happends with connections to services,ip's or destinations which do not have a NAT Portforward set up? (Block/timeout?)
Outbound --> inbound traffic without a NAT portforward never reaches the internal machines right?
This is only possible if the inbound machine makes a connection to the outbound pc first I believe?
Anyway, the main reason to post this is to obviously find out how safe we are in this " temporary " situation and why my firewall is currently freaking out when using a program like nessus to scan our ip range and connect to all possible ip's and 1500tcp ports at once.
Our firewall is a P4 machine with 3ghz and 4gb of ram, so I'm wondering why all our services are slow as h..l or do not respond until the nessus scan is canceled.
Is this because the default behaviour of pfsense is not to block non existing nat portfowards or unknown routes? Would it be possible to configure this until I have the option to block all traffic and make rule for allow?
-
http://forum.pfsense.org/index.php/topic,7001.0.html
if you dont create a rule, per default everything gets blocked.Are you talking about NAT or the firewall?
These are two seperate things.Outbound –> inbound traffic without a NAT portforward never reaches the internal machines right?
This is only possible if the inbound machine makes a connection to the outbound pc first I believe?
I'm not sure what exactly you mean with outbound –> inbound traffic.
maybe you should read up how NAT works.
http://en.wikipedia.org/wiki/Network_Address_TranslationAnyway, the main reason to post this is to obviously find out how safe we are in this " temporary " situation and why my firewall is currently freaking out when using a program like nessus to scan our ip range and connect to all possible ip's and 1500tcp ports at once.
Our firewall is a P4 machine with 3ghz and 4gb of ram, so I'm wondering why all our services are slow as h..l or do not respond until the nessus scan is canceled.
Is this because the default behaviour of pfsense is not to block non existing nat portfowards or unknown routes? Would it be possible to configure this until I have the option to block all traffic and make rule for allow?
Given enough bandwidth on the nessus side you kind of DoS-attack your pfSense. –> Everything gets slow.
Also if you're connecting enough to actual open ports you could fill your state-table.
Take a look at the table when you're doing that.
You could increase the size of the table under the advanced options.
You could play around with the advanced firewall settings and limit the number of connection attemps/time. -
http://forum.pfsense.org/index.php/topic,7001.0.html
if you dont create a rule, per default everything gets blocked.Are you talking about NAT or the firewall?
These are two seperate things.Both actually.
fw :
I have made a rule to allow traffic from and to wan and above that rule i created block rules for the most important ports/services (telnet,netbios etc etc etc)I know this is not the way to do it, but right now I don't have the time/option to block al ltraffic and create manual exceptions. Will be able to do this soon, but for the time being.. I'm stuck with allow all and specific block rules.
NAT
My question related to nat is, if I did not set up a NAT port forward, what happends with the traffic/connection? It passes the firewall rules (if there is no block rule for that specific connetion/port) and does it ten get blocked or timed out?
In short, let's say the traffic gets past the firewall rules (since there is a rule to allow all), what happends with traffic that doesn't have a destination(no port forward setup for that current connection or "query") Does pfsense drop all connections which pass firewall and then have no nat rule? or do they get timed-out (thus causing load for the cpu/pfsense with allot of tcp conections)
I'm not sure what exactly you mean with outbound –> inbound traffic.
If there is no NAT port forward to a internal ip, the traffic from the outside world cannot find it's way to the internal ip right?
That's why most consumers with routers these days are much safer from the outside world, since they are not using port forwarding thus, all ports are "stealthed" .
Given enough bandwidth on the nessus side you kind of DoS-attack your pfSense. –> Everything gets slow.
Also if you're connecting enough to actual open ports you could fill your state-table.
Take a look at the table when you're doing that.
You could increase the size of the table under the advanced options.
You could play around with the advanced firewall settings and limit the number of connection attemps/time.I would have to do more testing to find out exactly what's causing the issue here. Need to reconfigure my nessus client. But I'm still wondering if pfsense is causing more cpu power due to the fact that traffic is being allowed by standard but has no " destination" .
-
I dont see a problem with an allow all and then blocking certain services.
It "might" be a bit slower but with the specs of your machine you posted this should never be an issue.NAT is applied before the firewall.
So if you dont forward something it should just drop and never even hit the firewall.You could think of it as two devices: an ADSL-modem-router that does NAT, and a separate machine behind it that is the firewall. If you dont forward the ports on the modem-router it never gets to the firewall.
-
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
