Net firewall is not statefull

Home Forums Discussions Support Portal Net firewall is not statefull

This topic contains 9 replies, has 3 voices, and was last updated by  Vadim Smirnov 11 years, 4 months ago.

Viewing 10 posts - 1 through 10 (of 10 total)
  • Author
    Posts
  • #5037

    alienlove
    Participant

    Dear all,

    I’ve a problem with NetFirewall: setting “3rd Level Sthealth Security” everything work well without adding any rule and the firewall is stateful as I expect.
    On the contrary, using “high security level” i have to add a rule to go out

    (e.g tcp from any:any to any:80 for http). If I tourn on the option ” This rule should be applied for all packets” (for incoming/outgoing) I can brows but the firewall isn’t stateful!

    With simple scan (by nmap) using tcp source port 80 from an another machine I am able to bypass the firewall!!!!!!!!!

    It seems to me quite strange since the fireewall is provided as “statefull firewall”…..
    Have you any ideas?
    Thanks a lot

    All the best

    Andrea

    #6079

    Vadim Smirnov
    Moderator

    Well, you are right, but this is not about statefull inspection but the way the rules were originally implemented. IN means incoming packets, OUT means outgoing packets (in current implementation specifying only IN or only OUT for TCP protocol is senseless) and it is not exactly the same as IPFW rules where IN means incoming connection, OUT means outgoing connection for TCP. I agree that this may confuse a bit and probably it makes sense to change this behavoiur in order to avoid missunderstandings. Thanks for pointing this.

    The rule you have created allows any system connect your port (from any port) 80 and connecting any your local port from port 80 what really breaks any security. Basically if you want to allow any kind of outgoing connections you are supposed to use on the the Stealth Security levels and create rules to drop undesired outgoing connections and may be some rules to open local ports if you also work as server. High Securty level was designed for servers which are supposed not to go outside world but just open some local ports to provide services for their users.

    #6080

    alienlove
    Participant

    @SerpentFly wrote:

    Well, you are right, but this is not about statefull inspection but the way the rules were originally implemented. IN means incoming packets, OUT means outgoing packets (in current implementation specifying only IN or only OUT for TCP protocol is senseless) and it is not exactly the same as IPFW rules where IN means incoming connection, OUT means outgoing connection for TCP. I agree that this may confuse a bit and probably it makes sense to change this behavoiur in order to avoid missunderstandings. Thanks for pointing this.

    The rule you have created allows any system connect your port (from any port) 80 and connecting any your local port from port 80 what really breaks any security. Basically if you want to allow any kind of outgoing connections you are supposed to use on the the Stealth Security levels and create rules to drop undesired outgoing connections and may be some rules to open local ports if you also work as server. High Securty level was designed for servers which are supposed not to go outside world but just open some local ports to provide services for their users.

    Dear SerpentFly, first of all thanks for your answer 🙂
    Actually I think we just had a misunderstanding.
    Our goal is to let only everything I want go out (e.g. HTTP and DNS just to browse over the Internet) and let go in only the answers from the servers I opened a connection to, just as statefull firewalling has to work. I know that DNS works on UDP and actually UDP doesn’t provide any type of connection (so talking about the state of connection on a udp comunication is not properly correct) but other statefull firewalls I have tried provide some kind of support for udp sessions (e.g. the connection tracking module of Netfilter/Iptables).
    After reading your answer we did as you suggested: we put the FW on 3rd level security and just added the rules for HTTP and DNS, as in the images below.

    HTTP works as expected, but DNS doesn’t, and in the log it’s reported the outgoing packets are processed by our own rules, but the answers by the “general security”: ingoing http is allowed as expected, but dns (we need to browse) is blocked by general security.

    Do you have any ideas about it? Maybe it’s because NetFirewall doesn’t provide any support for connection tracking on udp communications?

    Obviously we cannot add a rule allowing every ip address to contact me on my 53 udp port, even thougth in this way I can browse: that would be a huge hole in my security walls! A scan using nmap with 53 udp port as the source port would be allowed 😯

    (if I permit 21/TCP out and I block all the other outgoing traffic passive ftp doesn’t works)

    Have you any ideas about it?

    Thanks a lot for your attenction

    Andrea

    #6081

    Kon
    Participant

    We will improve our internal interface to avoid such problem.

    To allow incoming DNS, please turn off DNS inspection in Option menu.

    Regards,
    Andrew

    #6082

    Vadim Smirnov
    Moderator

    The new version of NeT Firewall 2.3.2.3 has been released. We have updated the interpretation of IN/OUT keywords for TCP protocol, now it is applied to incoming/ougoing connections instead of incoming/outgoing packets. For other protocols IN/OUT interpretation remains the same. This should help to avoid missunderstandings in the future.

    #6083

    alienlove
    Participant

    @SerpentFly wrote:

    The new version of NeT Firewall 2.3.2.3 has been released. We have updated the interpretation of IN/OUT keywords for TCP protocol, now it is applied to incoming/ougoing connections instead of incoming/outgoing packets. For other protocols IN/OUT interpretation remains the same. This should help to avoid missunderstandings in the future.

    Thank you for your answers

    I tryed this new version (2.3.2.3) and now the connection tracking on udp communications (DNS) works too 😉 .

    there’s still the problem about the passive ftp . 🙁

    With the FW on 3rd level security if I permit 21/TCP out and I block all the other outgoing traffic passive ftp doesn’t work.

    How can I solve this problem?

    Thanks a lot for your attenction

    Andrea

    #6084

    Vadim Smirnov
    Moderator

    With the FW on 3rd level security if I permit 21/TCP out and I block all the other outgoing traffic passive ftp doesn’t work.

    FTP active mode uses two TCP sessions, one on server port 21 is a control channel and another data channel on server port 20. Control channel is established by client and data channel is established by server as a response on PORT command.

    In passive mode both control and data channels are established by client. Data channel uses arbitrary ports >1024 on both server and client sides. In you case blocking all outgoig connections except port 21 does not allow client to establish data channel and FTP in passive mode does not work.

    #6085

    Vadim Smirnov
    Moderator

    P.S. Some FTP relative information http://slacksite.com/other/ftp.html

    #6086

    alienlove
    Participant

    @SerpentFly wrote:

    With the FW on 3rd level security if I permit 21/TCP out and I block all the other outgoing traffic passive ftp doesn’t work.

    FTP active mode uses two TCP sessions, one on server port 21 is a control channel and another data channel on server port 20. Control channel is established by client and data channel is established by server as a response on PORT command.

    In passive mode both control and data channels are established by client. Data channel uses arbitrary ports >1024 on both server and client sides. In you case blocking all outgoig connections except port 21 does not allow client to establish data channel and FTP in passive mode does not work.

    Dear SerpentFly
    first of all I excuse for I’m late on answering you, I was busy with university: my porfessor Federico Simonetti of University of Milan says hello to you 🙂
    What I’d like to ask you is: is there any way to make NetFW look at the PORT command in the control connection on 21 TCP port to automatically open the port the server wants to use to transfer data? As an example, Netfilter/IpTables can do it, and other commercial firewalls as well.

    Thank you so much for your attention
    Andrea

    #6087

    Vadim Smirnov
    Moderator

    first of all I excuse for I’m late on answering you, I was busy with university: my porfessor Federico Simonetti of University of Milan says hello to you

    My warm regards to Federico, I hope he is doing well 🙂

    What I’d like to ask you is: is there any way to make NetFW look at the PORT command in the control connection on 21 TCP port to automatically open the port the server wants to use to transfer data? As an example, Netfilter/IpTables can do it, and other commercial firewalls as well.

    Yes this is possible but, heh, not implemented yet and the only known solution is opening port 20 for everyone. 😕 Dynamic rules (temporary rules created under certain conditions) are planned to be implemented, but it still needs time. In the meantime only Stealth 3rd level takes into account FTP protocol realization details so outgoing FTP can work in active mode.

Viewing 10 posts - 1 through 10 (of 10 total)

You must be logged in to reply to this topic.