Suricata Alert SID 2260001 - Regular nc connections to AWS port 4335 every 3 minutes
-
Hi,
I'm experiencing regular Suricata alerts that I'd like to understand better before suppressing them. I find three other occurrences of the SID on the forum but it was mainly suppress list, so I think it's better to share what happens here....
Environment:
pfSense 2.8.0-RELEASE (amd64)
Suricata 7.0.8_2
Packages: pfBlockerNG-devel-3.2.8, Squid 0.5.3, WireGuard, etc.Issue:
Getting SID 2260001 alerts every ~3 minutes with this pattern:SURICATA Applayer Wrong direction first Data [Classification: Generic Protocol Command Decode] [Priority: 3] {TCP} 192.168.0.7:XXXXX -> AWS_IP:4335
Findings:
Source: pfSense WAN interface (192.168.0.7)
Destinations: Various AWS servers (34.242.155.22, 52.210.229.217, 3.253.57.247, etc.)
Port: Always 4335
Timing: Exactly every 3 minutes
Process: DTrace shows nc (netcat) making these connections
Traffic: Legitimate TCP handshake, ~12KB data exchange, clean terminationTraffic analysis:
Used tcpdump to capture a full session - appears to be normal data exchange between pfSense and AWS services. No security concern identified.Questions:
Has anyone else seen these SID 2260001 alerts with AWS destinations on port 4335?
What pfSense service/feature uses netcat to connect to AWS infrastructure?
Is this related to automatic updates, threat intelligence feeds, or monitoring?
Safe to suppress these alerts?The traffic appears benign, but I'd prefer to understand the root cause before suppressing. Any insights would be greatly appreciated!
Thanks in advance!
plicplic -
Because you are running Suricata on the WAN interface, you can't see the actual host IP in your internal network that is initiating the AWS connection. Everything is being hidden by NAT. That's why only your WAN IP is showing up in the alerts. Suricata (and Snort) sees network packets on an interface BEFORE the firewall engine acts on that traffic. So, for inbound traffic from the Internet or outbound traffic from your local networks, Suricata on the WAN can only ever see the WAN's public IP as "source" or "destination" of traffic.
Place a Suricata instance on an internal interface such as the LAN and then you can easily determine which internal host is making the connection. If it is indeed actually being initiated by pfSense, then my first suspicion would be lists getting updated from one of your other installed packages.
If you Google that Suricata alert, you will find that it's a harmless consequence of the parser getting confused with some types of web traffic.
-
Many thanks,
It worked perfectly! -
@plicplic said in Suricata Alert SID 2260001 - Regular nc connections to AWS port 4335 every 3 minutes:
Many thanks,
It worked perfectly!I strongly recommend running Suricata only on internal interfaces such as LAN, DMZ, etc. That way it only has to process "filtered" traffic that the WAN firewall rules have already screened. That greatly reduces the workload and eliminates Suricata detecting and blocking traffic that the default "deny all" inbound rules generally present on the WAN interface are going to drop anyway.
Running an IDS/IPS on the WAN means it sees all of the normal Internet "noise" and will waste a ton of CPU cycles doing meaningless scanning and blocking because the deny-all inbound rule typically on the WAN interface is going to block unsolicited inbound traffic anyway.
Even if you have ports open and forwarded on the WAN, that traffic must leave pfSense via an internal interface such as the LAN to reach its intended local target host. Any IDS/IPS instance on that internal interface is still going to see the inbound and outbound traffic and can block it if necessary. No need to put IDS/IPS on the WAN. You don't run IDS/IPS to protect the firewall. You run it to protect internal hosts, and any traffic destined for an internal host has to traverse one of the internal firewall interfaces to reach the internal host.
-
i just adapted my config as you advised. Many thanks, again
