Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 6 replies
  • Subscribers 3 subscribers
  • Views 26808 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

NMAP scan find hosts in other VLAN

Jas Man

Hi folks,

there was a question in in the German part of this forum regarding the accessibility between two VLANs, which are configured on the UTM. Therefore I scanned my privat network (VLAN1) from a host (192.168.20.12) in my guest network (VLAN2) with NMAP.

There is no rule that allows the access from VLAN1 to VLAN2 or vice versa. VLAN2 has configured DHCP, DNS and the HotSpot option. Nothing else like WebProxy or Protection is configured for this VLAN.

Nevertheless NMAP showed me some (not all!) of my online hosts in VLAN1 when I start a scan. The hosts are my mobile phone, my NAS, a switch (one of two) and a router. All except the mobile phone have port 80 open, and all clients have a Linux distribution running. Two Windows clients in the same subnet were not found.

I opend the firewall live log during the scan. I saw that the scan client in VLAN2 sends a request to every IP on port 80 which where ALL dropped. But the named clients answered to this dropped packets and the answer is also dropped according to the live log.

Then I started Wireshark on the scan client, and filtered the packets to the IP of my switch (192.168.10.6) during a NMAP quick scan. I saw that the scan sends a ACK packet on TCP/80 to the client (No 3), and a RST,ACK comes back (No. 5). I'm not sure if this packet comes from the client or from the UTM, but this shows NMAP that there is a client online. The source MAC address of the response is from the LAN IF of my UTM.

Now I'm wondering if this is a normal behaviour, or if I found a bug, or a function of the UTM is responsible for this. I have already disabled the HotSpot, WebProxy, IPS and ATP, but had no effect.

Thank you!

Jas



