Slashdot Mirror
Sloppy Linux Admins Enable Slow Brute-Force Attacks
badger.foo passes on the report of Peter N. M. Hansteen that a third round of low-intensity, distributed brute-force attacks is now in progress — we earlier discussed the first and second rounds — and that sloppy admin practice on Linux systems is the main enabler. As before, the article links to log data (this time 770 apparently already compromised Linux hosts are involved), and further references. "The fact that your rig runs Linux does not mean you're home free. You need to keep paying attention. When your spam washer has been hijacked and tries to break into other people's systems, you urgently need to get your act together, right now."
That system you have with SSH facing outwards - right now: PermitRootLogin no, PubkeyAuthentication yes, PasswordAuthentication no, Allowusers one-guy-only
sudo apt-get install fail2ban
THL phish sticks
And boxes are still being hacked by *bruteforce* attacks?
I thought SSH Public key auth. is so 20th century.
Colorless green Cthulhu waits dreaming furiously.
What is the Slashdot crowd using these days for log monitoring?
My /var/log/auth.log might be filled with WARNING BRIAN YOUR DOG HAS BEEN COMPROMISED BY ENEMY AGENTS for all I know.
this time 770 apparently already compromised Linux hosts are involved
<sarcasm> chmod 750 ? </sarcasm>
___
It's the end of my comment as I know it and I feel fine.
Only the strong survive.
I want to delete my account but Slashdot doesn't allow it.
Ah, but things like denyhosts [1] with distributed reporting can and does catch these attacks. [1] http://denyhosts.sourceforge.net/
Couldn't we remove "Linux" from the headline and have it be just as accurate?
My sister opened a computer store in Hawaii. She sells C shells by the seashore.
That system you have with SSH facing outwards - right now: PermitRootLogin no, PubkeyAuthentication yes, PasswordAuthentication no, Allowusers one-guy-only
I'm sorry, but unless you have a laughably bad root password, this advice is unnecessary.
Even at 1 connections a second, in an entire year, an attacker could only guess 525,960 combinations. 10 connections a second?(REALLY fast...) 5.2M/year.
171,000 words in the English language, roughly. Pick two numbers, and now you're at 17 million combinations, and that's only assuming you put the numbers in one spot. Assuming they manage 10 connections a second, know the scheme you're using and hit it half-way (a HELL of a lot of assumptions in their favor) you're still looking at 1.6 years.
Two english words and a number? 292 BILLION combinations.
Please help metamoderate.
This attack was first reported last November, eleven months ago, and again in April of this year, 180 days ago.
IF the bad guys have been able to capture only 770 Linux boxes since April that is only slightly more than 4 boxes per day. At that rate it would take them 833 years to create a Linux bot farm equal in size to the 1.3 Million Windows bot farm recently reported. Out of the millions of Linux boxes in use 770 represents a vanishingly small threat.
Using this "threat" as an excuse NOT to move from Windows to Linux, or to move from Linux back to Windows, would be similar to playing Russian roulette with a fully loaded revolver and hoping to survive.
Running with Linux for over 20 years!
They will eventually compromise a system which has keys for other systems, so the success rate will increase.
http://michaelsmith.id.au
So this guy is seeing 6,000 attempts to break in via SSH over 4 days. That averages about 1 per minute. His earlier attacks were on a similar scale. And apparently he has long windows where there aren't attacks. While being attacked is never good, this rate of attack doesn't seem newsworthy. Welcome to the internet, it's dangerous out there! I had no doubt that botnets were being used for attacking a variety of services, so I would expect to see them attacking SSH. Going slowly is slightly clever, as it does reduce the likelihood of tripping some detection measures, but good fundamental security should be as effective against this attack as any other. Am I missing something about why this is actually interesting? Or is it just a really slow news day.
Search 2010 Gen Con events
Incompetence with security matters means you will get owned sooner or later, whatever OS you're running. There are plenty of microsoft tools out there to secure your shit, just as there is for Linux or any of the BSDs.
I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
I use BFD and CPanel enforced strong passwords. I don't know how well BFD would do against distributed attacks though. I also don't allow SSH access to just anyone, and if I do, it's using public key authentication, but they have to have a very good reason. SSH is also listening on a non-standard port. Really, the vast majority of clients will never *need* SSH.
I haven't updated my server since 2004. it runs debian 3.
There were all kinds of root logins from brazil last month, so I did permitRootLogin no but haven't got any farther than that yet.
It is colocated and they haven't sent a bill in 4 years so I don't want to go in and upgrade it or they might realize it is there!
All you need to drop any unsuccessful SSH logins for a specified period of seconds. /usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --set /usr/sbin/iptables -I INPUT -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --update --seconds 1000 --hitcount 2 -j DROP
Eth1 is obviously your public NIC
--hitcount is the number tries allowed
--seconds is, well, seconds the IP is dropped into a bit bucket for!
Sorry, text came out crap for some reason, trying again to make it clearer.
/usr/sbin/iptables -I INPU= T -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --set
/usr/sbin/iptables -I INPU= T -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --update --seco= nds 1000 --hitcount 2 -j DROP
Does any Linux distribution come with a default ssh config that allow root to login via ssh?
When it gets to 777 all users will have read/write access to the files!
I believe the default gentoo configuration file does. There is nothing wrong with allowing root to login.
Air Jordan 4
Air Jordan 5
Air Jordan 6
Air Jordan 7
Plenty do. Slackware, Fedora, CentOS, Debian, just to name a few.
I'm starting to think GNU is the problem with "GNU/Linux" these days.
Not that I've done much in a big professional system, so feel free to tell me to STFU and go home...
Wouldn't it be feasable to ban IPs with X unsuccessful login attempts for long periods of time (perhaps longer than the "user must change password" time)? Perhaps making X something larger than the per-user login attempt ban so one bad day doesn't ruin loggin in forever?
This is great advice, for when you must accept password-based SSH logins, and I use it myself.
Unfortunately the style of attack discussed in the article is one that gets around this, by being both slow and distributed, so that rate limits based on IP address per unit time are effectively useless.
The problem with 292 billion combinations or even just 17 million combinations is that your password will not be at the last point in the combination.
My calculations on time involved the half-way mark, ie average time.
However, you missed a more critical point: my examples assumed the the attacker knows exactly what combination you're using. Which he or she does not.
Are your chosen words in English? Did you use punctuation? One number? Where is it? Did you substitute numbers for certain letters?
They have NO IDEA. Scotch2!Foo. Simple, short, and completely bulletproof. I laugh at the idiots who sit there and pound away on complex root passwords. Sure, that can be done in production environments where you then set up an SSH host key so you can get in easily (and yes, root login is necessary sometimes- ever tried to scp an important system file? Pain in the fucking ass if you can't login as root.)
Here's a simple test: run John overnight on your shadow file. If it can't guess your password, nobody's ever going to get in via ssh by guessing your root password. Ever. John tries passwords by the THOUSANDS per second...
Please help metamoderate.
Sorry, text came out crap for some reason, trying again to make it clearer.
/usr/sbin/iptables -I INPU= T -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --set
/usr/sbin/iptables -I INPU= T -p tcp --dport 22 -i eth1 -m state --state NEW -m recent --update --seco= nds 1000 --hitcount 2 -j DROP
Yep, pretty much. Try rejecting with tcp reset if you want the bots to give up faster.
iptables -A INPUT -p tcp --syn --dport 22 -m recent --set
iptables -A INPUT -p tcp --dport 22 --syn -m recent --rcheck --seconds 1000 --hitcount 3 -j REJECT --reject-with tcp-reset
I have to wonder, with such a small number of machines as this, how many of them were actually seeded by the botnetters. Just to see if they could get other Linux boxes to fall. Maybe some non-trivial number of these were/are test machines set up to try to break into.
While keys are nice, a good password policy with forced changing frequently is probably better. Ok, so you've created a key, what prevents a brute force attack on the "never-changing" key? How can a key which will never change, be more secure than a very strong password that is only good for two weeks? Odds are a key can be broken in a few months of intensive work. Or less.
I once left a machine out there and intentionally left it there with no updates, to see how long it would survive. It lived for several years before being cracked.
Than the worms enabled by sloppy Windows admins who fail to apply server patches...
I woke up in the morning with over 700 denyhosts bans a couple of days ago. Still getting 2 or 3 per hour.
Denyhosts blocks the ip of any more than 3 failed attempts. My hosts.deny (with the help of some other similar apps) has a list of over 5500 banned IPs.
Not sure if such a large list affect performance yet.
We have a few class C networks with about 30-50% usage. Any attempted by an IP address to hit port 22 on an unused IP gets put on an iptables 'recent' block list and it stays there until it hasn't been heard from for 5 minutes. It isn't a bulletproof security measure by any means but it sure cuts down the noise, which makes reviewing the logs a bit more useful.
I wish I had IPv6... assuming you can't axfr my dns zone to determine active hostnames, you have a in 2^48 chance of hitting an actual host, and a (2^48 - ) in 2^48 chance of being blocked for 5 minutes after the last time my firewall hears from you. The downside is that the hackers/bots probably have 2^48 addresses to choose from too, making my block list overflow. oh well :)
All you need to drop any unsuccessful SSH logins for a specified period of seconds.!
With a distributed attack each attacker may only try once.
http://michaelsmith.id.au
CentOS / RedHat Enterprise Linux
Obviously, you didn't RTFA, or even the summary.
These attacks completely avoid the problem, you'd have to drop the IP for several days to mitigate this attack. It is hundreds of linux boxes tagging a target and waiting a while before hitting it again. It's a slow brute force attack because no individual bot attacks a particular target more than once or twice in a given time period, maybe several minutes, maybe even several hours. The frequency of this attack was about 1500 attacks per day total, which is only two attacks per machine in the 770 bot network in a single day.
Implimenting your strategy to prevent these attacks would also mean you would be locking out legitimate users who mis-type a password for a day or more. That is not going to work in any environment I am aware of.
The brilliance of this attack is that while a bot is only attacking a particular machine once or twice a day, there is nothing stopping it from attacking other machines in the mean time. A bot can still send out thousands of attacks per day, they are just sending them to thousands of machines instead of one. Well coordinated it certainly has the same potential for building a large botnet as normal brute force methods. The downside of course is your odds of getting a particular machine are terrible, you're playing statistics to get a large botnet.
Security is mostly a superstition... Avoiding danger is no safer in the long run than outright exposure. - Helen Keller
Here's a simple test: run John overnight on your shadow file. If it can't guess your password, nobody's ever going to get in via ssh by guessing your root password. Ever. John tries passwords by the THOUSANDS per second...
Seriously. Brute force of actual good passwords is not a foreseeable option.
If it worries you that much, it's pretty easy to implement something to make the system even slower. For example, I've previously used iptables to only let each IP make three new ssh connections every minute. ssh also has that option, and it can only count failed attempts.
I turned it off because I realized that was utterly pointless, and no one was going to break in in any reasonable amount of time.
Although I've recently considered messing around with iptables on our mail server and making repeated failed ssh attempts block access to the email server, as obviously they are either malicious, or their machine is controlled by a virus, and either way, any mail from that IP is probably spam. I need to run some intersect of the spamming IPs with ssh attempts and see if there's any overlap first.
If corporations are people, aren't stockholders guilty of slavery?
This touches on another point, that is being "root" at any time other than sysinstall. FreeBSD has never (by default) allowed root logins via SSH, and I will always contend that is a "good thing". If you access a system via SSH, it is a server. If you are on a shell session on a server, you should NEVER be root-- that's what sudo is for.
If you whine about this, you are indeed a poor sysadmin. It reminds me of my friend who habitually texts while driving. "But I have never been in an accident," he says. How selfish, putting his convenience above the safety of those around him.
Suse 11 does as far as I can tell.
When I first glanced at the headline for article, I thought that "Sloppy Linux" was the title for a new distribution.. haha
Mod up... that's the best explanation of this issue I've read yet.
Want to improve your Karma? Instead of "Post Anonymously", try the "Post Humously" option.
Yes, Ubuntu does so I suppose Debian/Mint... also does.
Sure no root logon is good... changing the default port is a good idea as well!
fail2ban is good, and if you only use linux boxen to ssh in, check out SPA port knocking. fwknop and a non-default high port! Very secure indeed!
Does any Linux distribution come with a default ssh config that allow root to login via ssh?
openbsd does it :)
the problem is not the root login, it's the stupid password
I agree that running SSH on a high port might not be a good idea, but didn't understand how a non-root user, who presumably doesn't have read access to the private SSH host key, could manage to successfully run a fake without causing the MITM attack warning to come up?
If someone is going to ignore the MITM attack warning, than anyway his password isn't being protected from a variety of other attacks, so I don't know how significant your additional attack vector is.
Pool logs of failed SSH logins on a public site. Allow whitelisting on your site for trusted IPs. If a lot of people see failed logins from the same IPs, use that as the source for a list of new iptables/hosts.deny/whatever ban lists.
Obviously it's a bit more complicated than this. For one thing, you wouldn't want people joe-jobbing shared hosting services, etc. This is very analagous to the problem of spam and RBLs. Still, if this problem grows to the point where it's wasting serious bandwidth, this would be a way to mitigate it.
On the other hand, in most cases strong passwords and a non-standard port number are more than sufficient. In five years I've never seen an attempt on the ports I use. For a high profile site, where you're likely to come under closer scrutiny, you would probably have a firewall/vpn configured as well.
iptables -F
iptables -t nat -F
iptables -t mangle -F
iptables -X
iptables -N SSH_WHITELIST
# My work network.
iptables -A SSH_WHITELIST -s 1.2.3.0/24 -m recent --remove --name SSH -j ACCEPT
# My home network
iptables -A SSH_WHITELIST -s 4.5.6.0/24 -m recent --remove --name SSH -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --set --name SSH
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -j SSH_WHITELIST
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j LOG
iptables -A INPUT -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 60 --hitcount 4 --rttl --name SSH -j DROP
Tune appropriately. I find that 4 per minute doesn't generate false positives but quite effectively blocks brute forcers. You could lower hitcount or increase the seconds to your liking.
And this is just for machines where I do need multiple people to be able to login from multiple locations. On other machines I definitely use ssh key only auth via the sshd_config.
PLUS: This proves that there ARE people out there interested in breaking into Linux boxes. It's just that this is the best way they can find to do it and I think that says a lot. So let's not hear any more of this "Linux would have viruses too if it were as popular as Windows" bull. Between this and the MySQL on Windows worm:
http://news.cnet.com/MySQL-worm-hits-Windows-systems/2100-7349_3-5553570.html
and the recent Linux botnet perpetrated via password brute forcing:
http://www.builderau.com.au/program/linux/soa/Linux-botnet-discovery-points-to-lazy-administrators/0,339028299,339298642,00.htm
you would think we could put that old chestnut to bed by now.
Yeah, most all of them do. However, FreeBSD / OpenBSD get it right and don't allow root remote logins by default. Create a normal account, add them to wheel so they can su and off you go.
News at 11: once you have been compromised, you're sunk. Time to reimage or rollback the VM.
Anyone interested in log monitoring should already know that.
Since this sub-thread is about log monitoring, your comment was, er, offtopic/superfluous, although I suppose you got the Interesting mod for the TSA story.
Why REJECT? You know their knocking why let them know your listening behind the door?
Wow, how are you getting so many? I only get a few every other days. I wonder if it is because I am residential?
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
how does that compare to windows-botnets with > 1,000,000 zombies? (don't tell me this was because of linux' low marketshare - linux has around 10% marketshare if you count the servermarket. So if marketshare was the only factor, then there shouldn't be much more than 9 times as many infected windows machines, so windows botnets with more than 6,930 zombies would already be newsworthy either)
rtfa - it says there are 770 bots with 32 attempts each - that's less than 26^4 so this can't even brute-force passwords with 5 lowercase characters!. So this means that
in both cases: if you use such a weak ROOTpassword, it's your own fault!
IMHO this is just an attempt to badmouth linux, by an OpenBSD fanboi (btw. I respect OpenBSD, but I think its installer should be easy enough for a graduate computerscientist to use it...)
The MAFIAA is a bunch of mindless jerks who will be the first up against the wall when the revolution comes
Welcome to denyhosts.
Belief is the currency of delusion.
AFAIK this is part of one of the SSH blocker efforts, DenyHosts. I found you need to change the window failed attacks are detected in as the people trying to break in appear aware of the current default (at least, that's what my logfiles appeared to suggest).
However, there are more things you can do, and I agree that just changing port numbers makes an enormous difference.
Insert
A properly configured hosts allow/deny
Rejects 99.9999% of connection attempts before they can even begin to guess.
"GET / HTTP/1.0" 200 51230 "-" "Mozilla/4.0 (compatible; Setec Astronomy)"
Sounds like we should set up a reverse botnet with a rating system, then.
Talk to some other companies you know, create a system that takes a list of failed logs, anonymizes it somewhat and publish it. They do the same, you all have a system that pulls down the list from the others and puts that into a list of "hosts we probably don't want to talk to, because they have tried as root@othercompany.com".
If the lists are properly anonymized and we have a rating system so getting bad data into the system is harder, I think we'll have more or less countered them for now.
I'm sure the next reply will tell us all about somebody who already has this designed and set up.
head -n 1
Sep 6 06:25:34
4745 61.143.178.194
3301 219.131.173.42
2357 200.229.119.104
2263 219.94.174.90
1653 87.106.252.228
1297 211.157.98.64
1194 125.208.1.40
1042 72.55.143.45
870 67.44.64.154
642 62.212.66.84
(top ten results, there's another 53 hosts, totalling 24641 failed logins)
This is a PC on a (fast) home ADSL connection. The reverse IP is dynamic, but a couple of minor domains point to it.
Damn, lost the command: /var/log/auth.log | grep '^...............' --only-matching; grep 'Failed password' < /var/log/auth.log | grep ' [0-9.]*\.[0-9.]* ' --only-matching| sort | uniq -c
head -n 1 <
The article have very good point. However the hosting service blogger.com has really incompetent web designers and that really detracts from a fairly important post.
Can we pull the handful of competent web designers, that presumably once existed, out of retirement and have them clean up the major web sites?
Beta is broken and the link to classic doesn't work. Stop wasting our time or there won't be anybody left here.
If you believe that, then this article is about you. There is NEVER any need for a direct root login.
all disabling root login does is prevent the following:
ssh -l root some.domain.com
You can still login with
ssh -l user some.domain.com
and once connected you can su to gain root. The whole idea is to isolate root from the outside world, restricting root access to localhost only. Or are you happy with the world having direct access to the single most important account on the machine ?
This attack prevalence _really_ needs support in sshd itself, we need an
SshAttackDelay int
so that SSH enforces a GLOBAL delay, int seconds (0==none) after accepting remote connections, before DH or PW/Key
response, for int seconds after any failed login, root or otherwise.
You can do this with IPtables, but you may have to enable additional kernel modules eg contrack; and its a kludge anyway.
SshAttackDelay 5
would ensure max 1 try ever 5 seconds and impede valid logins for a max 5 seconds; then good luck with fast, slow or other ssh attacks!
This is Slashdot, aren't all sysadmins fascist bastards who put needless restrictions in place for no good reason, that stop people do what they want to?
~~~~~ BigLig2? You mean there's another one of me?
So how, exactly, does one know whether a Linux box has been compromised?
Windows machines have an entire industry of antivirus software. We... don't. Dislike Windows as much as you like, but the mere fact that Windows is so insecure means that people are aware of it being insecure, and so the tools are available to deal with the problem.
What does a Linux user do? I know of tools like chkrootkit and rkhunter, and run them, but I have no idea if they're any good. What's the recommended way of finding out whether you've been compromised? Waiting for SORBS to blacklist you probably isn't the best way...
Perhaps you are unusual in that you seem to be picking dictionary words uniformly at random, leading to an average complexity of half the search space. Sadly most people are not very good at picking random numbers and if you told them to use this method the probability is exactly one that they would choose fuckdonkey69...
Joking aside, using John is very good advice. It actually sorts the search space to pick common layouts of dictionary words plus fillers first. If it can't find your password then it is pretty secure.
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
You can pick something non-standard below 1024. That cut down (but did not eliminate) the
crap for us.
you don't urgently need to get anything together, right any time. this is a condescending load of bullshit.
Let me make the same mistake you made and state: In the same way that it is impossible to use system logs to detect a compromise, it is in general impossible to conclude that a system is compromised even given a full dump of its state (stopping problem).
But we all know that that is not the case in reality/practicality, only a minuscule fraction of compromised systems would be compromised in such a careful way, leading us to believe that it is worthwhile to try to detect compromise.
I personally like to reject with the wrong message, such as no route to host. Some statefull IPS systems that you might have in front of the firewall like to keep track of the connections, by issuing a drop, that IPS doesn't know the connection went away. If you're getting pounded, it can actually make the IPS start losing/refusing connections. This includes the legitimate traffic to your web-server. SonicWall works this way. So sending back a BS message lets the IPS know that the connection is bad, and that it should drop it. While at the same time confusing the attacker, that a particular hosts doesn't even exist. "you hope." If you don't have something like that to deal with, then I'm all about the DROP.
You can get 99% of the port knocking benefit by simply running ssh on another port.
Almost all ssh attacks are automated, and if you're not running something on port 22, you won't be attacked.
So essentially you're left with people who are specifically targeting you, and portscan the system. Those are the sole people that port-knocking protects against.
It's too bad that SRV records aren't more prevalent.
Someone doing a random scan wouldn't get know the real port with scanning everything, while someone doing a normal 'ssh hostname' would get the correct settings automatically as part of the DNS look up.
by definition, a well designed OS does not have sloppy admins, because the default is correct, and to deviate from the default and setup systems with bad security takes a lot of effort and know how.
I've never seen such attacks in the real world. On a particularly hard hit system (which I also have access to), I have never see more than a few hundred failed logins per day. At that rate our V34y_l0n6-9455w0rd is going to take hundreds (of thousands?) of years to brute force.
Granted, we aren't Yahoo, Google, or Matt Drudge, but we get hit pretty good traffic.
I sometimes boot Ubuntu 8.10 and 9.04 from an SD card on an EeePC and leave it connected to the network for long periods (days) of time. I use the EeePC mainly for surfing. It's just the default Ubuntu. Being the only user, I have not set up any users or passwords. Does the the default configuration of Ubuntu allow telnet/ssh logins over the network?
The short answer: You're probably safe. But to make sure, go into your package manager (probably Synaptic) and look for the package openssh-server. If it's there, remove it — you don't need it for the desktop unless you want to be able to get into the computer from somewhere else.
Long answer: Telnet is definitely not a problem; nearly all Linux and BSD distributions stopped installing the telnet server by default years and years ago. As for SSH: if it's the "Live CD" version you're booting from the SD card, it won't have an SSH server either. (Because you claim to have no username/password, I suspect you're booting the Live CD from the chip. An installed Ubuntu prompts for username/password.) And I'm pretty sure Ubuntu doesn't install it on the desktop installs either. Maybe Server Edition does. But see the short answer above for the definite answer. openssh-client is OK to have — it's just openssh-server that allows incoming connections.
Every system on the internet **can** be hacked. Get over it.
You need to have a recovery plan for **after** the hack occurs.
Simple. Take snapshots every few hours. Take backups every day. Get the backups off-site. Test recovery to a different system. The simplest solution for non-matching hardware is virtualization - Xen, LVM, VMware all let you virtualize your hardware and drivers. This is nothing new folks. Don't use virtualization at your own peril.
Some of the easiest things to do for security are not to use static passwords and use methods to prevent network access without authentication. RADIUS standards are cross platform and work with almost any hardware and vendor. Use it, know it, love it.
My security has been kept simple, but effective for my particular situation. My software firewall allows remote connections only from certain IP addresses, which minimizes my exposure. But on top of that, I require reasonable good passwords for the users I allow on my desktop systems.
When I first got DSL over three years ago, I noticed a dictionary attack rate of about a thousand attempts per month. After I installed Firestarter, and configured it to disallow all SSH connections except those from particular IP addresses, the attacks came to a complete halt. I haven't had a single SSH attack show up in my logs since.
probably because that is the default for openssh, at least for version 5.1p1, :)
of course that is no excuse
one should change the defaults to suit their needs
see sshd_config:
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.
.
.
.
#PermitRootLogin yes
How does the world have direct access? They need a password or a private key. What about allowing root login, but requiring a private key, and disallowing login using a password? I'm considering that, and am wondering if there is a consensus about it.
Really? How do you SCP system files in a hurry without root access? Assign everything to wheel?
more attackerstats.pl
#!/usr/bin/perl
# attackerstats.pl (c) 2009 by Matt Rosin / GPL 3.0 License
# Usage: perl attackerstats.pl iplistfilename
# will show how many times each attacker has attacked, given a list of ips
# To get ips from vsftpd logs:
# grep FAIL logs.vsftpd | perl -nle 's/^.+FAIL\sLOGIN:\sClient\s\"(\d+\.\d+\.\d+\.\d+)\"$/$1/g; print;'
# To get ips from authd logs:
# cat logs.authd | perl -nle 's/from\s(\d+\.\d+\.\d+\.\d+)\sport/$1/g; print $1;'cat attacks |perl -nle 's/from\s(\d+\.\d+\.\
d+\.\d+)\sport/$1/g; print $1;'
my $f = $ARGV[0];
unless ($f) { print "Usage: perl attackerstats.pl iplistfilename\n" unless $f; exit 0; }
my %h = ();
open(IN,$f);
while() {
chomp;
my $ip = $_;
$ip =~ s/\s//g;
$h{$ip}++;
$lines++;
}
my @hk = keys %h;
my $numattackers = $#hk + 1;
print "Tallied $lines lines for $numattackers attackers.";
my $sortblock = q( $hash{$b} $hash{$a} );
use Tie::SortHash;
tie %h, 'Tie::SortHash', \%h, $sortblock;
print "\nSORTED ATTACKER IPS BY NUMBER OF ATTACKS\n";
foreach my $k (keys %h) { print $k . "\t" . $h{$k} . "\n"; }
print "\n\nDone.\n";
Mine:
# head -n 1 /var/log/auth.log | grep '^...............' --only-matching; grep 'Failed password' /var/log/auth.log | grep ' [0-9.]*\.[0-9.]* ' --only-matching| sort | uniq -c
Oct 4 06:47:04
8 190.202.98.211
16 88.87.196.105
I block brute attackers after failing three times.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
How about limiting SSH access for a restricted set of IP address?
Yes. I copy it with my regular, non privileged account and then change ownership and permission in the target machine as root.
You don't need root for one of transfer of files.
IANAL but write like a drunk one.
Either generated in advanced or with tokens (SecurID or similar).
IANAL but write like a drunk one.
Logs should go either or as well to a log server, whose only available service is syslogd and perhaps sshd.
IANAL but write like a drunk one.
This is indeed a problem. Turning root off is quite a hassle but, it has made me a better sysadmin.
Two ways around scp root problem is to either change the directory permissions or use rsync with which you can use sudo.
sudo su -
Post your IP, then!
PS: mine is 127.0.0.1, kiddies.
http://www.hexten.net/wiki/index.php/Pam_abl
The pam_abl module monitors failed authentication attempts and automatically blacklists those hosts (and accounts) that are responsible for large numbers of failed attempts. Once a host is blacklisted it is guaranteed to fail authentication even if the correct credentials are provided.
Blacklisting is triggered when the number of failed authentication attempts in a particular period of time exceeds a predefined limit. Hosts which stop attempting to authenticate will, after a period of time, be un-blacklisted.
And since many people enable sudo for their account in order to make it easier to admin their boxes, this won't necessarily make their boxes any more secure:
ssh -l user some.domain.com
sudo su -
They just use the same password from the user and they're root. Woops.
You still haven't presented a convincing argument that permitting root to login is inherently insecure.
I have several linux boxes that permit root login via keys and password. In six years none have been compromised.
Nobody but me has access to root on these systems and it wills stay that way because I use and remember proper passwords.
You're correct for sudo (although there is a setting to require root password to use sudo). I've never seen su allowed without providing the password for the account you're trying to become. The exception is if you're already root, you can become anyone. Disabling remote root login is just another layer of defense. If the attacker can't use root, their job is just that much harder. He dictionary attack 100 root password guesses, or go through a list of 100 user names with just one password.
I don't open SSH to the outside and only use it over an encrypted tunnel. Fail2ban and DenyHost are your friend layered with RBL's and snort. Works decent against web attacks too!