Does this indicate I was broken into?
I just happened to run a netstat command, and puckered up when I saw this:
Code:
# netstat -anp | grep EST Code:
# traceroute 95.49.118.165 Code:
# pkill sshd Next: Code:
# last Code:
# lastlog I thought I had my sshd locked down pretty good. I thought I had it set up to only allow pubkey authentication, so no password guessing would be allowed (and I have a strong password anyway). Does this sshd configuration really lock things down to only allow pubkey authentication as I thought? Code:
# cat /etc/ssh/sshd_config I see a bunch of unexpected entries in my auth.log. This is just a sample of them - there were many more, from different IP's. The time period for these entries is pretty short. Are there that many people knocking on my front door? Code:
Jan 18 20:18:43 Davids-Linux-Desktop sshd[31631]: Did not receive identification string from 79.101.95.120 |
Quote:
Highly recommend changing Port 22 to something else! Highly recommend key size of 2048! (Or 4096!) Rather than making another line that says yes rather than no (or vice versa) just change the yes or no! I also recommend fail2ban! is user "nx" you? |
Thanks for the reply.
When I change a default setting in sshd_config, I leave the default setting there, commented out, so that I can quickly see what the default was and what I changed it's value to. Having the original default line still in the file, but commented out, doesn't hurt anything. It doesn't affect security either. The port 22 you see is accessible from my LAN. To get there from the WAN, you must go through my router which forwards a different WAN port to port 22 on this LAN computer. So effectively, I have already "changed the port". But changing the port really does nothing to add security. It would be a very stupid hacker who thought that SSH could only run on port 22. Changing from port 22 to something else might delay a hackers port scan by about 18 milliseconds, but not much else. ServerKeyBits is set to 1024 because that was the default. I didn't change that because ServerKeyBits is only used with SSH "Protocol 1". You can see in my config that I only allow "Protocol 2", so ServerKeyBits is not used, and ignored. I am vaguely familiar with fail2ban. I believe it works on similar principles to a script I wrote and posted here on these forums over a decade ago. Named "banssh". For all I know, fail2ban might have even been based on my script or Bob Toxen's original concept that I based my script on (Bob was the instructor in a Linux security course that I took many years ago - fantastic course, Bob really knows his stuff!) Start with this post: http://www.linuxquestions.org/questi...6/#post2290227 and then read on down two or three posts after that to see the script. I stopped using my banssh script a few years ago because I stopped allowing anything from the WAN into my LAN except VPN. So if I wanted to SSH to one of my internal computers, I would first have to VPN into my LAN (my router runs OpenVPN) and then from there, SSH to the target computer. With that setup, I no longer needed banssh. But recently, I opened up port 22 on one LAN computer to the WAN via router port forwarding. And to be honest, I just plain forgot to turn banssh back on for this newly exposed computer. That was my error. Thanks for reminding me. User "nx" is used by the NoMachine NX server (GUI remote access, similar to VNC, but much faster). While installed, that server has never been turned on. I use the client for NX to connect out to remote computers I manage. But nobody connects incoming to my computer using NX. The server is installed, because the client shares some components with it. But the server is not running. You're seeing one of the footprints of the server being installed. The reference to the "nx" userid. At one time in the past, I was pretty well versed in setting up SSH securely. That was a long time ago, and in recent years I've pretty much just carried over my older implementations. I've lost my edge on secure SSH setup (hence my questions in this thread!) When I saw that ESTABLISHED connection to port 22, that grabbed my attention real fast. I was thinking to myself, "Hey, I thought I already had all that nonsense covered!" Evidently not. Or maybe I'm reading too much into that ESTABLISHED connection. That's why I'm asking questions in this thread. To re-learn what I used to know, get up to speed on more recent updates and security techniques, etc. Thanks again for the reply. I appreciate it. Especially when this thread started out with a detailed and long winded post. Those are difficult to wade through, I know. And here I am AGAIN, with ANOTHER long winded post! :( |
No worries! I was not sure if that meant anyone had connected or not, I was just making some general security change suggestions I often found when I first started learning about all that. I agree changing the default port isn't necessarily going to slow down a targeted attack by any measure, but I'd argue that one would see less login attempts in general. After all, it'd be lot faster to
Code:
nmap -p 22 Code:
nmap -p 1-65535 I will note for what it's worth that running the same netstat command on my system shows the username of the connected user after "ESTABLISHED 551/sshd:" rather than "[accepted", or, if there is no one connected it does not appear at all |
netstat is just showing the ESTABLISHED TCP connection - your auth.log shows the SSH negotiation failing as presumably the bot on the other end is trying to supply a user/pass or simply waiting for a prompt until it times out.
|
After playing around with logins a bit, I was able to replicate the output ESTABLISHED ***/sshd: [accepted.
It appears this indeed was someone connected but NOT authenticated. I did this just by ssh'ing to my ipaddress from let's call it computer B, at which point I received the prompt showing the ECDSA key fingerprint and asking if I wanted to accept. Before answering, on computer A I ran Code:
netstat -anp | grep EST When pubkey authentication is NOT enabled, and after answering whether to continue connecting, the username appears in place of "[accept" |
nx = nomachine?
|
Thanks for the help guys!
I guess I overreacted when I saw that ESTABLISHED connection on port 22. I don't run netstat routinely ... only if I have some reason to look at what's going on there. Yesterday, I was looking (for something else), saw the port 22 connection, and puckered up a little. I guess I've never stumbled onto an active (but ultimately repelled) SSH hack attempt. Had my brain been working correctly, the analysis should have been obvious. Of course you have to connect before you can authenticate! I guess floundering is good for you every now and then. It gets those stagnant brain cells woken up. Makes you question whether you really know what you're doing like you thought you did. It's good to question every now and then, to keep yourself sharp. |
Yes, nx is NoMachine. I use their software to manage other friends/family computers. I use an older version because it is all peer-to-peer. I believe the newer versions of NoMachine connect you through their central servers as middlemen. I prefer not to have a middleman computer in the remote connection mix. The older versions of NoMachine use the nx userid in their implementation. I don't know if the newer versions use that. NoMachine NX is much faster than VNC.
|
OK, obviously earlier I just got prematurely freaked out by a run of the mill and harmless port scan.
Here's some example netstat output (the netstat command was run once per second) illustrating a scan in progress on the computer I'm typing on right now. You can see that every few seconds the process id of sshd is changing, as is the port on the remote end, indicating they're knocking on the door, but not getting in. Code:
# netstat -anp | grep EST | grep :22 Code:
# nslookup 146.255.230.86 Code:
# whois 146.255.230.86 |
I recommend creating a script to create hashes of /etc and /usr after every set of patches so you can compare the checksums. This will allow you to verify if anything has been altered on your system. If you want to go the package route, you can install AIDE and create a cronjob to notify you of any changes. Very helpful in the event you do get hacked, you can see what binaries or configurations have been changed.
|
All times are GMT -5. The time now is 08:09 AM. |