This thread was automatically locked due to age.
Parents
  • 0

    Alone among the logs, the Firewall Live Log presents abbreviated information in a format easier to read quickly.  Usually, you can't troubleshoot without looking at the corresponding line from the full Firewall log file.  Please post the lines corresponding to the two above.

    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

    Hi Bob,

    here are the corresponding lines from the log file:

    2016:06:19-15:14:29 jasnet ulogd[27967]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth1.2" outitf="eth1" srcmac="00:24:d7:2c:36:1c" dstmac="fc:aa:14:e2:bf:f1" srcip="192.168.20.12" dstip="192.168.10.6" proto="6" length="44" tos="0x00" prec="0x00" ttl="57" srcport="52523" dstport="80" tcpflags="SYN"


    2016:06:19-15:14:29 jasnet ulogd[27967]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60002" initf="eth1" outitf="eth1.2" srcmac="b0:7f:b9:39:91:93" dstmac="fc:aa:14:e2:bf:f1" srcip="192.168.10.6" dstip="192.168.20.12" proto="6" length="44" tos="0x00" prec="0x00" ttl="63" srcport="80" dstport="52523" tcpflags="ACK SYN"

    b0:7f:b9:39:91:93 is the Switch, fc:aa:14:e2:bf:f1 is the LAN adapter of my UTM.

    Jas Man

  • 0 in reply to Jas Man

    I see what you mean...  If the firewall stopped the SYN packet before it could reach .10.6, how did .10.6 know to ACK the packet?  I have no idea unless there's a "leak" in your VLAN switch.  What happens if you unplug the UTM?

    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 did some more researchs yesterday and I think it's not the switch which leaks the packets into the other VLAN. The packets came all from the MAC address of my UTM.

    My test scenario:

    - NMAP client with Wireshark in the guest VLAN2 (192.168.20.0/24) with IP address 192.168.20.12. The client had authenticated to the Hotspot to get access to the Internet.
    - Rasperry PI with tcpdump in the main VLAN1 (192.168.10.0/24) with IP address 192.168.10.4.

    Before I started I scanned the RaspberryPI with a NMAP Quick scan within the same subnet to be sure, which ports are opend. The scan result showed only port 22 was open. Then I started the NMAP Quick scan from VLAN2 against the RasperryPI in VLAN1, and also the dumps with Wireshark and tcpdump. This scan result showed only port 80 was open. I thought about the Hotspot function, which redirects all traffic to the landing page of the UTM. But as I wrote above, I already authenticated and had Internet access.

    What I can see in the dumps:

    The NMAP Quick scan send a lot of SYN packets to the RasPI on different ports (e.g. 993, 139, 25, 80, 443, 445...), and no answer comes back. Then the scan client sends a ACK packet (not SYN-ACK!) on port 80 to the RasPI. and the RasPI answers with a RST packet. That's what I can see in the Wireshark dump of the NMAP client. Where is the SYN packet?

    In the tcpdump of the RasPI I can see the same. No packets from the NMAP client until a packet on port 80 arrives. Regarding to the dump this packet has no flags set. And the RasPI answers to it with a RST packet.

    I can see that the UTM firewall dropped the SYN packets from the port scan. But I can't find the ACK packets or any other packets with that port number in the logs. That means the UTM didn't block this packet?!

  • 0 in reply to BAlfson

    I did some more researchs.

    I created a new VLAN 3 on the UTM without any rules, NAT, access to the Internet. Only a IP address on the UTM and a DHCP range. On the switch where the UTM is connected to, I configured one access port and a trunk on the uplink port to the UTM. I connected the NMAP client to the access port and started a new scan against my client in VLAN 1. I captured all traffic on the LAN interface of the UTM and my client in VLAN 1. Here are the results:

    - Almost every packet from the NMAP Quick scan were blocked by the UTM firewall
    - Packets with ACK flag reaches the client in VLAN 1
    - Packets with ACK flag appear in the capture of the UTM

    That means it's not a faulty switch or VLAN configuration. The packets are routed by the UTM.

    After that I startet a NMAP TCP-ACK scan (with -sA). That means all packets have the ACK flag set. I also startet a capture on the NMAP client, the UTM and the destination client.

    - 70 packets with ACK flag left the NMAP client
    - 140 packets with ACK flag goes thru the UTM (incoming with 802.1q tag for VLAN3, outgoing without any tag)
    - 70 packets with ACK flag reached the destination client

    Mmhh, could someone else confirm this behavior in his/her LAN?

  • +1 in reply to Jas Man

    I've found the problem/solution by myself.

    Under Network Protection -> Firewall -> Advanced the Option "Use strict TCP session handling" is not activated by default.

     

     

    This allows the UTM to re-establish existing TCP connections whitout a new 3-way handshake, which are not known by the connection tracking table of the UTM. And this option also forwards the ACK packets to the client in the other VLAN. The client replies with an RST packet which is also forward back to the source VLAN, and thus NMAP knows that there is an active client.

    When I enable this option, no packets are forwarded between the VLANs anymore (except those, which are allowed by firewall rules of course).

    The other option "Block invalid packets" is enabled by default and should block such ACK packets which are not related to any known established connection. I don't know why the packets from NMAP are not blocked by this option. Maybe because NMAP is sending a SYN packet before, which is blocked by the firewall but forces an entry in the connection tracking table?!

Reply
  • +1 in reply to Jas Man

    I've found the problem/solution by myself.

    Under Network Protection -> Firewall -> Advanced the Option "Use strict TCP session handling" is not activated by default.

     

     

    This allows the UTM to re-establish existing TCP connections whitout a new 3-way handshake, which are not known by the connection tracking table of the UTM. And this option also forwards the ACK packets to the client in the other VLAN. The client replies with an RST packet which is also forward back to the source VLAN, and thus NMAP knows that there is an active client.

    When I enable this option, no packets are forwarded between the VLANs anymore (except those, which are allowed by firewall rules of course).

    The other option "Block invalid packets" is enabled by default and should block such ACK packets which are not related to any known established connection. I don't know why the packets from NMAP are not blocked by this option. Maybe because NMAP is sending a SYN packet before, which is blocked by the firewall but forces an entry in the connection tracking table?!

Children
No Data
Unfiltered HTML