sshd trying to connect to ports 25/ 465/ 587

anetde

Hello folks, I'm trying to find the exact attack vector and would like to know if I am overseeing any fixed issues here before opening a new one. Maybe someone can associate the described behaviour with a known issue easily:

An upstream network SOC contacted us with an abuse information for one of our pfsense gateways, saying the WAN IP of the gateway is trying to open TCP-connections with dest-port 25/ 465/ 587. We have ruled out that a node from the LAN net is causing the connection attempts (by placed a logging rule for conn. with these dest-ports on LAN interface). However, the default deny rule on the WAN interface logs lots of blocked connection attempts sourced from the gateways WAN IP to public IPs in the wild on the mentioned dest-ports. The general system log (system.log) and auth.log is full of messaged saying:

Mar 1 16:56:00	sshd	87031	error: connect_to 83.x.x.x port 25: failed.
Mar 1 16:56:00	sshd	87031	error: connect_to 213.x.x.x port 587: failed.
Mar 1 16:56:01	sshd	87031	error: connect_to 103.x.x.x port 465: failed.

The affected gateway runs an outdated version of pfsense+ (21.05) and I searched the netgate bug tracker for issues that can lead to this kind of exploitation. As the firewall rule set on the WAN interface was a complete mess here (allowing anything TCP from the IPv4 Internet to the gateway itself), I checked who logged in via SSH (auth.log) but the only succesful logins came from our staff members. Of cause, nginx.log and its archived versions show lots of automated exploitation attempts targeting all kinds of HTTP requests.

I did not find any issues in redmine that lead to abusing the gateway itself for making SMTP connection attempts.
I'm also wondering why our upstream ISP sees the described connection attempts whilst the WAN interface firewall log show them as blocked.

The only installed additional packages are net-snmp, sudo & suricata.

Any ideas? Known issues I'm overseeing? Thanks in advance.

Gertjan

Hi,

@anetde said in sshd trying to connect to ports 25/ 465/ 587:

An upstream network SOC ... abuse(d)

If these :

@anetde said in sshd trying to connect to ports 25/ 465/ 587:

Mar 1 16:56:00 sshd 87031 error: connect_to 83.x.x.x port 25: failed.
Mar 1 16:56:00 sshd 87031 error: connect_to 213.x.x.x port 587: failed.
Mar 1 16:56:01 sshd 87031 error: connect_to 103.x.x.x port 465: failed.

come from the logs of your pfSense, then 'some one' (must be an pfSense admin) is connected to pfSense, and trying to connect to the IP's and port mentioned. Or uses a script to do so.
Or mis configured a pfsense package to do so ? (dono if that is possible, can't exclude it neither).
One of the possibility is : you have a rogue admin.

Btw : why would you hide public mail server IP addresses ??

pfSense by itself does not do this. Be default, sshd the ssh daemon, isn't even activated.
Go have a talk with your admin ....

@anetde said in sshd trying to connect to ports 25/ 465/ 587:

he default deny rule on the WAN interface logs lots of blocked connection

That's it's job.
Like your phone number : it's accessible to who ever that has also a phone and use the same (and unique) phone network on planet earth (couple of billion).
So, if it start to ring a lot :
Mask the ring sound.
Change your phone number (and try to be less popular - give it to no one, ever).
Or pick up and ask : please don't call me any more.

What I want to say : anybody can connect to your WAN IP, as it is publicly accessible.
Knowing 'why' is the hard part.
The default option works great : un check :

or : change your WAN IP.

btw : what firewall rule did you create ?

stephenw10

@anetde said in sshd trying to connect to ports 25/ 465/ 587:

the default deny rule on the WAN interface logs lots of blocked connection attempts sourced from the gateways WAN IP to public IPs in the wild on the mentioned dest-ports.

That implies blocking outbound connections which would normally be allowed.
Can we see these actual firewall logs?

I would run ps -auxwwd and look for some script openning ssh sessions.

But note this is sshd, the server, logging that. This looks more like someone use ssh as proxy/tunnel and trying to send mail across it. So just look for ssh connections inbound when that happens. Could be an admin connecting from a compromised machine without knowing.

Steve