Checking network activity on Sophos XG Firewall for scanning attempts
Checking network activity on Sophos XG Firewall for scanning attempts
The device was located within the LAN and identified via the private IP 172.16.1.8. The next machine scanned was from a private address 192.168.0.13—its identity isn’t confirmed, but we follow the 192.168.xxx range. Is there a connection between the VPN and assigning addresses before firewall filtering, which might mislead scans to appear as internal? The results below come from Symantec Endpoint Management.
The VPN runs on a Cisco router owned by the ISP with limited visibility. Shop addresses follow a consistent pattern—third octet varies per location, not the 172.16 range. You can adjust firewall rules to tighten TCP/UDP scan detection and improve early recognition of port scans.
The stores interact with the server and database, requiring reliable connectivity. Each computer has its own Symantec license, suggesting internal detection is unlikely since antivirus would have flagged it earlier. Instead, the issue surfaces on the server hosting the backup tools, bypassing the firewall.
Your 172.* address indicates that the source address is from a Cisco device. Based on your listed network setup I would hazard to say that the device that is doing the scanning is your ISPs Cisco router, which means it probably has it's own "management" subnet that its assigned itself to apart from your LAN which is common. The port scanning behavior is most likely device fingerprinting from the ISP to identify what kind of clients are connected on the network and their connected status. If you want to confirm the 172.* device is in fact your ISPs router, you can hop in to your firewall and use ARP to see if that address is directly connected. The 192.168 device is more interesting, as the MAC indicates its a Sony device and I don't see anything you listed belonging to Sony. Is there anything in on your network that this could be that you are aware of? Either way, both of these devices are internal, private, IP address so I wouldn't be super concerned unless you have other evidence to suggest that your organization is compromised. You're going to have a hard time setting firewall rules to prevent this with your current setup. If the scanning is coming from your ISPs router, it would be dangerous to start blocking traffic coming from that device since everything else is in bridge mode you could have availability issues. Additionally, you could limit devices communicating with each other internally but that has its own issues and I don't see enough here to justify it. Once again, these port scans are NOT coming from external sources so your hosts do not appear to be exposed to the internet and the risk here is low.
After consulting with the team, we decided to proceed with this strategy: presently the policies and guidelines are enforced across all ports and the entire network. We prefer organizing the network into segments such as Shops, HQ, Remote Users, Internet (for casual browsing), and DMZ (for the Web server). Shops begin at 192.168.2.x, changing the third octet—we intend to place them in a Shop group before further categorizing by city. For firewall rules, the best approach is to create a specific rule for the DMZ, allowing the web server while restricting access from attackers. The People counter IPs are at 192.168.x.80, the HQ hosts two virtual machines (HV1 with ADDC/SQL and HV2 with People Counter, Veam backup, Symantec), and the DMZ contains the web server for secure communication with the SQL on HV1. Remote users need stricter controls, focusing on malware prevention and blocking port scans. The highest risk comes from external port scans targeting the web server, especially since it handles critical data and is exposed to the internet. Prioritize securing the DMZ and monitoring traffic patterns closely.
The DMZ functions exactly as designed, sending every traffic meant for another network straight to the internal LAN IP address, as though it were directly linked to the WAN. This is precisely how a DMZ operates, and even ping will skip the router and route right through the DMZ.
Right now there isn't a DMZ set up, and we're facing a TCP reset attack. The plan is to surround the web server with a protective barrier, limiting incoming and outgoing traffic. Even if someone breaches it, they won't easily reach the other virtual machines or services running inside.
TCP reset attacks are employed by firewalls for authorized actions to terminate potentially harmful TCP links. While you didn't specify details, it would be unusual for an adversary to intentionally close random connections to visitors. If you notice frequent resets, it likely signals a DDoS threat that a DMZ wouldn't shield against. For public-facing sites, a DMZ remains a recommended safeguard. Guidance on building one with Sophos is available at the provided link. It's usually wise to deploy two firewalls for greater separation, though logical setup works too. You may assign a specific port or subnet to your DMZ and configure rules accordingly—such as dropping packets destined for internal networks.