Too many alerts: "ET SCAN Potential SSH Scan OUTBOUND"

denis_ju

hello!

I have too many alerts like this in the screenshoot from my WAN interface!

I have three interfaces:

WAN (public ip) - snort NOT in blocking mode - IPS Policy Selection "Connectivity"
LAN - snort NOT in blocking mode - IPS Policy Selection "Balanced"
DMZ - snort in blocking mode - IPS Policy Selection "Security"

Poorly configured pfsense/snort?
Pfsense is infected?
LAN is infected?
Etc ...?
Does anyone have an idea what it could be?

denis_ju

@denis_ju
Installed packages:

pfsense 2.7.0
snort 4.1.6_11
ntopng 0.8.13_10
arpwatch 0.2.1
bandwidthd 0.7.5
darkstat 3.1.3_6
freeradius3 0.15.10 (not active)
mailreport 3.6.4_1
openvpn-client-export 1.9_1
pfBlockerNG-devel 3.2.0_6
RRD_Summary 2.2
Service_Watchdog 1.8.7_1
squid 0.4.46 (not active)
squidGuard 1.16.19 (not active)
Status_Traffic_Totals 2.3.2_3
Tailscale 0.1.4 (not active)

SteveITS

@denis_ju 0.0.0.0/8 isn't a public IP: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml I had to look it up to see if it was even valid. :)

If you change Snort to run on LAN it will show the source IP as the LAN device making the request. (and since Snort runs outside of the firewall, it will avoid scanning any inbound traffic that isn't going to be allowed by the firewall)

You could also block port 22 outbound on LAN and log that rule and see what is making the request.

denis_ju

@SteveITS said in Too many alerts: "ET SCAN Potential SSH Scan OUTBOUND":

@denis_ju 0.0.0.0/8 isn't a public IP: https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml I had to look it up to see if it was even valid. :)

Yes, that's clear to me.

If you change Snort to run on LAN it will show the source IP as the LAN device making the request.

Just done.
Snort for wan disabled.
Snort for lan remains active as before.
After the change, there is no source device making the request.

(and since Snort runs outside of the firewall, it will avoid scanning any inbound traffic that isn't going to be allowed by the firewall)

You could also block port 22 outbound on LAN and log that rule and see what is making the request.

Port 22 (out) for lan blocked and logged.

After the change there are no "snort lan" alerts for port 22.
No alerts seen on firewall logs for lan port 22.

SteveITS

@denis_ju Well that's weird and implies it either stopped or was coming from pfSense. If you put it back on WAN and it recurs I might consider reinstalling pfSense and restoring the config from backup so you know it's clean.

Technically you can run Snort on both LAN and WAN for this test, it's just double scanning.

bmeeks

Likely ntopng if I recall correctly from previous run-ins with this issue. I'm not 100% sure it was ntopng, but I do remember it was a package the user had installed making internal connections/probes and triggering the alert.

I would simply disable that rule.

denis_ju

@bmeeks said in Too many alerts: "ET SCAN Potential SSH Scan OUTBOUND":

Likely ntopng if I recall correctly from previous run-ins with this issue. I'm not 100% sure it was ntopng, but I do remember it was a package the user had installed making internal connections/probes and triggering the alert.

You're right. Yesterday I tried to stop ntopng service and then I didn't see any alerts anymore.

I would simply disable that rule.

I don't know whether this rule in WAN "blocking mode" silences other attacks/alerts!

bmeeks

@denis_ju said in Too many alerts: "ET SCAN Potential SSH Scan OUTBOUND":

I don't know whether this rule in WAN "blocking mode" silences other attacks/alerts!

In my personal opinion (and I managed an IDS/IPS for a Fortune 500 for several years before retiring), rules like that ET SCAN one are not very helpful because too many innocuous behaviors can trigger them. Your example in this post is a perfect one -- another package you installed for a different purpose was detected as doing somethng "bad" by this hair-trigger rule.

Also note this rule is set to detect outbound SSH scans, not inbound scans. So, it is designed to trigger when hosts on your protected networks are doing outbound scans for an open SSH port. In my view, it would be better placed to have this rule on your internal interfaces and not on the WAN. This is because all traffic from internal hosts must traverse the internal interface before getting routed to its destination.

denis_ju

@bmeeks

Today, out of curiosity, I activated ntopng again. Wanted to see what alerts came out.
A flood of alerts can be seen!
I don't understand why ntopng causes so many alerts!

johnpoz

@denis_ju said in Too many alerts: "ET SCAN Potential SSH Scan OUTBOUND":

I don't understand why ntopng causes so many alerts!

Because you have discovery enabled - its trying to discover, so you yeah going to create traffic like that.

Not sure how you have ntop setup - but it shouldn't be doing discover to externals..

https://forum.netgate.com/topic/173693/suspicious-traffic

Specific post with links to other posts
https://forum.netgate.com/post/1055688

Does nobody search before they post?

denis_ju

@johnpoz said in Too many alerts: "ET SCAN Potential SSH Scan OUTBOUND":

@denis_ju said in Too many alerts: "ET SCAN Potential SSH Scan OUTBOUND":

I don't understand why ntopng causes so many alerts!

Because you have discovery enabled - its trying to discover, so you yeah going to create traffic like that.

You are right! This is the solution!

Thank you!

Not sure how you have ntop setup - but it shouldn't be doing discover to externals..

https://forum.netgate.com/topic/173693/suspicious-traffic

Specific post with links to other posts
https://forum.netgate.com/post/1055688

Does nobody search before they post?

I'll read it carefully! Thank you!