After perusing my log files, I have found multiple attempts to log into my system. I would like to restrict access to Canadian and US sources only. I have downloaded a CSV file from ip2location, and created a database from it.
The /etc/ssh/ssh_config file has a Hosts line where ip addresses, or partial ip addresses can be entered, but the documentation says that only the first Hosts line is processed.
How long can a line be, or can the line be extended by using a \ as a continuation character?
Hosts 192.168.0/24 \
192.168.2/24 \
172.1.1/24
My plan is to write a program to generate a ssh_config file from a template, and include an ip list from the database.
can you give details of your OS (name+version), and paste the section where it talks about 'only the first Hosts' ...
also what ssh s/ware is installed ..... the more concise detail you supply the better chance the team have of responding with relevant assistance/questions ...
you can have multiple hosts, each with its own 'section'
SCO Openserver6
$OpenBSD: ssh_config,v 1.20 2005/01/28 09:45:53
and from the man page:
Host Restricts the following declarations (up to the next Host key-word) to be only for those hosts that match one of the patterns given after the keyword. A single `*' as a pattern can be used to provide global defaults for all hosts. The host is the host-name argument given on the command line (i.e. the name is not converted to a canonicalized host name before matching).
Does that imply that there can be multiple Host statements?
Updating is highly unlikely. While there is a compatible version of Openssh for non Linux systems which I just downloaded, it requires a later version of openssl than I have. My guess is that when I try to make openssl, there will be more missing prerequisites.
So, my choices are really can I make what I have work, or do I put a Linux system between the SCO system and the router.
Well, I got that all wrong. ssh_config only applies to outbound connections. sshd_config for inbound.
I set up a list of DenyUsers and that worked, although I would like to disable any messages if a valid password happens to be entered.
Here is what I get if I attempt to login from an denied ip address with a valid userid and password
This is not necessarily correct, sorry @munkeHoller
IT security for any organization is based on either a qualitative risk management analysis, a quantitive risk management analysis, or a combination of both.
However any organization or person slices the pie up, decisions made in the IT security realm, are based on the intersection of these three areas:
Criticality
Vulnerability
Threat
I want to educate all concerned in that you will notice that "paranoia" is not in this criteria What is important is to honestly access risk, and then doing a similar analysis on deciding the best controls to put in place to meet the risk assessment (based on a cost-benefit analysis) by looking at three categories of controls:
Administrative
Technical
Physical
Today I will not get into a complete discussion on this topic (everyone is happy now), as it goes a lot deeper than a few bullet points; but let me add this in summary, for laypeople in this area.
If an organization has assets which are not that critical (on a server) and there are no major threats against that organization, then the IT security controls they would put in place are far different than an organization with super critical assets (on a server for example) and serious threats against it.
The criteria for risk also changes based on the vulnerabilities (known and unknown) to the system being evaluated, so someone using a system which is up-to-date with few known vulnerabilities would focus their risk management and IT security controls differently than an organization with a server running unpatched, out-of-date software when known vulnerabilities, for example.
To illustrate this point picking on @jgt in this his topic, @jgt mentions that he found some login attempts to a server. However, he does not mention anything about the server and what is its function. He says "my server" but we have no idea what that means. Does he mean a personal server on the internet where he hosts a few files as backups? Or does he mean he is working for a client who runs a top secret database of state secrets?
Having few "logins entries" on login attempts in log files on most servers is normal and it is nothing to be "paranoid" about, using @munkeHoller choice of words. What is important to understand the risk profile.
For most people who are not running super critical servers and are not being attacked by spies and criminals relentlessly (and without doing any basic risk analysis); and are running a basic server (with perhaps only concern for ssh logins), there are much better ways to manage security than to rely on ip address to geolocation mappings which can be spoofed or circumvented via tunnels and IP proxies.
Today, for example, I have logged into various services from an IP address in both the US and Malaysia, using my VPN:
As you can clearly see, we can be "any location we need to be" with the click of a mouse, so everyone should understand that IP address, geoip-location based access-control is pretty much "useless".
Most people in the very sketchy security situation described by @jgt would just install this tool, which is mature and works well for ssh:
However, it is not possible to make a recommendation to @jgt because he has posted an IT security question without any risk management context (as I briefly outlined above).
I think this is not necessary. There are myriad tools out there which wrap ssh and provide strong IT security in most "normal" IT security risk management scenarios which are more secure that using geoip location, which is easy to circumvent with the most simple VPN tools easily available on anyone on mobiles or desktop. With the simple click of a mouse, anyone can hide their IP address and have an IP address from just about any country (based on geoip, on the planet). I use VPNs daily for this and this is a basic "feature" in the year 2022 for most all computer users with basic knowledge, but I digress.
You have a lot more choices than that, but as mentioned, you should so a proper risk management assessment before processing to a discussion about what IT security controls to put in place.
Yes, this I totally agree.
However, from what little risk management information you have shared so far, I think you should change course and consider failtoban; but then again, you have not provided enough details to provide a valid assessment.
I decided upon a relatively simple solution.
First I created a new user using the password generator to create a random valid user id. Then gave it a complex password.
Second I changed sshd_config to added this user to the Allowusers along with the customers that use sftp, and restarted ssh.
I have customers that log in to download files, but their login shell is MySecureShell, which allows ftp and sftp, but not a shell, and restricts access to their home directory.
By the way, there were 53176 failed logins from May 16 to June 28 from 61.177.173.22
This is generally one or more scanners from the net; 5,000 or 500,000, just about every sshd process will log these events since they are created by bots and anyone can (and do) run bots.
FWIW (and without knowing anything at all about your risk profile, since you did not share that information), the solution I used (before) for brute force ssh bots on Linux servers on the net is to enable 2FA on my servers using Google Authenticator. However, I have no idea about SCO, since I am not a SCO user.
Using 2FA in this way is not so difficult to set up (but it is not trivial either) and works very good; and I used this for a very long time, until I finally capitulated (lazy to enter the 2FA code all the time) and just changed all my servers to disable ssh password login and only use ssh logins using SSH key-based authentication keypairs (passwordless, since these servers are not "user" critical).
I prefer this solution for most low to medium risk sshd server processes because it is easier to configure than 2FA, provides good security and is faster to login. Since only known hosts with cryptographic keys (SSH key-based authentication) are permitted to login, this defeats all the random spam-ish ssh scans on the net.
So, in summary, this is a common issue for every server on the network @jgt and I would have set up sshd to not allow password logins, and would have moved to set up a SSH key-based authentication cryptographic solution using public-priviate key pairs, as it is secure and easy to maintain, requiring no additional code nor scripting (to maintain).
If the server was "very critical" and needed an extra layer of security for sshd I would have (and have) added Google 2FA, as this works well (but it is annoying if you are in a rush to login).
In closing, unless the risk profile is very high, most OOTB solutions for sshd security like 2FA or SSH key-based authentication are more than enough control for sshd brute force mitigation. Also fail2ban and other similar wrappers also work well (are very mature) and also be used.
What is important is to honestly access risk, and then doing a similar analysis on deciding the best controls to put in place to meet the risk assessment (based on a cost-benefit analysis) by looking at three categories of controls: