ICMP and UDP problem with pfsense
-
Hi everyone,
i think that it is a known problem, that you can initiate traffic from one
(forbidden) direction if traffic is generated from the allowed direction for
ICMP and UDP.example:
FW: block all from WAN, allow all from LAN1. with ICMP
ping from LAN to WAN Port is allowed an working, but you can ping also
from WAN to LAN because it is allowed by the state
2. with UDP
same as 1. ! you can initiate traffic from WAN to LAN by using the same
Portnumbers from WANThis is because the firewall states matches also the incoming traffic by ip
and portnumber (at UDP).is there a way to prevent this behaviour ?
ICMP can be blocked by detecting the number of the mode (request, reply).
UDP is more difficult, but there should be a timer that stops the traffic if
no traffic is initiated from LAN.Any solution for this ?
-
UDP states are removed if inactive. UDP is a stateless protocol so timers are the only way to fuzz statefulness there.
I'm failing to see what kind of attack scenario you're dreaming up here. Most source ports are randomized. The odds of someone connecting back to that port and getting something useful are quite slim.
-
Hi,
yes, with UDP you are right. Sourceports are random and you have to know the UDP ports
to start this kind of attack.ICMP is easy to handle for everyone. You can send big ICMP packets from WAN to LAN, so
this can affect the PC on the LAN. Or between other Interfaces.I checked this behaviour with a small sonicwall TZ200/210 :
With UDP, there is exactly the same behaviour as with pfsense.
But with ICMP, no packets could be send from WAN to LAN.TMG2010, ASA, ect. blocks complety this forbidden traffic. Maybe that this FW have additional
filters …. But i do not want to compare pfsense with ASA ! -
But you still have to ping from the LAN to that host on the WAN to make it happen - do your users make a habit of pinging rouge sites that would send pack large ICMP packets?
Restrict your ICMP rule to only allow ICMP echo from LAN users out, and I still fail to see what the actual exploitable problem is in a real-world scenario.
-
i think, that it makes no sense to discuss the users habit. in a real world scenario all traffic should be blocked, which is not explicit allowed. now in this case we have some technical reasons that this kind of traffic is not blocked by the default rule (block all from WAN). so far i have no problems with that because i have an explanation.
but the important thing is: Is it possible with pfsene to eliminate such kind of traffic ?
- maybe a configuration hint ?
- workaround ?
- is it caused by the design of pfsense / FreeBSD … ?
thanks for your support.
-
You can add block rules for icmp and udp if you like, make sure that those are above allowing rules
-
hi
the problem is a little bit diffrent. do the following:
1. make 2 rules:
- allow all from LAN > WAN
- block all from WAN > LAN
2. start to ping from a WAN-PC to a LAN-PC with -t
3. ping fails
4. start a ping from LAN > WAN
5. ping is successfull
6. ping under 3. is successfull also
7. stop ping from WAN > LAN
8. wait and watch until the statetable changes
9. ping again from WAN > LAN, ping fails…you can add a rule on WAN to block ICMP completly - but this will not help.
you can do the same with UDP traffic if you use the same port-numbers.
This is because of the statetabel for ICMP and UDP.
With TCP everything is perfect.Now it is up to you to decide if this behaviour is ok for you or not. some admin say,
that the risk is minimal because this occurs only between two specific hosts.
other admin dont like this, because it does not fit with the block all rule from
WAN.the only important things for me is to know:
-
Is it possible with pfsene to eliminate such kind of traffic ?
(if not, i will still use pfSense for SOHO and private DSL) -
other FW (more expensive) can handle this. what is the reason ?
-
-
I find it very hard to believe that other firewalls would block that UDP traffic.
ICMP is another question.
However, in both cases, the issue is not with pfSense, but with the underlying packet filter software, pf.
It's been brought up before, and it largely a non-issue. You are really stretching things to create a problem where no legitimate security risk exists. http://freebsd.1045724.n5.nabble.com/PF-quot-keep-state-quot-for-ICMP-td4183717.html
If you want to "block" this then don't let them ping out, then no state would be created.
-
thanks for support
-
As i stated before create rules for blocking icmp and udp if you think that those are too dangerous trafic.
On lan interface
block icmp * * * *
block udp * * * *
allow whatever you want and where ever you want.After that even ping from lan to wan isn't possible and thusfore no state is going to exist at all to exploit
-
That will not block what he's talking about. It will prevent the issue from ever happening, but it also blocks the traffic it sounds like he wants to allow.
-
Cat going around a table..
I tried to offer pre-emptive solution. Well, can't please everyone ;)
