ssh security and key auth ??
 

i have a server that has ssh key-only login with a passphrase on the key. password login is set to "no" as well as root login.
i was checking my auth.log to see if this discouraged any bots but was confused as to the difference between the way the bots are now logged. there seems to be 2 different responses to the connection attempts by the bots. first i have a whole series of lines like the following:
then later these same connection attempts look llike this:
why the difference in the log if it seems both are just connection attempts from a bot that doesn't have the key.
is the one that say's "possible break in attempt" somehow different and should i take any other measures?

After trying to connect the sshd service is doing a reverse lookup, most likely DNS, to ensure the IP address is the same as the FQDN. when the FQDN and IP address do not match then it states that there may be a possible break-in attempt.

Also check this link (I think it explains better with the example):
https://supportcenter.checkpoint.com...tionid=sk40676

See the sticky thread https://www.linuxquestions.org/quest...empts-340366/: disabling root login and denying password auth is one of the SSH security best practices, I suggest topping it off with fail2ban or equivalent.

i said i had root login and password auth off in my original post.
i actually have fail2ban as well, but i have not set it up yet. while i appreciate the response neither of you answered my whole question. the main question is why for like 300 lines does it do the reverse lookup and report it as a possible breakin and then later it only reports it as a disconnect and does no reverse lookup.

I looked into this a while back because of the same messages I found in my logs. I'm still a bit confused about it, but as I understand it, possibly incorrectly, sshd does a reverse DNS check to get the host name, and then does a forward check to see if the host DNS name points to the incoming IP. If they don't match, you get the "POSSIBLE BREAK-IN ATTEMPT!" message.

I believe this check is really only important if you are using host-based authentication. You are not, so you shouldn't care if a cracker's IP address and resolved host name don't match. There aer a lot of IP addresses that don't have valid reverse pointers anyway.

Take a look at the UseDNS parameter. It defaults to Yes. If you set it to No, it should eliminate the DNS check and the possible break-in message.

I welcome being corrected by an expert if I'm mistaken about this.


BTW, in your example, you have IP address 115.112.237.214 for the first message and 72.52.124.40 for the second. You don't know that a reverse lookup wasn't done in the second case. But if you check the second one yourself, you'll see there is no reverse pointer, and thus no way to get a host name to do the forward comparison.

thanks Z038. that makes sense. i didn't think it was anything to worry about either since i am using key authentication but was a little worried the "attack" footprint was perhaps different triggering the reverse lookup and "possible break in attempt" message. this is why i went to key authentication in the first place. i was getting bombarded with login attempts to the point that when the server was under high usage a DOS would occur, and even crashed at one point. i know fail2ban ultimately should be added as well, but will implementing fail2ban free up more resources on this server, or is the fact it is key only, and it doesn't have to process the password logins, enough to avoid the side effect of a DOS.
BTW -- i'm not saying this is a DOS attack. it is just a side effect because i am pushing this server already with 10-30 student VM's running on it, and can't afford to expend resources to ssh bots.

Fail2ban will detect repeated attempts from the same IP during a specified interval of time and ban it. That effectively limits the number of attempts from each IP hitting your port, so I consider that a benefit. It reduces the sshd overhead of having to respond to connection attempts.

You tell Fail2ban the number of retries (maxretry) within an interval (findtime) that triggers a ban, and how long to ban the IP (bantime). It's easy to configure. Make a copy of jail.conf called jail.local. Set your default bantime, findtime, and maxtretry in the DEFAULT section. Then enable any of the following jails you want Fail2ban to use. Override your defaults in each jail as needed.

The defaults set in Fail2ban, as distributed, are pretty lax. They only ban an IP for a very short time. The default for ssh is to ban an IP for 5 minutes if there are 5 failed attempts over a span of 5 minutes. That might be appropriate for a site like yours where you have a bunch students logging in to your server regularly. If they have fat fingers, they won't get locked out for too long and will soon get to try again.

I use much less forgiving settings, since my server is only for myself and my family to use. I permanently ban any IP that generates three failed attempts within a three hour period, unless the connection attempt comes from my own network.

Here is the default section and ssh-iptables section in my jail.local:

i did understand what fail2ban does, but i guess i thought with key auth sshd wasn't doing all that much if someone doesn't have the key. i know sshd definitely has less to do if someone has a wrong key as opposed to in a password system with a wrong password. for example PAM doesn't need to get involved. i just don't know how much less resources it uses. one shortcoming of fail2ban i think is that there is no blacklist. i do realize i can blacklist manually via direct iptables entry but i wish fail2ban would add that entry after a certain ip gets a temp ban 3 times. in other words after say 3 temporary bans the ban is permanent. then if it is legit the student can email me and i would remove their permanent ban. the reason i think that would be better is i have noticed the bots attacking me are rotating ip's so when one gets banned another kicks right in and the banned one will just rotate back in the next day or so. so basically i am always being attacked even with fail2ban the only difference is the ip address rotates more frequently. it would take too much effort to figure out and manually add their entire pool of ip's to iptables manually.
BTW i don't need lax rules because the students are not logging in to the server via it's sshd. they are logging in to their own VM's running on the server so vboxheadless is listening on those non standard ports not the host/servers sshd. for example if their VM is password auth they can still login to their VM with a password even though the host/server is key only and passwords set to "no". fail2ban doesn't effect them because they are not attempting an ssh connection to the server just a TCP connection on a high number port and the bots are only attacking port 22 on the host so i need no rules for those high # ports. i can be super strict with fail2ban because i am basically the only one with remote access to the server. the students as i said are logging on to VM's running on it not the server itself. how it works is vboxheadless listens on the server's port 70001 for student1's VM and forwards any requests on that port to student1 VM's port 22 so the students VM's sshd does it's own auth. vboxheadless is also listening on port 70002 for student2's VM and forwards those requests to it's port 22. and so on.

fail2ban does implement that, more or less. Take a look at the recidive jail. That should do what you want. If you set the bantime to a negative number for that jail, it becomes a permanent ban for any persistent attacker until fail2ban is restarted. I'm not sure how many bans it takes to trigger the recidive jail, or if you can modify it.

You can also implement custom features by adding your own scripts to the actionstart and actionban actions in the appropriate config file in the action.d directory. I always ban an IP with a permanent bantime of -1 in the jail.local file, but as I said, that is only permanent until fail2ban is restarted. I wanted a permanent ban that would survive a restart of fail2ban. Credit where it is due, I modified the script I found here: http://www.looke.ch/wp/list-based-pe...-with-fail2ban to make it do what I wanted. See the bold sections below. This is my iptables.local file in the action.d directory.

The actionban script adds an IP to the ip.blacklist file only if it doesn't already exist. That is to keep me from getting duplicate entries in my blacklist. The actionstart script reads the ip.blacklist file whenever fail2ban is started and adds an iptables rule to ban every IP in the list.

hey thanks allot z038. i did a similar scrirpt before but it was not as clear or simple as this one. i also was unaware of the recidive jails negative ban time thing . i think i am going to impliment fail2ban this way, and give this script a shot for persistence.