Email notification for successful ssh login

[elorimer]

I've now set up a backup Freenas server in a physically separate location (an office building a hundred miles away). My main Freenas server replicates my datasets to this server nightly using SSH key pairs. Because this office location has a Comcast router with limited capabilities, I've port-forwarded a high, non-standard port to the backup server. This all works fine.

I'm now getting email notifications of unsuccessful attempts to do a ssh login to this backup server, hundreds of them. This leaves me with a negative pregnant: in addition to my nightly replication, are there any other successful login attempts?

I wonder if there is a way of getting a similar email notification of successful attempts. Failing that, are there suggestions for further hardening?

 

[no_connection]

Found this

How to log every login (SSH) on FreeBSD

I want to log every SSH login attempts, both successful and not, to my FreeBSD server to a file, and daily mail this log to root. I could accomplish something like this by parsing /var/log/auth.lo...

serverfault.com

But why are you not using a VPN tunnel? If you don't want to use wireguard for example then you can always run a small VM with pfSense or similar.

 

[elorimer]

But why are you not using a VPN tunnel?

Just following the guide for remote replication, using an SSH connection to send encrypted data. Creating a VPN tunnel, then running the replication, then breaking down the tunnel is a possibility, I suppose, but there isn't anything in the guide recommending that.

 

[no_connection]

Well for one you would not expose FN box to the internet at all so no extra logins to begin with.

 

[Arwen]

@elorimer, one of the things I did to my Cloud server, (which sometimes I think should be called Clown...), is to restrict my SSH to specific user ID(s). Plus, disable password authentication, only RSA keys, (which I use 8K size). Doing both of those drops the chances of being hacked quite a bit. No password to guess, assuming they get past guessing the user name(s).

You've already taken another step, changed the SSH port to non-standard. Some port scanners are real stupid. They expect standard services, like SSH, to be on their standard ports.

As for E-Mail on login, that is tricky. If it were a normal, interactive login, the normal ".bash_profile" could have the code. I don't know off hand how much that would work for non-interactive logins.

 

[no_connection]

You could keep password on but make it one fail and it's 1h ban or something, that would cut down chatter since you don't expect password logins anyway.
Unless you can do that with password disabled then even better.

Random port don't do much for security and I assume that is just to keep it from interfering with normal traffic.

Also if you remember heart bleed and similar exploits? It's good to not have stuff exposed even if you think it's safe.

 

[elorimer]

I'm a little perplexed. I can grep /var/log/auth.log and see my replications connecting using the key pair. I can also see the rejected login efforts, which are all coming in from a single Chinese IP address, with multiple user names. The odd thing is that they are coming in on a high port that is not being forwarded. So I don't follow how these are even getting to my server.

I wonder if it would be a useful addition for an alert as to successful logins, in the same way that the auth.log file is being parsed for unsuccessful logins. I'm also wondering if I could get into syslog-ng to forward those to my central syslog-ng server.

Clearly I have a bit of reading up to do.

 

[Heracles]

Hi,

Here, I monitor my environment using QRadar Community Edition. All my logs are sent to it, parsed and it will trigger alerts for many security incidents including repeated password fail.

But to actually prevent the attack completely, you should not expose SSH to Internet and use a VPN instead.

One option is ot have an actual firewall at both ends, like 2 pfSense. That way, they can easily do site-to-site VPN and interconnect the 2 FreeNAS.

Another option is to have an OpenVPN client jail in your remote FreeNAS and have that one calling back home to a pfSense on your main site. That will let you through the remote NAT router and again, offer you a direct access. No more port forwarding from Internet.

In all cases, if you really can not do anything else but port forward from Internet, you must disable password and switch to public key. This is the only way to achieve a minimum level of security. Only SSH vulnerabilities possible before authentication will leave you exposed.