Hello,
I have notice that traffic from orange to green was opened for 3 ports 80, 443 and 500 even though I have rule that blocks orange → any , it only happen if I enable another rule (under block orange → any) the ports will be opened to green and red until I do disable the second rule and either reboot the firewall or run /etc/rc.d/init.d/firewall restart
it seems that only happens when Enable SYN Flood Protection (TCP only) options is checked.
Your firewall rule seams wrong.
What are you trying to do?
I want to allow connection from orange → red on 80 and 443 but once this rule activeted it will allow 443, 80 and 500 to red, green and all firewall ips and wont be blocked unitl reboot…
Orange to red is open by default
just noticed they added this to the bottom of the firewall rule page.
I have changed the default to drop but even if it is allow the rule in the pic should not open the ports to green network
Its because your destination is the input of the network stack.
You have to set up DMZ network to port forward the address and the dmz server should use a public dns,
See these instructions:
when i activate the same rule with SYN Flood Protection (TCP only) option is disable it work as expected (only orange → red allowed). i was only testing I am not forwarding any port.
so when SYN Flood Protection enabled any server in orange can reach any ip within my network (green, blue, green and all firewall ips) on ports 80, 443 and 500 by the way I do not have any rule with port 500
UDP Port 500 can be/is IPsec. Technically the spec also allows for TCP:500. If you are NAT’d, IPsec also uses UDP:4500 and the spec allows for TCP:4500.
Are you using IPsec?
Yes i have ipsec enabled but i do not think it is related it seems to me there is a bug with SYN protection . If i enable the rule in the pic any machine can reach any machine in the network to ports 80, 443, 500 even if there is no services running on target machine.
I will stop ipsec and all other services and test again
It depends what you mean by any machine in network.
Without any firewall rules in place any machine in the Green network can contact (for example via ping) any machine in Blue or Orange.
That is expected and how it is designed. See the wiki
https://www.ipfire.org/docs/configuration/firewall/default-policy#default-zone-ruleset
However any machine on Green or on Blue cannot contact any machine on Green.
I tested and confirmed that this is as expected on my vm testbed with green, blue and orange networks.
I then installed your firewall rule to test it, even though as already said Orange can access Red by default without a firewall rule in place. I had to presume that in your service group called HTTP-HTTPS you only added the ports 80 and 443.
I also put it at position 1 so that it would be the first rule to trigger on anything
I then tested access to a Green machine from a Blue and Orange machine via ping and in all cases there was 100% packet loss.
I then also enabled SYN protection in that rule and then re-tested contact from the Blue and Orange machines to a Green machine and again 100% packet loss. Nothing getting through.
So I am unable to reproduce what you are describing.
Please be more specific and when you say that any machine can contact any other machine please specify from which zone to which other zone.
Also when you say you can contact via port 80, 443, 500 on the other machines even if those services are not on those machines, how are you testing this port 80 etc contact.
In my test only ports 80,433 and 500 are open. Ping is 100% loss i was using nmap to check open ports
I mean any machine from different zone can reach any mahcine between zones for example from orange → green or blue → orange on the 3 ports
Okay, I will give that a test.
Hi @ezyz
Okay, we understand what is happening here now.
When the SYN Flood Protection is turned on then for any inputs coming with the ports specified in the rule using SYN Flood Protection a SYN Cookie will be sent out. The response to that cookie by the client is what defines if it is a normal packet traffic communication or if it is a SYN Flood attack.
The default scan used by nmap is the TCP SYN (stealth) which sends out a SYN packet and then basically does not respond further, which basically has the hallmarks of the start of a SYN Flood attack if more were to come.
In your case the rule you used had ports 80 and 443 specified in it which made the SYN Flood protection respond on those port scans, although the ports are not actually open.
This can be confirmed by running nmap with the -Pn option. This makes nmap use the TCP FIN, SYN, ACK scan which checks for a complete response, which won’t come because the port is not open. That is not usually used for scans because it takes longer as it is testing out the whole back and forth response which includes waiting for a certain time before deciding there is no answer coming.
What was found to be a bug, so thanks very much for flagging this issue up, is that when the SYN Flood detection is unchecked the ports stay being shown by nmap as responding. It turned out that the SYN Flood protection option was not being flushed in the firewall rules code after the option had been unchecked.
A simple patch fix of adding the SYN Flood rule to the flush section has been created and I have tested it and confirmed that when the SYN Flood protection in unchecked then you no longer see the nmap seeing a response (not an open port) due to the SYN Cookie used in the SYN Flood protection.
I am happy to help improving this project and thank you all for the great work.
I also have done a test using curl on a machine hosting HTTP server, even though there was a rule blocking port 80. I confirm that it reached the server and received a response.
I found that after update 189 adding new firewall, SYN Flood Protection option will be enabled for all other active rules (not sure if this only happing in update 189).
only if the new rule is above the others for example adding rule at position 1
