Slackware This Forum is for the discussion of Slackware Linux.
|
Notices |
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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
|
06-04-2006, 05:48 AM
|
#1
|
Member
Registered: Oct 2004
Location: Norway
Distribution: Slackware, CentOS
Posts: 641
Rep:
|
Slackware's favorite automagic ssh-protector
All,
What's your favorite tool for automatically locking ssh-hackers out and reporting them to the abuse-department of their ISP?
I have had a look at authfail ( http://www.bmk-it.com/projects/authfail/) which looks good but for some reason doesn't seem to agree fully with Slackware.
Such an automated tool obviously comes in addition to using keys, restricting which users are allowed to use sshd, etc etc - what I'd like to sample some opinions on is the favorite tool used by other Slackware-users to proactively shut these offenders out (and report), rather than just fill up logs and hope they'll go away..
Thanks for any insight!
-Y1
|
|
|
06-04-2006, 07:17 AM
|
#2
|
Slackware Contributor
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 8,559
|
I had loads of trouble with scripted attacks throwing hundreds of user names a day at my home SSH server.
All of that went away after I moved my internet-facing SSH server listening port from "22" to another port number. No more ssh hack attempts since (none!).
Just add another line with a different port number after this line
in the file "/etc/ssh/sshd_config" and restart the ssh service:
Code:
/etc/rc.d/rc.sshd restart
Don't forget to block port 22 on your external firewall! Now, port 22 is still useable inside your LAN which saves you from typing "ssh -p XXXXX" each time you want to connect.
Eric
|
|
|
06-04-2006, 07:50 AM
|
#3
|
Member
Registered: Oct 2004
Location: Norway
Distribution: Slackware, CentOS
Posts: 641
Original Poster
Rep:
|
Thanks for answering Eric,
I know about the change of port, but in this case I'd like to be able to permanently block through ip-tables as well. Based on the various programmes I've searched so far, it seems like a combination of denyhosts and authfail would be ideal (ie block the offending host with iptables, send an email to the abuse address from whois, and also submit to a global database for proactive blocking..
While changing the port keeps the script-kiddies out, I've never been a big fan of security through obscurity, and being the "detail devil" that I am, I would like to see how secure it's possible to get this
-Y1
|
|
|
06-04-2006, 09:21 AM
|
#4
|
Member
Registered: Jul 2005
Location: Finland
Distribution: Slackware
Posts: 213
Rep:
|
tcpwrappers, add all:all to /etc/hosts.deny and the ips to hosts.allow that should have access to your machine like this sshd:192.168.11.1
|
|
|
06-04-2006, 10:07 AM
|
#5
|
Member
Registered: Oct 2004
Location: Norway
Distribution: Slackware, CentOS
Posts: 641
Original Poster
Rep:
|
Hi con, and thanks for answering.
I guess I was a bit fuzzy in my original post - my apologies.
In order to access the network from the internet, allowing only one static IP address won't cut it. Furthermore, I believe iptables is far more secure than relying on hosts.allow/deny. I've moved my sshd to a different, high port, but still see quite a bit of attacks, so what I am looking for is a system that functions under Slackware that will allow incoming connections from the internet, but block the IP addresses of hackers using IP tables, and preferably sending an automagic email to the offending IP-range's abuse-contact from whois.
authfail does all this, except it's very Debian-centric and thus won't install on Slackware with my very limited perl-knowledge.
So I guess my real question is - has anyone got authfail to function on Slackware successfully?
|
|
|
06-04-2006, 11:14 AM
|
#6
|
Slackware Contributor
Registered: Sep 2005
Location: Eindhoven, The Netherlands
Distribution: Slackware
Posts: 8,559
|
You should take a look at psad and/or Snort. Both are intrusion detection systems that can block IP addresses based on the way traffic from those IP addresses is evaluated. Psad is more light-weight than Snort and could be more what you want - note that IP blocking is disabled by default in psad.
Eric
|
|
|
06-04-2006, 11:30 AM
|
#7
|
Member
Registered: Oct 2004
Location: Norway
Distribution: Slackware, CentOS
Posts: 641
Original Poster
Rep:
|
Excellent - thanks!!
|
|
|
06-04-2006, 11:34 AM
|
#8
|
Member
Registered: Jan 2005
Location: The grassy knoll
Distribution: Slackware,Debian
Posts: 192
Rep:
|
Quote:
Originally Posted by Yalla-One
authfail does all this, except it's very Debian-centric and thus won't install on Slackware with my very limited perl-knowledge.
So I guess my real question is - has anyone got authfail to function on Slackware successfully?
|
Well, I guess I'm blind but I could not see a download link except for md5 and pgp sigs and those gave me 404's.
If I can get a good download link, I'll take a look at it.
Or if it's just a perl script, email to me from my profile page.
Last edited by vls; 06-04-2006 at 11:36 AM.
|
|
|
06-04-2006, 11:48 AM
|
#9
|
Member
Registered: Oct 2004
Location: Norway
Distribution: Slackware, CentOS
Posts: 641
Original Poster
Rep:
|
Just sent it - thanks much!
When you've got it (and see my email), feel free to email me so I can send you the entire .tgz if you'd like.
-Y1
|
|
|
06-04-2006, 11:52 AM
|
#10
|
Member
Registered: Jan 2005
Location: The grassy knoll
Distribution: Slackware,Debian
Posts: 192
Rep:
|
Quote:
Originally Posted by Yalla-One
Just sent it - thanks much!
When you've got it (and see my email), feel free to email me so I can send you the entire .tgz if you'd like.
-Y1
|
Sittin' in the inbox this very moment. Let's see what I can do.
|
|
|
06-04-2006, 12:40 PM
|
#11
|
Senior Member
Registered: Mar 2006
Distribution: SLACKWARE 4TW! =D
Posts: 1,519
Rep:
|
Quote:
Originally Posted by Alien Bob
I had loads of trouble with scripted attacks throwing hundreds of user names a day at my home SSH server.
All of that went away after I moved my internet-facing SSH server listening port from "22" to another port number. No more ssh hack attempts since (none!).
Just add another line with a different port number after this line
in the file "/etc/ssh/sshd_config" and restart the ssh service:
Code:
/etc/rc.d/rc.sshd restart
Don't forget to block port 22 on your external firewall! Now, port 22 is still useable inside your LAN which saves you from typing "ssh -p XXXXX" each time you want to connect.
Eric
|
Yupper and anyone here who has or admin's a windows xp computer should consider this micorosoft guide on changing it's port as well:
http://support.microsoft.com/?scid=187623
Personally I'm a non-defaults kind of guy. You gotta keep them guessing. And turn off 8080 to while your at it
Fogie
|
|
|
06-04-2006, 02:50 PM
|
#12
|
Member
Registered: Jun 2004
Location: USA
Distribution: Slackware
Posts: 137
Rep:
|
You might want to take a look at DenyHosts. It's a python script which can run in daemon mode. It will monitor the log files for failed ssh login attempts and it will add the originating IP's for the failed attempts to your hosts.deny file. You specify which log files to monitor and you set the threshold limit's for failed attempts, etc. Once the IP is logged in hosts.deny file, the inetd will not allow any connections from that IP.
The only requirements are:
- a working sshd server which has been configured to use inetd
- a working python install
It also has an optional feature which when enabled will update your system from a user populated database of known abusive IP's.
|
|
|
All times are GMT -5. The time now is 09:36 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|