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.
Location: Northeastern Michigan, where Carhartt is a Designer Label
Distribution: Slackware 32- & 64-bit Stable
There is also DenyHosts (http://denyhosts.sourceforge.net/). Been around for quite a while. It monitors your logs and when it sees this sort of activity it creates an entry for you in iptables or /etc/hosts.deny (either of these will stop a site from connecting); it's a daemon, it works (been using it for years).
Other options are country blocks, see for example http://ipinfodb.com/ip_country_block.php#blocklist. You can get iptables or htaccess entries and just block the entire country (Chine, for example, is a good one to bock along with Russia, both Koreas, and others). You get list and write a little AWK program that creates the iptables entry, pretty easy.
If you're open to the Internet you're going to get whacked by script kiddies and bad actors (such as China); DenyHosts (along with the other methods in other posts above) is a good tool that you don't have fiddle with constantly and does a good job.
Reasons for not using DenyHosts in its default configuration: http://www.linuxquestions.org/questi...iptables-3036/
Reasons for not changing the port SSH listens on: /etc/services (as in IANA assigned ports aka interoperability and obfuscation)
Wrt using RBL's like DShield, OpenBL.org I think its use is debatable as it doesn't relate to local conditions. In other words you may be investing resources in banning hosts that may have either scanned your particular ranges ages ago or will never scan your range RSN. (Also see this (2008) and this (more recent).)
Last edited by unSpawn; 05-04-2013 at 06:01 AM.
Reason: //More *is* more
Script kiddies and port scanners are one thing, state-sponsored attacks are quite another. Do countries spy on one another? Of course they do and have done so for thousands of years in one form or another. It seem, though, that China has taken it to a new level.
Personally I don't see the need for fail2ban in this situation. Its one more package he has to install and one more thing that has to be memory resident. The kernel and some iptables rules already offer what is needed.
If you use a strong password or disable password authentication and use ssh keys than slowing down an attacker is enough to prevent a brute force attack from working and spare your logs.
iptables -A INPUT -p TCP -m state --state NEW -m recent --name probe_list --update --seconds 300 --hitcount 5 -j DROP
iptables -A INPUT -p TCP -s 0/0 --destination-port 22 -m state --state NEW -m recent --name probe_list --set
iptables -A INPUT -p TCP -s 0/0 --destination-port 22 -j ACCEPT
What this will do is cause netfilter to keep track of recent connection setups on port 22. It will have a hold time of 300 seconds, if there are more than 5 entries from the same source ip in that time it will refuse new connections. You can play with the hold time and hitcounts but I have found these values are very effective at stopping brute force attacks (they just give up and move on when they start seeing the port as closed after 5 hits) and not causing me any usability problems.
I would reserve things like fail2ban for other services like web applications where its normal for a client to be repeatedly establishing TCP sessions or anything UDP.