SlackwareThis Forum is for the discussion of Slackware Linux.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
Lately I have receive a lot of tries of connections on my server's ssh. So I was thinking (and I think it is) if is possible to deny connection of ssh or ftp or even smtp and pop to a range of ips. I realy want to deny connection from any ip not equal to 200.*.*.* or 201.*.*.*
The easiest way to avoid those attacks is by changing the default sshd port from 22 to something else, since most of them are automated attacks.
You can also use iptables, the commands would vary if you're already using it, since you can allow only from those IP or deny from all others, depends on how you're protecting.
Two other things to set by default is to use Protocol 2 only and set PermitRootLogin no.
To deny it would be something like: iptables -A INPUT -i ppp0 -p tcp -s IPRANGE -d 0/0 --dport 22 -j DROP
Personally, my way of avoiding these attacks without moving ports was to install knockd (available from linuxpackages). With this, I was then able to have port 22 closed to everyone that didn't know the knock. I have the Cygwin knock client on my USB key and anytime I need to ssh in, I just run it with the right knock and then, bam, the SSH port is open (but only to that IP). Then when I'm done, I can knock a different tune and it closes the SSH port.
This way, SSH is closed to everyone else in the world but I can selectively open it to any computer that I happen to be at just by knowing the knock. Must have cut a meg a day of logs out of the picture with only a tiny added inconvenience.
Another way of trimming the logs is using sshblack which is a perl script that monitors a log file for multiple attempts to log in via ssh. It then alters your firewall to drop the offending IP address. It requires you to tweak your firewall a bit, but it works well.
The other thing to consider is to not allow ssh login using usernames and passwords, but rather require public key authentication instead. There is a really excellent tutorial on how to set this up here .
The version of knock I use has available for download the linux command line knock and a windows cygwin executable for windows (two files, knock and the cygwin dll, put them both in the same folder and it just works like the linux command line version).
I would suggest looking into using the hosts.allow and hosts.deny files I have found them exceedingly effective in limiting who can connect the ssh servers I have set up. Their syntax is pretty straigh forward and they can even be used to log who is allowed or denied. They are well documented both in man pages and on the net.
On the "security through obscurity" note, yes, you're right but that phrase is overused. My bank card has a pin that relies on security through obscurity - you don't know my number or my pin but that's the only thing stopping you drawing money out of my account. The security of the portknock level is only as good as the security of the password, the knock itself. I don't tell people my knock and if I did, it would only be to those people who I also trust to login to the machine via SSH. I trust them not to disclose their portknock as much as I trust them not to disclose their public key.
The main purpose of using portknock software for myself and the above poster is that it stops any amount of dumb brute-force password attacks on my SSH (which is public-key only) and also stops no end of log entries from filling my logs.
Most people, when a port is closed, just ignore that port. To do anything else is just logistically crazy (i.e. if you assumed that every closed port you saw had a port-knock and then tried to find it, you would have to try many BILLIONS of knock combinations before you even got into the complex knocks, time-related knocks, hash-related knocks, IP-related knocks etc.).
Port knocking keeps the kids out. Anyone else who gets in is going to have found out the knock from someone who already has the knock and/or password and/or key.
Currently, I have the following setup:
- All closed (stealthed or whatever, not that it makes much difference) ports, for sanity when reading through logs.
[Therefore most observers see no difference between this and a machine that is turned off. Script kiddies have nothing to work from when they nmap, SSH bots see a machine that's not worth trying.]
- A "secret" port knock to open up SSH only to the IP that the knock came from.
[Effectively a password, potentially sniffable.]
- Only a single user can log in via SSH
[Username is non-standard, and SSH is encrypted therefore it is effectively a password that cannot be sniffed]
- That user has a single private key which is the only accepted way to login (no passwords)
[That key is effectively a password which cannot be sniffed]
- That key has a large passphrase.
[That passphrase never goes out across the Internet and therefore is a password that cannot be sniffed]
- That user account has limited access unless you su or sudo, which needs the root password.
[That is yet another password, unsniffable as this is the only way to get to it]
Therefore that's effectively four pieces of non-sniffable information and one (potentially) sniffable. The port-knock is therefore roughly as effective as a GOOD root password on a machine that has the latest version of SSH and is running no other services. This is, despite popular belief, quite secure because a full-text brute-force of any decent length password is still not practical across even a broadband internet connection, especially not with retry limits etc. Some portknock software has these same retry limits. Port knocks also mean that any brute-force attempt has bounces off your TCP/IP stack rather than SSH. This takes less resources and less logfile lines on the target machine (I don't log stray packets, I see no point).
Port knocks are easily sniffable assuming you can watch both ends of the conversation but they are not necessarily replayable (there are knocks based on one-time password lists, hashes of the time, source IP and other information, encrypted knocks and all sorts). This makes those portknocks as secure as something like SSH.
Say someone DOES steal/sniff/guess my portknock? Big deal. You opened a port that would have already been open without portknocks. I can still blacklist/whitelist certain IP's from having a successful portknock, I can still block IP's/usernames from SSH or whatever other service it opens up, I can get portknock to open ANY port, I can get the computer to do ANYTHING when it recieves a portknock (send SMS, reboot switches or computers etc.), I can have multiple portknocks for multiple tasks.
This all makes it absolutely invaluable for many tasks, means my computer becomes no less secure and much harder to try to invade, makes brute-force attacks MUCH, MUCH harder, is of minimal overhead (a single tiny daemon listening for SYN packets), of little inconvenience to someone who tries to log in (a simple password entry into a piece of tiny portknock client software that can accompany your SSH login software), another level of defense against things like new SSH vulnerabilities, an extra layer over any potentially stupid admin decisions that open holes, doesn't interfere with any of the software that it protects, can protect every service on a machine that doesn't need to be open to everyone and costs nothing but about ten minutes to set up.
I agree with what freemor has said. The easiest (though not best) way of solving your problem is to use TCP Wrappers. ssh is compiled with wrapper support. So it is as simple as entering the following line in your /etc/hosts.allow file.
Okay thanks, I will do it too !
But I have to admit, using another port have already made a big change here... no more tries on ssh port. I changed the ssh and ftp ports and the things are very quiet...