Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 11 replies
  • Subscribers 2 subscribers
  • Views 5576 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

9.202-33: TCP session resumed BY REPLY PACKET after UTM reboot

ondrej.holas
Moved from general discussion as this is firewall-specific problem; original thread was https://community.sophos.com/products/unified-threat-management/astaroorg/f/51/t/22262

Situation: Connect to SSH server through UTM and then reboot UTM. The SSH server has configured TCP keepalives, so it is expected that after UTM reboot, the keepalive packet from SSH server will be rejected and the TCP session will die.

But after reboot, the traffic is as follows: 

utm:/root # tcpdump -i eth0 ip host *SSH_SERVER*

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes

08:15:48.009572 IP *SSH_SERVER*.ssh > *CLIENT*.64737: Flags [.], ack 1290682868, win 228, length 0

08:15:48.011201 IP *CLIENT*.64737 > *SSH_SERVER*.ssh: Flags [.], ack 1, win 16570, length 0


(eth0 is facing towards the SSH server)
The keepalive ACK packet (green), instead of been discarded, silently resumes the session, client responds with another ACK (red) and the session continues well. As seen in ip_conntrack, new session appears: 

utm:/root # cat /proc/net/ip_conntrack | grep *SSH_SERVER*

tcp      6 290 ESTABLISHED src=*SSH_SERVER* dst=*CLIENT* sport=22 dport=64737 packets=1 bytes=40 src=*CLIENT* dst=*SSH_SERVER* sport=64737 dport=22 packets=1 bytes=40 mark=528384 use=2


So from netfilter perspective, the session is established in REVERSE DIRECTION, as if it were ACCEPTed by mirrored rule [:O]

And finally, there's no record in packetfilter.log.

I'm still calm, since my UTM is surrounded by Cisco 87x routers with CBAC, but the statefulness of firewall inside UTM is now disputed for me. The strange thing in iptables configuration is that eth0 has some rules (mostly marking) in primary filter chains (INPUT, OUTPUT, FORWARD) while the other interface (eth1) has not such.

No NAT. "TCP strict" turned on.

Has anyone logical explanation of this behavior?


This thread was automatically locked due to age.
  • 0
    Ondrej, my guess would be that there's a firewall rule that allows outbound traffic from your internal SSH server.

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Bob, there's no such rule. The SSH server is on the internet and it is present only in destination side of some rules. It is neither itself as a source nor matching source side in any wider rule.

    And hypothetically, if there were such rule, UTM should not accept that session by ACK packet, if "Strict TCP" is turned on.
  • 0
    OK, I had misunderstood your explanation.  Yeah, that does look like a potential bug.  Still, I don't understand how conntrack knew where to send that ack - it's as if there was no reboot of the UTM.  Can you confirm from the logs that a reboot took place?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Bob, the box surely rebooted, as seen in "last".

    Where to send that ack: this UTM does not perform any NAT, so it does not need active conntrack entry to forward that reply packet, UTM simply forwards the packet by destination IP address (which is untouched by UTM in this scenario).

    My further ivestigation showed iptables rule responsible for accepting the reply packet: 

    -A FORWARD ! -d 224.0.0.0/4 -m confirmed -j ACCEPT


    This can be seen in rule counters, green rules were inserted manually, state just after keepalive ACK/ACK: 

    [1:40] -A FORWARD -s *SSH_SERVER*/32 -m confirmed

    [1:40] -A FORWARD -s *CLIENT*/32 -m confirmed    

    [2:80] -A FORWARD ! -d 224.0.0.0/4 -m confirmed -j ACCEPT


    So the problem seems to be somewhere inside "confirmed" match/"CONFIRMED" target logic.
  • 0
    Ondrej, do you have a paid license that will allow you to submit a bug report to Support?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    I have home license only, no paid license.
  • 0 in reply to ondrej.holas
    Confirmed in lab on test VM with fresh install of UTM 9.202-33 and minimal configuration.

    192.168.20.2 = SSH server
    192.168.21.2 = client

    After UTM reboot:

    utm-test:/root # iptables-save -c | grep -E "FORWARD.+confirmed" ; cat /proc/net/ip_conntrack | grep 192.168.20.2
    [0:0] -A FORWARD ! -d 224.0.0.0/4 -m confirmed -j ACCEPT


    Keepalive packet from SSH server:

    19:21:17.107553 IP 192.168.20.2.22 > 192.168.21.2.54617: Flags [.], ack 1579353482, win 1563, options [nop,nop,TS val 926336 ecr 774430], length 0
    19:21:17.108358 IP 192.168.21.2.54617 > 192.168.20.2.22: Flags [.], ack 1, win 2389, options [nop,nop,TS val 924444 ecr 776322], length 0


    Final state:

    utm-test:/root # iptables-save -c | grep -E "FORWARD.+confirmed" ; cat /proc/net/ip_conntrack | grep 192.168.20.2
    [2:104] -A FORWARD ! -d 224.0.0.0/4 -m confirmed -j ACCEPT
    tcp      6 292 ESTABLISHED src=192.168.20.2 dst=192.168.21.2 sport=22 dport=54617 packets=1 bytes=52 src=192.168.21.2 dst=192.168.20.2 sport=54617 dport=22 packets=1 bytes=52 mark=528384 use=2


    UTM must be configured with no NAT/masquerading. With masquerading in place, packet from outside server is replied by RST (expected behavior).
  • 0
    With masquerading in place, packet from outside server is replied by RST

    Ahhh - conntrack wasn't involved!  So, it's not clear that this is a bug.  What firewall rules do you have between 192.168.20.0/24 and 192.168.20.1/24?

    Cheers - Bob
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    Bob, as far as I know netfilter/iptables, conntrack is involved always, including configuration without NAT/masq. (To be exact: You must explicitly use "notrack" target to exclude packet from connection tracking; however, in UTM there's only one rule using "notrack" for localhost communication.)

    There is only one rule in the lab: 192.168.21.2/32 -> 192.168.20.2/32 : 22/tcp

    There's no rule in UTM config allowing communication from SSH server to client.
  • 0
    Hi, would enabling the strict TCP options be a solution or workaround for this?

    Barry
Unfiltered HTML