I host my website on a server at my office. I only host traffic to the site, and allow mail to be sent from the site.

Recently, several logwatch messages sent to my root account have shown sections just like this one below:

This one represents the most authentication failures of any of the logs. I don't recognize this IP or any of the others in similar logs. Obviously, this seems alarming. Does this mean that someone is connecting via ssh and trying to enter my server?

If so, what is the best thing for me to do to prevent this? I'm almost certain that nobody has actually logged on illegally.

Take into consideration that I am fairly new at this, but I am not by any means a real newbie.

This is known, bots and or script kiddies and their scripts running from remote servers that have either been compromised themselves or not to attempt logins.

First step, disable root login via SSH.
Second step, setup iptables to block any IP's or IP Ranges from connecting to your machine remotely. Or block all IP's except the known ranges you connect from.

And the correct term is cracker, not hacker.

If you don't know what those IPs are you should block them via iptables. Better yet you should insure that iptables only allows in http/https traffic - you shouldn't have ssh and other ports open to the world. You should restrict ssh to internal addresses and/or to only those external addresses you wish to allow. (This assumes you don't have another firewall between the server and the net - if you do you should block it there.)

It looks to me like someone at 84.246.244.93 is trying all the well known accounts so I'd certainly suspect a hacker there. That address is in Denmark according to www.dnsstuff.com IP check.

I only log on from two locations (home and office), and those are both DHCP. As far a setting iptables to only accept logins from those addresses, how do I set a range? I have only used commands to target one IP before.

This happens continuously - scans for ssh logins. The steps you need to take:

1- Never allow remote root login. In sshd_config:

PermitRootLogin no

2- Only allow specific users to login remotely (as few as possible). In sshd_config:

AllowUsers user1 user2 user3

3- Use very strong passwords for the allowed users (mixed case, numbers and special symbols, with a minimum length of 12 characters). Even better, only allow login by ssh passphrase. In sshd_config:

RSAAuthentication yes
RhostsRSAAuthentication yes
DSAAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

Also see:

man ssh-keygen

4- Move ssh to a non-standard port. In sshd_config (for example):

Port 12345

Remember to also close the old port (22) and open the new port in your firewalls/routers.

That's usually more than enough to protect your systems. There are additional tools that automatically add firewall blocks for bad access attempts, but they are not usually needed if you follow good security practices. The "bad guys" will just run their script, fail, and move on.

Say your IP is something like 66.120.90.34

You could set iptables to allow the whole block by using 66.120.90.0/24

That way if your IP changes to 66.120.90.156, it will still allow you to connect via the iptable rule you have in place. If your whole block changes, well, you'll have to sort that out manually at the machine but in most cases, it's not common for your ISP to change a whole range on you, at least it's not common. And if you have some type of router in place that's always on if you have DSL or Cable, it's very unlikely your IP changes at all. I have cable and have had the same IP for 3 years now on a DHCP connection.

I usually don't recommend this approach as in most cases it's not full proof way of protecting your system. Most can easily pick up the port with a quick scan of the IP. If an attacker wants to get into your system, they'll get in despite where you move the listening port. The other methods though are better ways to protect your system. The most reliable way is to just disable root login and setup a good firewall.

So then if I entered for example:

it would drop all connections except those from my computer?

If so, how would I include another range from the internal network, such as 192.168.0.0/24?

Additionally, how would I disable root login?

On it's own, it is not useful. However, using non-standard ports adds 64K permutations to the script - which translates to 64K times the amount of time to attempt access to a single host. It's usually not worth the time. Quick scans (nmap, for example) usually only test the privileged ports and not the high port numbers which can be opened transitionally by unprivileged applications (an open port in that case is not useful information).

As part of a best practice, the use of non-standard ports is a useful deterent. It's like putting bars on your windows. Not effective for a determined attacker, but still useful.

See post #5.

Nah, more like putting bars on your windows but forgetting to lock them..

What do you think about PAM authentication? Is this best set to yes or no in sshd_config?

Check your logs. I have multiple ssh ports opened (forwarded to different hosts). The only port ever to be scanned, multiple times per day, and attempted for ssh login in the last 6 years... port 22. That one's just a dummy/honeypot I use to monitor for that type of activity. Why spend 64K times as long to scan one host, when you could scan 64K hosts in that time? Unless the host has some particular value to the attacker (e.g., the potential to grab credit card numbers and other ID) the additional effort is, in practice, not worth the time.

Bars on a window are the same - their only purpose is to slow down an attacker, not stop them. As such, they act as a deterent. Why spend the time cutting through the bars, when there are thousands of homes without bars? Now if the bars are on a bank...

Who'd a thunk it? Thieves are doing ROI analyses...