Identifying Rogue Traffic
-
I killed the state and the traffic ceased but I have no idea where it was coming from.
-
Don't know if this will help you figure this out: but something to consider:
Port 57621 using UDP is most commonly associated with Spotify, particularly with Spotify Connect and Spotify's peer-to-peer (P2P) local file synchronization features. This port is used for broadcast and discovery purposes on local networks, where Spotify clients use UDP 57621 to detect other Spotify devices and share playlist and local file information. Several security and networking communities, along with Spotify documentation and user reports, confirm this usage as the main known application for UDP port 57621. -
@Normandy214 said in Identifying Rogue Traffic:
Don't know if this will help you figure this out: but something to consider:
Port 57621 using UDP is most commonly associated with Spotify, particularly with Spotify Connect and Spotify's peer-to-peer (P2P) local file synchronization features. This port is used for broadcast and discovery purposes on local networks, where Spotify clients use UDP 57621 to detect other Spotify devices and share playlist and local file information. Several security and networking communities, along with Spotify documentation and user reports, confirm this usage as the main known application for UDP port 57621.Thanks thats good info, will keep an eye on it. My real confusion is how can an IP with no MAC Address create a state and be sending all that traffic. Really strange.
Been nominal so far since I killed it manually.
-
@james_h just to ask do you have anything in 172.16.0.0/12 that has a mask wider than /24?
-
In the future, to assess traffic in real-time, consider installing ntopng. You can also use softflowd to export netflow data to a netflow collector to analyze traffic patterns and bandwidth usage.
Without tools like these, tracking specific bandwidth usage can be a challenging task.
-
@SteveITS said in Identifying Rogue Traffic:
@james_h just to ask do you have anything in 172.16.0.0/12 that has a mask wider than /24?
No which is the strange thing to me, no idea where this traffic originated from.
-
@marvosa said in Identifying Rogue Traffic:
In the future, to assess traffic in real-time, consider installing ntopng. You can also use softflowd to export netflow data to a netflow collector to analyze traffic patterns and bandwidth usage.
Without tools like these, tracking specific bandwidth usage can be a challenging task.
Thanks for the advice, will take a look at that for future.
-
@james_h what is odd is that it originates from PRIVATE and goes out on FIREWAN and is not NAT-ed.
What traffic are you allowing on PRIVATE? Source 'PRIVATE net'|10.10.110.0/24 only or any?
-
@patient0 said in Identifying Rogue Traffic:
@james_h what is odd is that it originates from PRIVATE and goes out on FIREWAN and is not NAT-ed.
What traffic are you allowing on PRIVATE? Source 'PRIVATE net'|10.10.110.0/24 only or any?
These are the rules for PRIVATE, I guess I could change source to "PRIVATE SUBNET" ?
I wander if this is the problem, I cant remember what this was here for, maybe to unclutter the block log below.
-
@james_h PRIVATE is the interface? Normally traffic from an interface to other devices doesn't go through the firewall. That would imply the 2 open states are traffic from devices on that interface to pfSense. The block rules above block to certain ports. Left click the states column and it should show you the open states. But it's passed only 154 MB so seems a rather small amount of traffic.
-
@james_h it's more the last rule with 'PreferFIBRE'. The default allow-all rule after installation is source 'LAN subnets' and the rest any.
You rule allow anything as source on the PRIVATE interface. If you do expect traffic with source IPs of PRIVATE subnet then changing it from * to 'PRIVATE subnet' would have blocked the 172.20.* traffic.
Are the 'admin_devices' all in the PRIVATE subnet?
-
@patient0 said in Identifying Rogue Traffic:
@james_h it's more the last rule with 'PreferFIBRE'. The default allow-all rule after installation is source 'LAN subnets' and the rest any.
You rule allow anything as source on the PRIVATE interface. If you do expect traffic with source IPs of PRIVATE subnet then changing it from * to 'PRIVATE subnet' would have blocked the 172.20.* traffic.
Are the 'admin_devices' all in the PRIVATE subnet?
Yes I think thats what I should do. The admin devices are indeed in the PRIVATE subnet.
