Numerous ET SCAN Potential SSH Scan OUTBOUND alerts. Is Pfsense infected?
-
Indeed. Logs, pcaps, or a disk image would have been interesting.
It would also be interesting to know how you reinstalled (not worried about rootkits? efi/bios resident malware?).
After re-install, did you put the same config back in and just modify the password?
All kinds of interesting questions... thread had 10/10 potential :)
-
It would have been nice to see but I just wanted my internet back under control :)
All good questions! Yes same config, new LastPass random password this time.
I am a Linux admin at work so I know a few things, although not everything :p
I reinstalled after booting up an Ubuntu instance and running chkrootkit. Not sure how effective it'll be but I made an attempt. I then formatted the drive (it was ZFS) and I have moved back to UFS.
I installed fresh, restored backup, changed password and then sat there for about 30 mins watching the Suricata alerts just to make sure.
Then I powered all severs/desktops back up one by one just to be sure it did not spread to them.
Not 100% trusting just yet.
-
I'm getting the same thing, Seems to be crawling through the IP's. Really worrisome as I host a site for my wife's Co.
Has the rebuild fixed it? Are you sure you still have the alert enabled?Member of the 'emerging scan rules':
SID 2003068
https://docs.emergingthreats.net/bin/view/Main/2003068 -
How many times per minute are you seeing this? You're sure it isn't a result of you attempting to make an ssh connection 5 times in a 2 minute window?
-
Also, could you paste the output from the command line
sockstat | grep ":22" -
-
@boobletins said in Numerous ET SCAN Potential SSH Scan OUTBOUND alerts. Is Pfsense infected?:
sockstat | grep ":22"
Thanks for the quick response, here is what the command yielded, what am I looking at?
? ? ? ? tcp4 192.168.2.1:20356 192.168.2.23:22
? ? ? ? tcp4 192.168.1.8:54310 192.168.1.24:22
? ? ? ? tcp4 192.168.1.8:54312 192.168.1.24:22 -
Those question marks are in the original output? And you're running that from the pfSense command line?
The command should be showing you which process has open sockets on port 22. We're hoping whatever process is scanning will show up there to try to get an indication of what is going on.
-
-
Can you check chat for me? It will be faster.
-
chromefinch had previously had ntop-ng installed but only recently re-enabled suricata.
sockstat | grep ":22"output from the ui did not generate helpful output.He re-enabled ssh access for himself and
sockstat | grep ":22"generated output similar to below:root ntopng 15017 45 tcp4 x.x.x.x:33912 57.151.10.72:22ntop was likely scanning what it thought was an internal network for sshd servers (though I have no experience with ntop on pfsense) -- he's following up in the ntop forums.
lambro690 -- I wonder if you had something similar going on?
-
@boobletins Thanks for your help!!!! I disabled the ntop wan interface and No more alerts!
-
@chromefinch said in Numerous ET SCAN Potential SSH Scan OUTBOUND alerts. Is Pfsense infected?:
@boobletins Thanks for your help!!!! I disabled the ntop wan interface and No more alerts!
So your firewall was infected -- but with ntop instead of a trojan ...
. (Just kidding). -
@boobletins Yup lol I sure did have ntop installed. Must have been a bug with the package because I haven't gotten anything since the reinstall. Now I will know what to look out for!
Great work guys. That makes me feel a little bit better about my security :p
-
I'm having same issue with ntop .. .. seems to try ip's like 0.106.219.157...
installed, reinstalled several times. ... anyone might know what is the issue? -
This post is deleted! -
@lambro690 Same like me, but I prepared to protect my firewall with pivate and public key, and limit access to my firewall with SSHd Key Only > Public Key Only.
-
I have the same problem and even more dangerous behavior from pF after latest ntop update. Even my avahi demon send mdns externally!
I'm on the latest pF 2.5 btw.I found this is due ntop bag and resolved by turning off hosts discovery in ntop itself.
If you are affected is easy to check after ntop update by visiting ntop host details page where you will see a lot of errors.I also added all my local networks under the ntop settings in pF.
This stop pF from crazy behavior with this snort allert, mdns and also fixed host details page in ntop itself.
I think this ntop bug affecting only folks with WAN enabled under ntop setting in pF but didn't check that.
Annoying thing is that after rebooting your pF you need go to ntop setting page in pf and just clink save all settings again.
-
I have the same problem and more dangerous behaviour from pF after latest ntop update. Even my avahi demon send mdns externally!
I'm on the latest pF 2.5 btw.I found this is due ntop bag and resolved by turning off hosts discovery in ntop itself.
If you are affected it is easy to check after ntop update by visiting ntop host details page where you will see a lot of errors. This behaviour is discovered even you not using ssh on your pF so changing logging behaviour don't make sense.I also added all my local networks under the ntop settings in pF.
This stop pF from crazy behaviour with this snort allert, mdns and also fixed host details page in ntop itself.
Don't have time enough to check if all this mess really go outside or just happened on localhost interface with ntop.If still not updated bug you can contribute on freeBSD forum for it.
I think this ntop bug affecting only folks with WAN enabled under ntop setting in pF but didn't check that.
Annoying thing is that after rebooting your pF you need go to ntop setting page in pf and just clink save all settings again.
Final conclusion is if you have any package wrong configured on your pF then you can become in internet even like an attacker regardless you are reseeding not your own traffic.
Maybe good way to truly test all updates on pF platform :) not simply fork them.How you run the process is important too because I feel ashamed a bit that my pF firewall became unaware that behave like a worm for resident and friendly network by simply copy redundant traffic across interfaces because one of the distributed packages wasn't test enough.
Form me personal interesting in this is how you are utilise your pF when this can become dodgy for your network. All about is use the tools, analyze the logs and do the tests :)
I love pF btw always my recommendation like you can see in open source we can resolve a lot annoying problems. :)
