No, not a lesson in CyberSecurity. Just a tale.
I was working on setting secure shell (SSH) access to a remote computer from mine. I’ve installed Linux on it and have enabled SSH access via RSA keys only. That’s the only real way of doing it properly. Only allow users to come in (disallowing the root user) via SSH as long as they have the 4096bit RSA key locally on their computer that’s registered with the remote computer.
I’m using a few years old Watchguard firewall one that I’ve not had muhc experience with. I managed to log into it as the administrator and to look at what it would take to get SSH port forwarded to the Linux computer in question.
With that Watchguard I was able to set up a SNAT and then create a rule to forward traffic. The SNAT I assume is the firewall NAT feature and the rule is pretty basic — it allows traffic to pass over that port to the computer specified by the traffic rule.
In the process of doing this I thought it would be a good idea to test it out to see if anyone had tried to get in as I had let it run for about a day with it only requiring a password. Today is when I implemented the RSA key requirement and disallowed passwords.
In order to determine if anyone had tried to get in I SSH’d into the remote computer and moved into the “/var/log” folder and looked at the auth.log file. Shift+g takes you to the end of the file where the most recent activity is taking place.
Looking at the end of the file uncovered that there were numerous attempts to get in as various user accounts such as “support”, “root”, “ubnt”, and “admin”. None have been successful and the attempts keep resulting in that IP address being banned for 10 minutes.
If you make too many password tries (remember I turned off password access and require you possess a 4096bit RSA key instead) the system will ban the IP address for 10 minutes and then unban it. This doesn’t stop abusers, it just slows down their attempts.
When I first set up my main network here long ago I noticed that I was being bombarded hundreds of times a second by bot’d computers. I solved this by forcing my network to only use RSA keys, I restricted logins from only specific IP addresses, and I set the ban mechanism to only permit one failed attempt, I disabled root login, and moved to a non-standard port. In my case someone trying to get in gets one failed attempt a day and is banned for a day if they fail on the second attempt.
I wanted to do some of these same things with the Watchguard. I’m not sure what is up but I was not readily able to configure the SSH port, though I am not sure it isn’t my fault. I’m new to it after all. I generally work with pfSense. I also wanted to see if I could tell the Watchguard to only allow SSH from my location here as I have restricted access from outside my network to specific IP addresses.
In looking at the auth.log I discovered that the failed attempts were from my IP address here. It would try those user accounts over and over. At least that’s what the IP address in the log shows, however, that may be some odd configuration option in Watchguard part of my failed attempt to restrict port access to specific IPs. It may just be saying that the IP address is from my address even though it is coming from others.
Seeing this puts me on high alert because if the attempts really are coming from my address then it means that potentially one or more of my computers are infected and since I use mostly only Linux that would be shocking news.
In an attempt to figure this out I turned off many computers and have watched the log file changes through the day. I can see continued attempts every so often all from this IP address here.
Now, if my computers here were infected it would mean that my systems at home should also contain log entries with the same sort of attempts to log in. I examined those log files and they show no attempts to get in from here.
I also noted the login activity began yesterday. I also noted that at roughly 9pm one of the attempts was from this IP. I was at home and I had not made any attempts to get in at that hour. I tried once around 7pm just to see if things were secure. I was rejected for not having the RSA key. I didn’t try again. At that hour my main computer at work (which is really the only one that has access to connect to the remote computer) is off. It means that the remote computer is safe from attempts from this location if that’s where the attacks are coming from.
Circumstantial evidence seems to indicated that it is just a single IP address trying. That may be an artifact of what I described above in configuring the Watchguard.
Of the account names tried none of them exist. That means the computer doing the attempts hasn’t identified the OS version. The root account attempts are always going to be futile because root login is disabled by default when you install Ubuntu and thus there’d be nothing you can do. The account names that are being tried are “admin”, “support”, “root”, and “ubnt”. I can understand why attempts would be done as most of those however the notable one is “ubnt”.
I looked up why that account name would be tried and it appears that “ubnt” is the login name for the Ubiquity routers. The “admin” account name is the name for various other routers such as the Watchguard and even pfSense.
What crossed my mind a moment ago is how can I enable incoming SSH login but disable outgoing SSH login (allow users to log into my server but don’t allow my server to log into other computers).
That’s it for now. We’ll see what I uncover of the next week.
EDIT: I worked the issues out with the watchguard identifying my IP address here as the culprit. In the configuration of the policy you can set the source IP. Initially I thought it was the IP of the incoming computer and that would restrict it. That is not the case. It simply changes the IP of the actual source to the source you fill in. I haven’t figured out why that would need to happen.
I also found out how to restrict incoming packets to be port forwarded to specific addresses. For instance, I want to restrict connections between home and work on specific ports and allow no other computers on the internet to permit this. In the drop down boxes when filling out the type of connection. It’s not hard. It can be done by selecting IPv4 in the connection and then specifying a custom IP and then specifying the external address. That’s put in an alias and that alias is then referenced in the firewall policy for the port you are trying to forward.
I was unable to find out how to specify a port not covered in their canned port choices. I want SSH moved to a different port other than 22 and I want the router to forward ports from that. I looked and looked to no avail. I’ll do a bit more research and see if others on the internet have managed to do it.