Weblogs for MrFusion
#2
Posted by MrFusion on Tue 24 Oct 2006 at 08:29
For those of you who run a Debian machine (or heck, any UNIX-based OS):
If you run SSHD (Secure Shell Daemon) on your machine (which might be there by default and never explicity denied all outside traffic other than select IP's from gaining access, and you leave port 22 open to the world wide web, then try this command:
You may be surprised to find hundreds of lines describing failed attempts from various IP's from all around the world trying to log into your machine via SSH. Some may even have tried hundreds of logins just by themselves, using a dictionary attack. Running a whois on these addresses will often trace back to China or Korea, and emailing their ISP's abuse dept. is generally useless.
Now, if you're savvy enough when setting up your system, then you will have not used obvious names (like 'Joe') unless you tied them to very long and complicated passwords. Even if your login names aren't obvious, you should still have used very long and complicated passwords. And you will have set an especially difficult and complicated password for root. So if this is the case, your system is already fairly safe from dictionary attackers. (They're generally script kiddies and will give up and move on after a while.)
So even if your system is fairly bullet-proof in the login department, it's still fairly unsettling to just let it take repeated abuse from dictionary attackers. If you don't even use SSH to sign into your computer, then kill and disable SSHD. If you only ever sign onto it from specific IP addresses, then block all SSHD traffic with the exception of those IP's in your /etc/hosts.deny file. But if you like to keep it open for friends or your own general use from a school campus (or whatever), then you want to make it available. That is where DenyHosts comes in.
DenyHosts is a highly configurable program written in Python which can either be executed manually or via Cron, or can be run 24/7 as a daemon. Basically, it checks up on your /var/log/auth.log file periodically. It recognizes fishy activity from the log, picks up on malicious IP's and then automatically adds them to the /etc/hosts.deny file. Any IP listed in there will be actively ignored by your computer from then and on.
You can download that script from the webpage (linked above) and simply run an included Python script to install it. Or, if you're cool and you use Debian (or a derivative thereof), you can simply say:
If you use the apt-get way, then it will automatically create a useful man page and will set itself up in /etc/inet.d so that you can easily start and stop the DenyHosts daemon. It also creates the config file (/etc/denyhosts.conf). In the config, you can specify all kinds of options (especially if you choose to run it in daemon mode, which I prefer). You can adjust tolerence levels (how many times someone fails to log in before it gives them the boot) and how often it checks the logfile (default 30 seconds). It can be set up to synchronize itself with the designer's central server so that you can also block out IP's that other people's computers have blocked. (I keep this disabled, which is default, since that would be a frighteningly huge hosts.deny file.)
Anyway, it works like a charm. As of writing this, my personal server has blocked 46 separate IP's in the past two weeks... very impressive. It's a bullet-proof machine as it is, but I like the satisfaction of watching it weed out all the losers who try to break in. You can check out a list of all the IP's my system has blocked using DenyHosts through the following link: http://www.tarlus.net
There are tons more features that go with DenyHosts, but I'd end up with an all-out HowTo if I type anything more about it. Heck, this is more of a HowTo than it is a blog. Oh well, I wanted to write it; I hope people will find this to be useful! At the very least, I hope more people will become aware of all the unsetting things that show up in their auth.log files!
If you run SSHD (Secure Shell Daemon) on your machine (which might be there by default and never explicity denied all outside traffic other than select IP's from gaining access, and you leave port 22 open to the world wide web, then try this command:
sudo grep sshd /var/log/auth.log(Or, if you're already root, don't bother with using sudo.)
You may be surprised to find hundreds of lines describing failed attempts from various IP's from all around the world trying to log into your machine via SSH. Some may even have tried hundreds of logins just by themselves, using a dictionary attack. Running a whois on these addresses will often trace back to China or Korea, and emailing their ISP's abuse dept. is generally useless.
Now, if you're savvy enough when setting up your system, then you will have not used obvious names (like 'Joe') unless you tied them to very long and complicated passwords. Even if your login names aren't obvious, you should still have used very long and complicated passwords. And you will have set an especially difficult and complicated password for root. So if this is the case, your system is already fairly safe from dictionary attackers. (They're generally script kiddies and will give up and move on after a while.)
So even if your system is fairly bullet-proof in the login department, it's still fairly unsettling to just let it take repeated abuse from dictionary attackers. If you don't even use SSH to sign into your computer, then kill and disable SSHD. If you only ever sign onto it from specific IP addresses, then block all SSHD traffic with the exception of those IP's in your /etc/hosts.deny file. But if you like to keep it open for friends or your own general use from a school campus (or whatever), then you want to make it available. That is where DenyHosts comes in.
DenyHosts is a highly configurable program written in Python which can either be executed manually or via Cron, or can be run 24/7 as a daemon. Basically, it checks up on your /var/log/auth.log file periodically. It recognizes fishy activity from the log, picks up on malicious IP's and then automatically adds them to the /etc/hosts.deny file. Any IP listed in there will be actively ignored by your computer from then and on.
You can download that script from the webpage (linked above) and simply run an included Python script to install it. Or, if you're cool and you use Debian (or a derivative thereof), you can simply say:
sudo apt-get install denyhosts(Drop the sudo if you're root.)
If you use the apt-get way, then it will automatically create a useful man page and will set itself up in /etc/inet.d so that you can easily start and stop the DenyHosts daemon. It also creates the config file (/etc/denyhosts.conf). In the config, you can specify all kinds of options (especially if you choose to run it in daemon mode, which I prefer). You can adjust tolerence levels (how many times someone fails to log in before it gives them the boot) and how often it checks the logfile (default 30 seconds). It can be set up to synchronize itself with the designer's central server so that you can also block out IP's that other people's computers have blocked. (I keep this disabled, which is default, since that would be a frighteningly huge hosts.deny file.)
Anyway, it works like a charm. As of writing this, my personal server has blocked 46 separate IP's in the past two weeks... very impressive. It's a bullet-proof machine as it is, but I like the satisfaction of watching it weed out all the losers who try to break in. You can check out a list of all the IP's my system has blocked using DenyHosts through the following link: http://www.tarlus.net
There are tons more features that go with DenyHosts, but I'd end up with an all-out HowTo if I type anything more about it. Heck, this is more of a HowTo than it is a blog. Oh well, I wanted to write it; I hope people will find this to be useful! At the very least, I hope more people will become aware of all the unsetting things that show up in their auth.log files!
#1
Posted by MrFusion on Mon 10 Apr 2006 at 01:27
So between three machines in my house, I have used Woody, Sarge and Etch. I would get them installed and set up, and everything would work fine and dandy for a little while, until after about a week.
Then, my apt-get would quit working, it would cease up trying to connect to my apt sources, resolving them as 1.0.0.0. I would not be able to connect to any instant messenger services (even though they worked fine before) and browsing websites would become unusually slow. When I'd boot into Windows, everything on the internet was quick and responsive. Whenever I would SSH into the machines, either remotely or locally, it would hang up for about 5-10 seconds while authenticating both my login name and password. It should be instantaneous. All three distros have done this to me.
Obviously, considering how it was resolving my apt sources to 1.0.0.0, there was something strange going on with the DNS. I Googled everything I could about internet being slow with Linux. Most people suggested disabling IPv6, which I tried, with no luck. I knew it wasn't just some strange bug in Debian since my work machines (all GNU/Linux) all accessed internet resources beautifully.
Here is a useful bit of information for any GNU/Linux user who uses an Actiontec (or similar) modem with DSL internet who is having similar issues: Actiontec modems don't seem to support the high-speed DNS resolution that Linux apparently does. I know little more about how DNS works beyond starting and configuring bind9, so I don't know exactly how to explain this phenomenon. Windows can get out just fine, but Linux seems to suffer a bit of slowdown.
So here is the trick to fixing it:
Don't use local DHCP or DNS servers. I'm behind a router as well as this modem, but these computers never leave my house so I prefer static addressing. It's faster and gives me more control (since I forward a lot of different ports to different machines). Use whatever local IP addresses your local DHCP service would assign, but use your ISP's DNS servers.
If you don't know how to obtain them, access your modem's configuration (your default gateway as a web URL) and check its connection status to determine what the primary and secondary DNS servers supplied by the ISP are.
Next, as root, place those into your /etc/resolv.conf file:
search
nameserver x.x.x.x
nameserver x.x.x.x
The first and second are primary and secondary DNS addresses, respectively. I also recommend using static addressing because this file won't get changed by DHCP (assuming DHCP affects this file, I've never checked to see).
Also, if you're using static addressing, make sure both nameservers are on the same line in your /etc/network/interfaces file:
dns-nameservers x.x.x.x x.x.x.x
Then do a networking service restart:
/etc/init.d/networking restart
Try it out. I can load websites instantly (thus discovering that Lynx isn't slow at all), all my IM software works, and I can do SSH logins instantaneously.
If that doesn't work, then try disabling IPv6, that seems to be a common solution for many people as well. :)
-MrFusion
Then, my apt-get would quit working, it would cease up trying to connect to my apt sources, resolving them as 1.0.0.0. I would not be able to connect to any instant messenger services (even though they worked fine before) and browsing websites would become unusually slow. When I'd boot into Windows, everything on the internet was quick and responsive. Whenever I would SSH into the machines, either remotely or locally, it would hang up for about 5-10 seconds while authenticating both my login name and password. It should be instantaneous. All three distros have done this to me.
Obviously, considering how it was resolving my apt sources to 1.0.0.0, there was something strange going on with the DNS. I Googled everything I could about internet being slow with Linux. Most people suggested disabling IPv6, which I tried, with no luck. I knew it wasn't just some strange bug in Debian since my work machines (all GNU/Linux) all accessed internet resources beautifully.
Here is a useful bit of information for any GNU/Linux user who uses an Actiontec (or similar) modem with DSL internet who is having similar issues: Actiontec modems don't seem to support the high-speed DNS resolution that Linux apparently does. I know little more about how DNS works beyond starting and configuring bind9, so I don't know exactly how to explain this phenomenon. Windows can get out just fine, but Linux seems to suffer a bit of slowdown.
So here is the trick to fixing it:
Don't use local DHCP or DNS servers. I'm behind a router as well as this modem, but these computers never leave my house so I prefer static addressing. It's faster and gives me more control (since I forward a lot of different ports to different machines). Use whatever local IP addresses your local DHCP service would assign, but use your ISP's DNS servers.
If you don't know how to obtain them, access your modem's configuration (your default gateway as a web URL) and check its connection status to determine what the primary and secondary DNS servers supplied by the ISP are.
Next, as root, place those into your /etc/resolv.conf file:
search
nameserver x.x.x.x
nameserver x.x.x.x
The first and second are primary and secondary DNS addresses, respectively. I also recommend using static addressing because this file won't get changed by DHCP (assuming DHCP affects this file, I've never checked to see).
Also, if you're using static addressing, make sure both nameservers are on the same line in your /etc/network/interfaces file:
dns-nameservers x.x.x.x x.x.x.x
Then do a networking service restart:
/etc/init.d/networking restart
Try it out. I can load websites instantly (thus discovering that Lynx isn't slow at all), all my IM software works, and I can do SSH logins instantaneously.
If that doesn't work, then try disabling IPv6, that seems to be a common solution for many people as well. :)
-MrFusion
[0 Comments
| Add Comment
|
]