[paperogiallo]

I'm really interested about country restriction, because my ISP doesn't provide static IP and I need to have access to my VPS via ssh, but these days f*****ng crackers seem to attack my box many and many times with brute force attack.

Could someone get me more info and a howto about country restriction?

Thanks all!

_YD

[kavalakala]

Well, I think the most effective solution to this problem could be to start filtering SSH login attempts. sshdfilter or fail2ban are in my opinion quite good tools to cut overwhelming amount of failed ssh logins. They scan syslog for such attempts and place a strict ban on IP address after certain number of failed tries. In that way you hadn't to suffer from loss of usability (you still could use your box from foreign TLDs and other domains) and any inappropriate breakin attempts.

You could also move your sshd to listen to another port, like 222 or 2222 or such, it probably would quite effectively stop any random attempts. But it definitely will not stop the attacks if the crackers have decided to try to get into your box. In such case probably they just scan your host once more and notice you have done such trick - and continue like nothing was happened.

Speaking of tcp wrappers, you have two files residing in /etc. They're called hosts.allow and hosts.deny. As said before, tcp wrappers restricts access just by filtering incoming connections by IP address and FQDN. In case you decide to pass further with tcp wrappers this page should help. Of course, consult also man.

[paperogiallo]

Many thanks, also for quickness!

I've changed ssh and webmin default ports yet.

I can't read man pages on my system because I have only ssh access to it (it's a Virtual Private Server hosted by a provider in a webfarm), and I've got only Windows-based computers at home.
I'm sure I can find a lot of useful information in linked pages, anyway. I think fail2ban is what I need!

BTW, I've just installed rootkit hunter on my system, and found 2 rootkit installed.

Another question, if I could: is it normal that rootkit hunter find 2 version of ssh? Into the log file I have two rows for:
ssh 3.9p1 [OK]
ssh [unknown - no version found]
First one is in /usr/sbin, second one in /usr/local/sbin ... how can I check which one is "in use"?

Again, many thanks!

_YD

[Lazydog]

The best way to thaw brutforce attacks is to use keys and move the port.

They can attach all day and never get in.

No password needed and you could carry your key on a usb stick for when
you use diferent machines.

Check out this SSH Link
It is a good way to use ssh keys.

[paperogiallo]

Thanks for good advice, I will take a look.

Another question: ssh is not logging any activity at all! On my system (Centos), it should use /var/log/secure for logging (according with syslog.conf, it has standard "authpriv.* /var/log/secure"), but nothing goes on that file... I also tried to explicitly force it to log writing "LogLevel: INFO" in sshd_config, but nothing changes...

How could I turn ssh logging on? This is crucial to use fail2ban or similar!

_YD

[paperogiallo]

Ok, failed sshd login attempts are logged in /var/log/messages, not in /var/log/secure... doh...

I installed fail2ban, configuring it to work with hosts.deny and hosts.allow. I tried a fake connection via ssh, mispelling my password five times. A correct rule is now written in hosts.deny (ALL: my_ip), but I can still have access via ssh. Why? Do I have to tell ssh to use hosts.deny, maybe?

I'm sorry if my questions seem to be silly to someone...

_YD

[Lazydog]

Hmmm.......

If I'm not mistaking, and it has be known to happen from time to time, host.allow is checked before host.deny is. So if you have anything written in there for your host to allow ssh then that might be why you still have access.

[paperogiallo]

Thanks, but hosts.allow is void...

(I love your State... eated a very good soup near ... hmmm... the city famous for the battle! I'm Italian, so I don't know about anything about American history... sorry...)

_YD

[kavalakala]

If I understood right, you made a rule to fail2ban which mangles hosts.allow and hosts.deny? In my opinion a more effective way would be to use fail2ban with iptables: failed attempt involves just a basic shell command which applies the rule which bans all incoming port 22 connections from specific host - when preferred time has passed, fail2ban just runs another command which removes the ban from iptables.

Of course you can use tcp wrappers for additional security (you once configure hosts.allow and hosts.deny to suit your needs) but IMHO continuous mangling of such config files via automated scripts is very clumsy.

There are also some cons when using a system such as fail2ban. It requires constant logging and log-watching and in that way consumes the resources of server. A bigger disadvantage or even a security breach would be the chance of Denial of Service. For example if there are users from a big NAT'd subnet (such as municipalities's and schools's intranets), it would be quite easy to perform a DoS attack. The attacker needs just to gain access to one workstation residing in the victim network and perform some false logins to fail2ban running server. The whole subnet would be unable to login to that server because every connection behind the NAT would appear as coming from one single host - which got banned.

Lazydog suggested implementing the key based authentication which prevents such risks but naturally, if the crackers are allowed to hammer your server, it increases the bandwidth usage

[paperogiallo]

I've read somewhere that IPTables are not configured on many Virtual Private Server, so I choose tcpwrappers... but, is there a way to check if iptables are installed on my system?

_YD