Slashdot Mirror
Rundown on SSH Brute Force Attacks
An anonymous reader writes "Whitedust has a very interesting article on the recent SSH brute force attacks. The article goes into depth on how to monitor these attackes and to report them to the authorities. It also discusses various tools that are available. According to the article, mostly compromised Linux systems from outside of North America are responsible for the attacks. Even the author's DSL connection was getting break-in attempts."
Since it's a brute force attack and not using some bug that's been known but not patched for months, I'd say so. However, this is about SSH, not Linux so it's irrelevant.
If possible, restrict access by source IP address, limit the user accounts w/ SSH access, and don't allow remote root logins.
Another step to improve security if there are very few users is just to ONLY allow public key authentication. I've never seen such a box compromised remotely.
Throw the bums out!
What are we going to see next on Slashdot? A review for the movie "Scr1pt k1dd15"? I was interested when I saw the link and after clicking on it, I was sadly disappointed. This has nothing to do with SSH, and could just as easily be used on Apache logins, FTP, Telnet, IRC, etc. Brute forcing is an old concept and is the whole reason you are supposed to use strong passwords (well that and offline password attacks).
Do what I do, drop packets to port 22!
Idiot
till the first Spaceballs "password" reference.
I have seen tons of these for 12+ months. Highly annoying. Last week I had one with over 10k connection attempts. What I need is an IDS that will just drop the remote IPs into iptables. Anyone have something like that? Of course if anyone is actually interested in reports on all the IPs, most of which usually are in .cn, I've got back logs for quite awhile. ;-P
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
just 2 ips
218.188.8.186
218.27.88.170
Jul 15 01:00:01 www sshd[46625]: Illegal user amza from 218.27.88.170
Jul 15 01:00:06 www sshd[46666]: Illegal user ana from 218.27.88.170
Jul 15 01:00:10 www sshd[46671]: Illegal user anna from 218.27.88.170
Jul 15 01:00:15 www sshd[46675]: Illegal user anemarie from 218.27.88.170
Jul 15 01:00:19 www sshd[46677]: Illegal user anamaria from 218.27.88.170
Jul 15 01:00:25 www sshd[46679]: Illegal user analusia from 218.27.88.170
Jul 15 01:00:30 www sshd[46684]: Illegal user analuisa from 218.27.88.170
Jul 15 01:00:34 www sshd[46696]: Illegal user anabel from 218.27.88.170
Jul 15 01:00:39 www sshd[46701]: Illegal user analia from 218.27.88.170
Jul 15 01:00:43 www sshd[46704]: Illegal user anan from 218.27.88.170
Jul 15 01:00:47 www sshd[46708]: Illegal user anaya from 218.27.88.170
Jul 15 01:00:52 www sshd[46711]: Illegal user anda from 218.27.88.170
Jul 15 01:00:56 www sshd[46715]: Illegal user ande from 218.27.88.170
Jul 15 01:01:00 www sshd[46718]: Illegal user adonis from 218.27.88.170
Jul 15 01:01:04 www sshd[46730]: Illegal user anders from 218.27.88.170
Jul 15 01:01:09 www sshd[46732]: Illegal user andersen from 218.27.88.170
Jul 15 01:01:12 www sshd[46734]: Illegal user anderson from 218.27.88.170
Jul 15 01:01:16 www sshd[46737]: Illegal user andi from 218.27.88.170
Jul 15 01:01:20 www sshd[46739]: Illegal user andy from 218.27.88.170
Jul 15 01:01:24 www sshd[46741]: Illegal user andley from 218.27.88.170
Jul 15 01:01:28 www sshd[46743]: Illegal user andonia from 218.27.88.170
Jul 15 01:01:32 www sshd[46746]: Illegal user andra from 218.27.88.170
Jul 15 01:01:36 www sshd[46750]: Illegal user andre from 218.27.88.170
Jul 15 01:01:41 www sshd[46754]: Illegal user andras from 218.27.88.170
Jul 15 01:01:45 www sshd[46756]: Illegal user andrea from 218.27.88.170
Jul 15 01:01:50 www sshd[46760]: Illegal user andreas from 218.27.88.170
Jul 15 01:01:54 www sshd[46762]: Illegal user andreassi from 218.27.88.170
Jul 15 01:02:00 www sshd[46764]: Illegal user andree from 218.27.88.170
Jul 15 01:02:06 www sshd[46766]: Illegal user andrei from 218.27.88.170
Jul 15 01:02:12 www sshd[46768]: Illegal user andreia from 218.27.88.170
Jul 15 01:02:16 www sshd[46773]: Illegal user andreina from 218.27.88.170
Jul 15 01:02:20 www sshd[46776]: Illegal user andrew from 218.27.88.170
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
i have had this on a number of occasions.. i just set the max auth attepts to 4, this renders the attempts useless
...to have a frontdoor made of 1 mile thick steel instead of a cardboard, so that we DON'T have contact autorities each time some bum goes through it?
I use DenyHosts http://denyhosts.sourceforge.net/ from a cronjob. It detects any suspicious logins in /var/log/auth.log and adds the ip address of the user into the /etc/hosts.deny file. It also sends me an email telling me the IP address that was last added to the file.
Lately I have been getting atleast 1 hack attempt a day on my personal computer connected to the internet over a cable connection. On weekends I get more.
Just this morning I had two ssh dictionary attacks. DenyHosts caught them both.
If they bother you, you could always use portsentry or something similar to block the IP once a certain number are received.
- Preferences: Solaris 10 (servers), Ubuntu (desktops), Solaris 11 (personal servers) -
I don't think these are at all "recent".
Haven't these ssh-based attacks been going on since sometime like July of 2004?
The deal was that there was a SSH vulnerability in non-OpenBSD implementations of sshd. The automated stuff kicked off then -- and they've gotten a bit worse in the last few months.
http://www.thebricktestament.com/the_law/when_to_
Use a non-default port on any service whenever possible. This simple change goes a long way. Obviously it is not all you should do.
-- Note: If you don't agree with me, don't bother replying. I won't read it.
I've seen many attempts to log in to my system via SSH. Oddly enough, since I never enabled SSH2, a lot of the attacks fail due to incompatible SSH versions.
8 . 172.160.19. 98
1 2.167.162.5. 246.34
Some of the IPs I'm seeing trying to log in (break in) are:
211.98.192.91
66.194.210.4
210.188.243.20
200.198.184.135
222.122.25.100
211.87.224.192
62.231.44.113
212.202.220.163
62.75.216.10
81
82.127.73.97
82.76.47.40
206.170.12
61.133.218.110
216.70.203.62
66.220.1.112
80.190.243.50
62.75.216.10
221.249
152.92.7.212
210.118.193.95
82.76.47.40
61.135.134.238
I got annoyed enough that I wrote a little script to pull the data out of my logs in real time and add an entry to my firewall, but the attacks are harmless to any sysadmin with a clue.
-Matt
The simple, old attacks are sometimes the most dangerous because you start to assume there's no problem with them. You forget about them. They become a blind spot. The point of the article is to remind you, linux can be just as insecure as windows if you do stupid things like choose bad passwords.
Use another port than 22. I have not noticed one single bruteforce attempt after I did that.
objorkum dot com
I had a lot of these attempts. I just set max autorization atempts to 4... renders these attacks useless.
If setup a delay between the time of the password is accepted from the ssh client, and the time when you indicate a successful login with a shell prompt (or a failure message,) you would slow down a brute force attack. You should delay even delay for a successful login, because if the brute force program doesn't see a shell within a second, it could simply assume it failed and try another. Also, you should be behind a router (OpenBSD and an old PC is what I use.) If you don't need sshd available from outside your LAN, simply don't forward the port. You may consider keeping your LAN on RJ45 (not wifi) to reduce the risk of malicous login attempts. Make sure your wireless access point is locked down as much as possible if you must have it. Blacklisting an IP after say, 7 unsuccessful logins and logging the incident is a good idea (and perhaps have the sysadmin notified of the event.) Some ways to alleviate the risk.
Powered by caffeine and sugar; BSD
I was just reviewing one of these today from Miami University (Ohio).
...
Jul 15 04:55:51 combust sshd[12125]: Did not receive identification string from 134.53.130.197
Jul 15 04:59:57 combust sshd[14758]: Invalid user president from 134.53.130.197
Jul 15 04:59:57 combust sshd[1219]: input_userauth_request: invalid user president
Jul 15 04:59:57 combust sshd[1219]: Failed password for invalid user president from 134.53.130.197 port 57698 ssh2
Jul 15 04:59:57 combust sshd[14758]: Failed password for invalid user president from 134.53.130.197 port 57698 ssh2
Jul 15 04:59:57 combust sshd[1219]: Received disconnect from 134.53.130.197: 11: Bye Bye
Jul 15 04:59:58 combust sshd[29612]: Invalid user bob from 134.53.130.197
Jul 15 04:59:58 combust sshd[7875]: input_userauth_request: invalid user bob
Jul 15 04:59:58 combust sshd[29612]: Failed password for invalid user bob from 134.53.130.197 port 57789 ssh2
Jul 15 04:59:58 combust sshd[7875]: Failed password for invalid user bob from 134.53.130.197 port 57789 ssh2
Jul 15 04:59:59 combust sshd[7875]: Received disconnect from 134.53.130.197: 11: Bye Bye
Jul 15 05:00:00 combust sshd[22372]: Invalid user sunshine from 134.53.130.197
Jul 15 05:00:00 combust sshd[6311]: input_userauth_request: invalid user sunshine
Jul 15 05:00:00 combust sshd[22372]: Failed password for invalid user sunshine from 134.53.130.197 port 57864 ssh2
Jul 15 05:00:00 combust sshd[6311]: Failed password for invalid user sunshine from 134.53.130.197 port 57864 ssh2
Jul 15 05:00:00 combust sshd[6311]: Received disconnect from 134.53.130.197: 11: Bye Bye
Jul 15 05:11:57 combust sshd[1820]: input_userauth_request: invalid user gus
Jul 15 05:11:57 combust sshd[1820]: Failed password for invalid user gus from 134.53.130.197 port 39530 ssh2
Jul 15 05:11:57 combust sshd[23478]: Failed password for invalid user gus from 134.53.130.197 port 39530 ssh2
Jul 15 05:11:57 combust sshd[1820]: Received disconnect from 134.53.130.197: 11: Bye Bye
Jul 15 05:11:58 combust sshd[14363]: Invalid user adminweb from 134.53.130.197
Jul 15 05:11:58 combust sshd[3817]: input_userauth_request: invalid user adminweb
Jul 15 05:11:58 combust sshd[3817]: Failed password for invalid user adminweb from 134.53.130.197 port 39568 ssh2
Jul 15 05:11:58 combust sshd[14363]: Failed password for invalid user adminweb from 134.53.130.197 port 39568 ssh2
Jul 15 05:11:58 combust sshd[3817]: Received disconnect from 134.53.130.197: 11: Bye Bye
True enough. However, another limiting factor in how secure a system is would be the strength of the passwords that the users use.
password authentication for OpenSSH.
OpenSSH supports several forms of authentication and generally password-only authentication is the weakest it can support.
A much more secure versions is public/private keypair combined with a passphrase that is not related to your normal unix password.
That way if they get a hold of your keys they still have to brute force your passphrase, and if they don't have your private keys then they can't get in even if they do know the password.
Also disable root ssh access and disable any 'sudo' you have setup. That way if a hacker guesses a password he still has to find a local rights elevation exploit (which isn't terrificly difficult in Linux unless you keep things very up to date)
The other form of secure authentication is kerberos, but that is a pain to setup.
Mitigating against SSH brute force attacks using Netfilter and the recent module
-- Newbie sysadmin question --
I've noticed these scripts on my logs before attempting to access my machine (its a moot point now given my network setup, but...), how would you limit from occurring?
I'd like to do the following: If two failed connections with nonexistant usernames are used or three with a known user name, block the connectors IP subnet for a certain time (with the exception of a couple known good subnets).
The blocking would be the easy part, since some script could control iptables (or pf on a bsd machine). But outside of doing creative monitoring with with auth.log, is there another way to detect failed logins?
The idea of brute force is extremely old, but the fact that somebody is out there actually doing them is important. The use of strong passwords is no longer just a theoretical "it would be a good idea" policy, but now somebody actually is looking to get through.
Other Slashdot readers are reporting the same effect: a recent rise in brute-force, scripted attacks, possibly by compromised boxes.
Most accounts of all sorts remain secure simply because they're obscure, and it's tempting to be lulled by past successes. We always knew that this was possible, but the fact that somebody is actually doing it is news.
I've been seeing these attacks for QUITE a while now. Repeated access attempts which were guesses of people's first names as logins. I used to ban the entire source subnet, but it's futile. Now I just whitelist acceptable IPs.
To-do List: Receive telemarketing call during a tornado warning. Check.
I installed this on my server, seems to work well. Basically it keeps track of ssh attempts and after a preconfigure number of failures within a certain period of time, it bans the hosts. Hooks into tcpwrappers using hosts.allow.
The difference between Canada and the USA is that in Canada healthcare is a right and gun ownership is a privilege.
Slashdot must be really hurting for a story. I've been noticing these since the first time I put up a linux box on my home cable line. It's not a new phenomenon, and thank you very much, I know how to report an IP address for abuse.
What is this, Security for Dummies?
It shows what an automated land we live in when even the hackers are automating their attacks. The problem with this is that every compromised machine will in turn compromise more, making it very hard to stop.
Voice your opinion!
Do you have your machine directly on your broadband connection, or do you have port 22 forwarded to the router? I don't have port 22 forwarded, and I have never seen this. Sorry if this is too obvious. Do you need to login remotely from work or something? Maybe you could only allow a certain IP?
Powered by caffeine and sugar; BSD
I've never understood this advice. If the crackers get hold of an admin account, all they need to do is upload a trojan 'sudo' or 'su' program and wait. I've done so myself on one system (making sure I tick the 'anonymous' box). Blocking root logins doesn't increase security, it just annoys root.
Counter agruments?
If you only need access from a limited set of machines which can have pre-generated keys, you can disable password authentication entirely (PasswordAuthentication no) and use RSA instead, with optional passphrase. In addition to PermitRootLogin no, I suggest judicious use of AllowUsers in sshd_config.
you had me at #!
We use sshd_sentry which puts the IP address into the hosts.deny list for 24 hours after five failed attempts. This eliminates the problem completely and it doesn't fill up our logs with useless trash.
I am thinking of doing the same thing for relay attempts because that seems to have become the new sport. One reject you would think would be quite sufficient, but no, we're getting a hundred or more requests from the same IP address.
For those that want to check their own logs. I just get a sprinkling of those, maybe an average of one or two a day.
One line blog. I hear that they're called Twitters now.
A good thing to do is to use the AllowUsers configuration directive for sshd in /etc/ssh/sshd_config. The following would allow some account named 'unprivguy' authenticated ssh access from anywhere. All other ssh connections must come from local and local domain authenticated users. So root@localhost or root@*.mydomain.com could log in. All others are blocked, even if they have the password.
AllowUsers unprivguy *@*.mydomain.com *@localhost
You still see the attempts in your logs, but now you also see:
User root not allowed because not listed in AllowUsers
Too much trouble. If you want someone to log in, you'll have to tell him to use the non-standard port.
Brute force attacks are the predominant form of attack on my web server, which are host to several large web shops in Scandinavia. Just this weekend, I've gotten tons of requests from 80.18.87.243 and 200.163.190.132. Most attacks come from Italy, South-America, Korea and China... We don't have a root login, and the user logins are restricted, so the login attempts are annoying more than anything else.
I tried to post this in the talkback on the article but it got horribly munged.
Here are the iptables rules I use to dynamically stop this kind of thing (with a good degree of success):
# SSH
-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --rcheck --hitcount 3 --seconds 600 -j LOG --log-prefix "SSH attack: "
-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --rcheck --hitcount 3 --seconds 600 -j DROP
-A PREROUTING -m tcp -p tcp -d $EXTERNAL --dport 22 -m recent --set -j DNAT --to-destination $INTERNAL:22
-A OUTPUT -m tcp -p tcp -d $EXTERNAL --dport 22 -j DNAT --to-destination $INTERNAL:22
Your mileage may vary. This blocks attempts for 1 minute after 3 attempts (successful or failed, so if someone forgets their password, they may trip it as well).
Green's Law of Debate: Anything is possible if you don't know what you're talking about.
Personally, I find port knocking useful in providing an extra layer of security.
Some of the systems that I am responsible for, have restrictions on when and how I can apply patches. So if a vulnerability is discovered, if I cannot patch it right away, I am relying on my FireHOL and port knocker to protect these systems. Since implementing these measures (and good security policy), none of these machines have been compromised in three years.
Of course, saying that, I probably just jinxed it...
Most of the attacks I see originate from Korea. Its gotten so bad that we are finally blocking around 3 class A (CIDR/8) networks from our border routers that belong to KRNIC/KORNET/HANANET.
I hope they enjoy their intranet.
It's true no man is an island, but if you take a bunch of dead guys and tie 'em together, they make a good raft.
I've been seeing these sorts of "attacks" in number since I installed my Linux Desktop machine about 6 months ago. I'm only on plain ADSL that isn't published, not like I'm a likely target.
Every day I get two or three new attackers, most of whom try 50-60 times on common account names (fred, jeff, user, test etc.) and about one a week that goes full-bore for a particular username or a large spread of a few thousand attempts.
I took the appropriate measures... disallowed root login, use public-key authentication only and I also have a script that checks through my logs once every five minutes, permanantly blacklisting anyone who has more than five attempts within a 7-day period (except for known whitelist addresses).
Currently, it runs to 390 unique lines of IP's, some of which have come via
http://www.cyber-defense.org/blacklist.txt
and at least 50% from my own blacklist. That site (http://www.cyber-defense.org/ incidentally, also notices the same phenemona.
I made an account for my dad on my mom's computer so he could have a samba share over the network, and gave it a really easy, completely forgetting that it was also accessible via ssh. Fortunately, I added their computer to my personal DNS domain so I could remember how to get to it easier. Shortly after it was compromised, I got an email informing me that phish spams were being sent from the computer.
.bash_history file His only attempt to gain root access was to run 'sudo'. He copied over a list of people to spam, a mail script, and an email. He fired off a test email first, and then spammed the email list. A couple days later, he copied over a different list and message and sent those off. After that, I was tipped off and sealed off his entry.
I analyzed the system, and quickly determined that the person was not a big time hacker. Looking at his
Since he made no effort to cover his tracks or avoid detection, either this script-kiddie didn't know how to, or had so many computers to manage it wasn't worth his while to do so.
Looking for a computer support specialist for your small business? Check out
I sleep just fine now.
PHEM - party like it's 1997-2003!
I've been logging and reporting these attacks since last October (when I first started using BFD). I'm figuring they've been going on for a long long time. A simple install of APF and BFD will keep you from having too much trouble though. That and making sure noone is using easy to guess passwords.
APF and BFD can be got here: RFX Networks.
StrategyTalk.com, PC Game Forums
The article goes into depth on how to monitor these attackes and to report them to the authorities.
... how very ... twentieth-century.
....
The authorities
Better we should self-organize our collective defense.
Peer-to-peer government -- making the nation-state obsolete, one node at a time
-kgj
-kgj
I've seen these in my logs as well: 168.148.40.58 210.22.153.134 80.55.129.94 195.184.172.1 195.5.57.5
They came for the Communists, and I didn't object - For I wasn't a Communist; They came for the Socialists, and I didn'
Once a month or so, I check the list of banned IPs & manually report U.S. ones to the relevant abuse@ email addresses (figuring that they can de-zombify the boxes.
I just disabled any SSH use without a key. Duh, right?
-- 'The' Lord and Master Bitman On High, Master Of All
The solution is to not expose SSH to the Net without disabling interactive authentication. IMHO anyone not using certificates or IP access-lists is being negligent.
UsePAM no
Never ascribe to malice what can be adequately attributed to ignorance. -Napoleon
Have been seeing these on my public Linux boxes for 6 months. Trivial to stop. Just allow only unique user names, enforce good passwords, etc...
Traced one attack from a Windows box in an Ohio school.
This guy is way out there
This has to do with Linux getting to the mainstream... people are using lame passwords and leaving unnecessary services with weak passwords open to the public. (Hey, if you'd know how many people **I** alone know that use "password" or "god" or "mom" as their root (*nix/bsd) or admin (windows) passwords. (Or, funnier still, the ones who leave it blank for ease of use.)
Do people on slashdot NOT know what a brute force / dictionary / wordlist attack is??? It is an attempt to connect to a service, using a random or scripted password and username generator or a list of commonly used ones (root and administrator on various systems obviously comes to mind.)
Most people use SSH without redirecting it through a trusted tunnelling protocol or connection. There are many ways to secure even the most trivial home network.
A word to the wise... instead of clicking okay and next mindlessly when installing your OS, start making a practice of READING the warnings and learning something... it should keep the brown fat cells from drowning out your otherwise idle brain as you get older. (IANAMS - I am not a med student, but so I've heard)
-DaedalusHKX
" What luck for rulers that men do not think" - Adolf Hitler
if your ssh server needs to be publicly available, you can always have it listen on a different port. that seems to thwart 100% of these automated attacks.
Gyrate Dot Org - "Where high-tech meets low-life"
This lame attack can be thwarted with an equally lame response. Any of the following can stop it:
a. Change default port from 22 to something else.
b. Put a delay in iptables for new connections.
c. Portsentry - Sourceforge
d. Denyhosts - Sourceforge
Changing the port number is the easiest, but a delay rule in netfilter is a good way to stop any brute force attack, so it is a generic solution. Portsentry and Denyhosts has the danger that you can lock yourself out, if you are not careful.
it should be noted that these attacks have been going on since at least 2003.
Gyrate Dot Org - "Where high-tech meets low-life"
Yes, good point. I always try to have more than one machine configured with access for this reason.
It's also important to revoke keys if the client machine is stolen or otherwise compromised, although passphrases help in this situation.
you had me at #!
I've never understood this either. Once they get in as some other user, can't they just start bruting root via su? If there are better brute protections there than in SSH, then just make the SSH protections more robust...the problem has nothing to do with root.
Also, if you are not logging in as root simply because you want to make the attacker break two passwords, just make your root password ecompass the keyspace of both of them and it is just as secure as two.
The 'dont run as root' mantra I don't take much of an issue with, because some exploits can only work if someone is logged in as root on the system at the time... although even then 99% of this advice is just based on the fact that most people do stupid things and root lets them screw it all up worse, not an any real security concern. But not logging in via SSH as root is just ridiculous.
On Windows, you can't remote login to a user with a blank password. I believe the same is true with Linux.
I tracked down an IP to a local ISP in the middle of an attack and the ISP just didn't care. They should do something to the owners of the computers attacking whether their zombies or not.
One of my favorite features of Tiger Server is that I can enable ssh login (and just about every other service including console login) only for the users I choose. That way, even if one of my lusers' accounts is compromised, the bad guys can't get to a command line.
/bin/false. That way if I screw something else up, there's no way anybody's launching a shell as them.
Oh yeah, and I (manually) set their shell to
Last, Tiger doesn't have passwords for any of the standard unix accounts, so no amount of dictionary attacking is getting in.
I'm sure most of these features exist for other OS distros, but it's nice that there's GUI access to them in Tiger Server.
I just installed SSHBlack.pl the other day on my server to deal with this. It is at http://www.pettingers.org/code/sshblack.html . What it does is monitor /var/log/secure or whatever file has the failed attempts. If it sees 5 failed attempts in a recent time from an IP, it by default adds a new iptables rule fo X amount of days. It also has some protection to prevent a DOS issue from two many IPs being added.
For me, since I run shorewall, I changed one line to run shorewall drop instead of adding its own iptables rules.
In 2 days I now have 3 IPs blocked.
True yes, but that doesn't mean that other services cannot be exploited in such a manner. I recall walking into a server room where the admin pwd was indeed blank. I was authorized to be there, but it didn't really make much difference, the door was NEVER locked (against company policy for those people). Yep, it was a public facility without even any physical security other than 2 renta cops and 4 cameras (main entrances, this being an educational facility) Oh wait... did I mention that this facility's network had access to the entire Novell and Windows network of the local city government?? Yeah I forgot to mention that part.
Imagine how easy it would've been to install some backdoor or rootkit, as the admin. It would've been THAT poor chap's fault. Simple steps that can prevent a system being rooted are rarely taken. I ended up nearly getting sacked for bringing it up, since "it was not my job to be looking in places where my job description didn't tell me to go". At least the place is a little less hackable now.
" What luck for rulers that men do not think" - Adolf Hitler
block drop in log on $EXT_IF proto { tcp, udp } \
from any os Linux to any port ssh
-> _Zero_ failed login atempts.
http://it.slashdot.org/~(H)elix1/journal/38378
I had installed DB2, and used db2admin/db2admin as the default account. Win32 box, but was undead by the time I got back from a roadtrip. Not only do you need to make sure your passwords are strong, but avoid the 'common' passwords folks will set up for a dev account. Looking at my firewall logs for the last year just confirms how fast you will go down if you use a simple/common account and password.
+++ UGUCAUCGUAUUUCU
This has got to be the best, most lucid, most interesting post on slashdot for at least 5 years.
Thanks, made my day.
In the interest of journalistic balance, it should be noted that I've posted plenty of asinine, ill-thought-out comments in the past five years.
But I recognized the Authority post as a keeper, the moment the idea came to me. So, thanks again for your affirmation.
-kgj
-kgj
We've been using pam_abl on our server for quite some time and it has been very successful.
One of our guys actually hacked it so it would use MySQL and iptables to automatically add certain types of offenders to the firewall.
I've got a
this goes to show why even your temporary accounts (if you need them) should have strong passwords.
Gyrate Dot Org - "Where high-tech meets low-life"
Running apache as root is the real mistake in that case.
A skript kiddie from there had been pounding me for months from 68.39.149..
I've gone back and forth with Comcast but the upshot is: Pound Sand.
As a result I banned his entire ip range. I had to, his password attacks were coming too fast & blocking out legit clients. This action took out 255 innocent customers of Comcast NJ - but's that's the risk of subscribing to a rogue ISP.
This is hardly news. Everyday there are ~100 such attempts from China and S. Korea (Which have ip range close to me). I just block the /6 ip range and white list someone if necessary.
Set up a honeypot and track which idiot is behind those bots are much more fun though.
I use APF and BFD on servers I manage. BFD will automatically block ip addresses that generate too many invalid login attempts.
I have been seeing attacks since the server went online, but they have increased recently.
BFD comes with a 10 minute cycle time. I recently changed it to 1 minute on one of my servers. It looks like the scripts expect it to be running on a 10 minute cycle, since a lot of the attacks start on 10 minute intervals.
I am blocking 3-10 new ip's per day.
On Windows, oh yes, you can. I've gotten into many computers on the university network with Adminstrator:[blank]. Haven't tried on Linux.
The real path to male liberation
http://daemonshield.sourceforge.net/
will temporarily block IPs that have more than a certain number of failed login attempts in a certain amount of time. It seems to block these attacks nicely.
Just set up SSH auth only with pubkey method. It is more convinient and much safer (but you need to protrect your keys). Also if your system uses PAM you can use pam_tally module to limit login (via PAM - so it covers anything from SSH thru console, X11 and finishing on FTP) attempts to f.e. 3 tries per hour - it will render bruteforce attacks basically useless.
Since attempts to shut these attacking bots down by reporting the source IPs seem to be ineffective, how about using an iptables ruleset that tracks the abusing IPs, and if they fall into that category, put the connection into a tarpit so the scripts stop scanning and guessing? I suppose this would just make the script kiddies use a timeout of some kind, but it seems more satisfying to at least attempt to tie up the resources of these scripted attack bots.
Fail2Ban will monitor any custom log file (mail, ssh, apache, etc) and will ban IPs with the help of iptables.
http://fail2ban.sourceforge.net/
I changed the port, but my university blocks all the non-standard ports, so I had to change it back or change it to 80 or something, and a friend of mine reported being unable to ssh into it on port 80, so I've left it on the standard port.
I run the script once a month now and only block a few more addresses each time. I've noticed that most (maybe 80%) of the IP's that I've blocked are from Romania or Italy. Right now I'm adding to the script to detect several IP's from the registered IP range blocks, and to block those entire ranges.
If anyone wants it, I'll be happy to provide it, but keep in mind that at the moment it doesn't work since I've taken it apart to make these and other improvements.
One of these attacks got a correct password, back in December. It installed some IRC software and a small SSH program, a script to run these programs under some aliases, and everything was in multiple locations including the users home directory, many directories under tmp, and a few others. Yes, its clearly part of a bot network. The guy writing this article provided so little useful information. I knew more than he did.These aren't the sigs you're looking for.
1. nmap -sV an attacker and see the box has a rootkit installed,default port,default pass.
2. Login,browse,setup a sniffer
3. Gain access to 13 other hosts
4. Repeat
5. Profit?
Recent ssh attacks?
Bull! This shit's been happening for over a year. I resorted to using tcp-wrappers & restricting IP addresses only to allow access from work to my home systems. I tried to "whois" the accounts & post email to the abuse email accounts, but most of this shit is happening from countries that don't give a damn what their people do on the internet. I'd like to see all access to those countries dropped from the internet, and that will solve the problem.
I see these frequently on my Mac, and while I'm positive they'll never get in due to AllowUsers, it's incredibly irritating when my CPU starts heating up crunching encryption for long periods of time. That's usually how I realize what's going on, then I notice my CPU bar going steadily about 20% or so above usual usage, and my network bar with constant minimum traffic. Really, really irritating, and I honestly haven't got a good excuse for not switching to a non-standard port... In fact, I'll just do that right now. What would be awesome though is a counter-attack honey pot shell on my Mac. Then I could just let them have access and watch them go down.
Yes, I know security through obscurity is generally bad, but I have two boxes, one that runs sshd on a different port (so they don't conflict). I just looked at my logs again.. the one on 22 is still going (I did notice these attacks before and kinda freaked.. before it started getting reported in the news). But there have been no attacks to the box on the other port.I just closed port 22 on my firewall, so now you would have to go through the other box...
What do you think? Stupid annoying attacks can have stupid annoying solutions? Or no? (That is, if you do all the other stuff.. no root logins... strong passwords.. etc...)
It cuts the risk of someone guessing a password, but doesn't eliminate the chance of an exploit in ssh or elsewhere. As you say, have as many layers of security as possible. (I've never seen a compromise on my ssh servers either, touch wood.)
you had me at #!
I ran into this problem some time ago. I had a client account that was logged into with this brute force attack. Luckily the client was in the shell at the time and terminated the login, then notified me about the problem. I went to the drawing board immediately. This is the solution I use across my small network farm of Linux servers.
/etc/hosts.deny ) /var/log/messages /var/log/secure /var/log/xfer.log /var/log/maillog
/etc/hosts.deny and add them to the firewall through IPTABLES.
/etc/hosts.deny is performed. If an IP is already in /etc/hosts.deny, then do not block it. I will manually go into /etc/hosts.deny and #comment out any valid user IP to prevent them from triggering what I call 'the mitigator'.
Read the common server log files with a PHP script and wrapped through the PAM authentication module ( a quick call for the script through
using regular expression, determine any failed password attempts. This gets tricky when dealing with RedHat boxes, as the logger will compress numerous "like" messages in something similiar to: "Last message repeated x number of times". Keeping this in mind, check for failed logins for _any_ account by the same IP X number of times.
What I found was the brute force scripts used numerous names: admin, root, webmaster, user, temp, etc.. ; therefore you are unable to use the detection system on a per-user basis, instead it must be per-IP basis.
If the IP attempts X number of failed logins, ban them in
Problems that arose due to this:
Some clients are just all thumbs on the keyboards. To augment this, a modification to the script to first read
This system has worked to prevent ssh brute force and rumple style dictionary bombing against sendmail.
The only problem I have run into with the script was when I ported it to a new server and forgot to add that servers IP to a 'safe_list'. Oops. A quick firewall flush though fixed the issue and the mitigator was back in business.
My Thoughts, Kyndig
If you increase the time between successive login attempts, you basically eliminate the threat of brute force on SSH. If someone is only allowed to try logging in once every 3 seconds, it's pretty unlikely that they'll get the correct password anytime soon.
The bits on the bus go on and off... on and off... on and off...
Is there a way to auto-route to 0.0.0.0 for these people with cisco routers?
(using a cisco routers with lots of rules as the "firewall" opened up just the ports that are necessary inbount AND outbound)
For anyone experiencing SSH attacks, I suggest you have a look at fail2ban http://fail2ban.sourceforge.net/. I got fed up with random script kiddies trying to bruteforce my DSL connected box. Now all repeated SSH authentication failures are iptable'd to a tarpit:)
This may of course not be suitable for everyone, as it creates potential denial of service conditions. Caveat Emptor.
I work as a systems administrator. Thats the first thing I suggest when someone actually starts paying attention to the logs. I invariably get a similar cross-eyed look.
Maybe they find it more exciting to talk about then to address.
Quack, quack.
I can keep a password in my head. I can't do that with a key.
Yeah, 'cause you should definitely limit your options as much as possible. How about doing BOTH? Frankly, my expectations of what "the authorities" will do is pretty low, but then my expectations of this "peer-to-peer government" you speak of is also pretty low, especially at present (since it doesn't exist yet).
It's easy to have high expectations of organizations that haven't been formed. Frankly, I suspect that this peer-to-peer organization you have in mind will have all sorts of unexpected problems in practice. I mean, democracy looks good on paper too. But I'm willing to wait and see. In the mean time, I'm going to try to take advantage of the infrastructure that does exist. I may be a cynic, but I'm a practical one.
I was a little worried and decided to look around the web to see what I could do. I heard a couple of mentions of disabling password authentication and going for something like RSA public key authentication instead. This means the client provides a public key that the server already allows through and the client proves it's the owner of the public key by signing something with it's private key. This is more secure, but it's not possible to connect from an unknown client easily.
Another interesting way of increasing security is to implement a port-knocking strategy.. I'm not sure myself how much effort this would take, but again, it does perhaps make connecting from secure clients more difficult.
After looking into that, my solution was to simply change my passwords to non-dictionary words. But with the ever increasing CPU power and distributed networks out there, how long before memorable passwords fail altogether?
Nice idea, but anarchy is an inherently unstable system.
I'm not calling for anarchy, it's a bad way to live.
Think of how the Greek city-states learned to develop constitutions, entered into by a relatively large proportion of citizens (exclusive of slaves and women, of course), and debated in the agora. Some constitutions suited their cities; some were less successful; but in any case, men learned to collectively develop laws by which they reasoned they could live. We're speaking here of the sixth, fifth, fourth centuries B.C.
Fast-forward to our time. We have the technological means to develop new institutions, in the manner of city-state constitutions but suitable for our modern global survival. This is what I mean by peer-to-peer government: open source code, collectively developed and debated, of benefit to all and malice to as few as possible.
-kgj
-kgj
The automated script runs through the default logins such as "root", "toor", "daemon" -- which on FreeBSD would not be able to login remotely even if attackers could guess the password.
I've configured syslog.conf to feed ssh's notifications of such attacks to a simple script, that routes the attacker's IP into blackhole...
In Soviet Washington the swamp drains you.
Checked the originating address - FSCKing students from India!
I think in yet another direction.
I limit accounts on the externally accessible system to those who need access from outside the network, require key-based authentication, and strungly encourage users to passphrase-protect their keys.
And I get over 300 authentication failures a day *without* allowing password attempts.
BTW, I know of someone who had allowed an account with a weak password to be accessible via SSH over the internet and was compromised by this sort of attack. Once they break in, they usually install a root kit and set up scripts to scan for other systems. It is sort of a classic zombie attack. One wonders if this process is sufficiently automate to be considered a worm...
LedgerSMB: Open source Accounting/ERP
my expectations of this "peer-to-peer government" you speak of is also pretty low, especially at present (since it doesn't exist yet). It's easy to have high expectations of organizations that haven't been formed. Frankly, I suspect that this peer-to-peer organization you have in mind will have all sorts of unexpected problems in practice. I mean, democracy looks good on paper too. But I'm willing to wait and see.
... it may be emergent, I don't know. Nor am I very confidant of how things might turn out -- really, I'm like you -- I'm willing to wait and see.
... see my post regarding Hellenic city-state constitutions and the development of modern open-souce government.
Quite right, my so-called peer-to-peer hasn't emerged
Interesting that you mention how democracy looks good on paper
In the mean time, I'm going to try to take advantage of the infrastructure that does exist. I may be a cynic, but I'm a practical one.
Agreed, I'm with you. I omitted this line of thought from my original post, to more sharply define my manifesto. But of course we must be practical: vision alone does not pay the bills.
-kgj
-kgj
"We can eliminate a huge portion of the search space by only searching passwords of length x"
Nope! This is the beauty of iterative deepening. The number of possible (7-bit) passwords of length x is 128**x. The total number of possible passwords of length less than x is also 128**x. So, if you just search passwords in order of increasing length, it will cost you at most twice as much to search all passwords of length less than or equal to x as to just search passwords of length equal to x.
The vulnerability is just that you can watch ssh connections going by on the network and find accounts with short passwords.
I've been getting a few of these per day, so that's more like a thousand per day. So far none of them have guessed my root password, which is 12345.
There's no failure quite as dissatisfying as a complete and total solution to the wrong problem.
...for all the lazy slashdotters on some linux box.
iptables -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --update --seconds 180 --name SSH --rsource -j DROP
iptables -A INPUT -p tcp -m tcp --dport 22 --tcp-flags SYN,RST,ACK SYN -m recent --set --name SSH --rsource -j ACCEPT
Usually they're not that patient...
I get these all the time on every system that's internet accessible, including on my cable internet connection. It's pretty clearly lots of different people using similar scripts, since they always try the username "Patrick", for instance.
:)
As others have noted, changing the port makes them stop, and it's a good idea to use the AllowUsers directive in sshd_config to only allow access for people that absolutely need it. Don't allow root access from ssh directly, because if they do somehow get your ssh password, it's better that they don't get root at the same time at least. Lots of other people were arguing over the value of disallowing direct root logins, but for me it's as simple as separating the break-in from the privilege escalation.
You can defend against these attacks by installing and implementing "swatch" a perl based script that you can use to execute commands (eg iptables blocking). This can be done by tailing /var/log/messages or your relevant log file dynamically or by passing swatch over historic files. This has worked well since Nov/Dec 2004 when this was reported to AUSCERT. You might also like to look at "portsentry" which can watch for probes and block using iptables rules (takes out Windows machines infected with viruses for instance). Both systems have exclusion rules that allow internal traffic to transmit normally.
A few months back my Debian Woody system was compromised by this. I had major security issues: a weak password and an old unpatched kernel.
I got up in the morning and looked at my logcheck emails. It was odd: there were messages saying the ethernet card had entered promiscuous mode, and several kernel modules loaded. Further investigation revealed two connections to remote port ircd, but netstat wouldn't show the process ID(s) that owned this connections. The machine was in a mess: I couldn't run man, or gzip (needed by the apt-get process) and several other key commands as they immediately seg faulted. Rebooting resulted in the same issues: ethernet card in prom. mode, etc. Perhaps a packet sniffer was running on my networking looking for passwords to upload.
My problems started when I created an account for a friend and gave it a weak password without making him change it. The ssh dictionary attack broke in that way. Furthermore, I wasn't running a normal Debian kernel. Instead one that somebody else had created with MPPE support (it would be nice after all these years if one could have MS-CHAP support for PPP straight out of the box). I hadn't kept tabs on the kernel notices and ensured that this kernel was ok with them - it hadn't been updated for at least a year. Thus the script that broke in via SSH was able to exploit a local security hole and elevate privileges - game over.
I write all this as a reminder to people to take care. Debian is fairly secure if you use standard packages and keep them up to date. I'm generally quite carefull about what I install, which services run, what ports are exposed to the internet, keeping and eye on it, etc. Two careless mistakes and I had to rebuild the system and change all my passwords - thankfully nothing more. Be warned.
Some googling shows:
. c.php
http://www.frsirt.com/exploits/08202004.brutessh2
Still requires some additional effort, in getting a password database, and some additional functionality, but it seems to be easier than I thought.
I wonder where all those attacks are comming from. Somebody probably must be fairly sure he doesn't get prosecuted.
Is a passworf some kind of Klingon security measure? If so, then I bet it looks tough, but somehow always gets defeated first by the bad guys.
These are blind scans, the attackers are searching the entire routable IPv4 space (actually they may even be searching unroutable space although obviously that will just slow them down).
If at any time 10% of Internet addresses actually lead to a machine that's switched on, and 5% of those machines are running a Unix of some kind (these numbers are probably a little wrong, but not by an order of magnitude) then typically 1-in-200 addresses scanned will answer a SSH connection, at that point the attacker tries a few dozen (or hundred in some cases it seems) user+password combinations and then moves on to someone else. They're probably scanning hundreds of thousands of machines every day in this way.
BUT.. let's try that again with IPv6 addresses. Under the present scheme for unicast address assignments blind jumps into the routable address space probably only have a 1-in-a million billion chance of hitting any machine at all choosing at random -- they'd need to scan a million billion times as long to get the same results, or to put it another way, you'd get scanned a million billion times less often.
I don't know about other readers, but despite daily encounters I haven't been scanned even _one_ million billion times yet, so making this problem a million billion times smaller seems like it would effectively go away completely.
So far experience bears this out, of course IPv6 isn't that widespread yet, so it could be that somehow no bad people are using it, but I suspect the vast address space simply makes scans prohibitively expensive. The daily logs I read show a fair few attempts with IPv4, but no unexpected connections using IPv6.
Since I can't take the risk of one of my users choosing a weak password, I've simply locked sshd down. Easy to do, and keeps things sane.
One of my friends had his box broken into because a user on his machine had a weak default password. The maliscious person got in, replaced sshd, and started capturing all failed login attempts. Since most of us had authorized_keys set up, when we tried to log in and were prompted for a password, we got suspiscious. Other users would try their password several times and give up. Those passwords were being sent back off to some site in Russia or Slovenia or something.
The other interesting prong of this attack was that the users who failed to log in and "handed" their password to the attackers, had their ~/.ssh/known_hosts scanned for external hosts they've connected to, and the username + password they just used was attempted on those other hosts, propagating the attack further.
The following short script firewalls off port 22 for unknown hosts. Simply add the IPs of your users or netblocks you connect from, and you're done.
--------- /etc/blacklistb le="YES"h --config-file=/root/.swatchrc --tail-file=/var/log/auth.log --awk-field-syntax --daemon --pid-file=/var/run/swatch.pid"o ot"-
#!/bin/sh
pfctl -t blacklist -T add $1
echo $1 >>
logger swatch: $1 caught with bad login. Added to blacklist pf table
---------
---------
rc.conf:
swatch_ena
swatch_rules="1"
swatch_1_flags="swatc
swatch_1_user="r
swatch_1_pid="/var/run/swatch.pid"
--------
pf.conf:
---------
table <blacklist> persist file "/etc/blacklist"
block in quick log on $WANIF from <blacklist> to any
There are esentially three ways to fix this problem.
h tml called pam_abl
The first is to patch sshd which is probably the least preferable way as you would need to continually keep patching with each upgrade. But this seems effective allowing you to exec a system command such as iptables.
http://ethernet.org/~brian/src/timelox/
The second is to use iptables to limit connection attempts from an IP address. One problem with this is people who use scp alot may quickly rack up that connection limit.
Here is a recent example from the iptables mailing list
iptables -A INPUT -p tcp --dport 22 -s ! $My_Home_Firewall_IP -m state --state NEW -m recent --name SSH --set --rsource -j SSH_BF
iptables -A SSH_BF -m recent ! --rcheck --seconds 60 --hitcount 3 --name SSH --rsource -j RETURN
iptables -A SSH_BF -j LOG --log-prefix "SSH Brute Force Attempt: "
iptables -A SSH_BF -p tcp -j DROP
The best in my opinion is a pam module found at http://www.kernel.org/pub/linux/libs/pam/modules.
This does not have the problem of the IPTables method that may mistake multiple fast scps etc as an attack attempt, and will not require coninutal repatching of the kernel such as the timelox patches.
Lastly you probably want to lock down ssh somewhat using the below config lines, primarily changing the PermitRootLogin to either no or without-password.
Protocol 2
PermitRootLogin without-password
# disable skeys
PasswordAuthentication no
ChallengeResponseAuthentication no
ClientAliveInterval 60
ClientAliveCountMax 30
meridian at tha.net
Another approach is shown in the Deception Tool Kit. DTK is a collection of scripts which connect to unused ports and appear to be various servers. When many servers use it, a forest is created which helps hide individual trees.
The article describes one attack method known as dictonary attacks on SSH ports of *nix systems. This attack method is known by ALL system administrators -- since years. It is even known to newbies that happen to read the manual.
So, nothing new here. And it is definitely not an article that goes "into depth on how to monitor these attackes and to report them to the authorities" and it also does not discuss various tools, but simply name some.
So, just a superfluous posting...
A Windows XP computer, joined to a Windows 2003 domain with password auditing enabled will not allow you to share its terminal services ports 3389 or 3391 without having a password.
When you try to share it out, it "should" request that you set a pwd. Of course, knowing Windows, nothing Microsoft ever does is either stable, or of any relevant quality.
In the end, they and their greedy colleagues in the IT industry and business community just bully everyone else into accepting their way and selling their shit to the rest of the world.
" What luck for rulers that men do not think" - Adolf Hitler
Currently, we have a complex set of heuristics that get used to help stop spam, yet our decisions to help stop random attacks coming in from the network are almost entirely non-heuristic.
I could see software that decides that an IP that has hit me twenty times with an incorrect password over the past week without ever successfully logging in correctly is not a legitimate user.
We shouldn't ever rely on heuristics alone for security, but I could see them being a useful addition.
Any program relying on (nontrivial) preemptive multithreading will be buggy.
You are so wrong. You can definitely remote login to the Administrator account, even if it has a blank password.
I manage a few hundred linux installations and in order to give avoid such issues and make management easier, I have created a shell wrapper.
The shell wrapper works exactly like the ones found on any router, it allows you to change the service configuration, and do diagnosis like ping and traceroute. If you need "shell" access, you just login as another user.
Here I have had cases where a few of these have got broken in because of weak root password, but no damage is possible because access the commands available are only a few ones, and none of them give access to the filesystem or allow launching generic processes. So probably the script sends commands to "infect", the shell simply replies with a "command not found".
Oh, you mean like this from yesterday on my little Linux box?
sshd:
Authentication Failures:
root (38.117.242.11): 3370 Time(s)
unknown (38.117.242.11): 369 Time(s)
unknown (110076.ntpu.edu.tw): 3 Time(s)
games (38.117.242.11): 2 Time(s)
news (38.117.242.11): 2 Time(s)
nobody (38.117.242.11): 2 Time(s)
ntp (38.117.242.11): 2 Time(s)
operator (38.117.242.11): 2 Time(s)
postfix (38.117.242.11): 2 Time(s)
sync (38.117.242.11): 2 Time(s)
unknown (mail.tskt.co.th): 2 Time(s)
uucp (38.117.242.11): 2 Time(s)
adm (38.117.242.11): 1 Time(s)
apache (38.117.242.11): 1 Time(s)
bin (38.117.242.11): 1 Time(s)
daemon (38.117.242.11): 1 Time(s)
dbus (38.117.242.11): 1 Time(s)
ftp (38.117.242.11): 1 Time(s)
gdm (38.117.242.11): 1 Time(s)
gopher (38.117.242.11): 1 Time(s)
halt (38.117.242.11): 1 Time(s)
lp (38.117.242.11): 1 Time(s)
mail (38.117.242.11): 1 Time(s)
mailnull (38.117.242.11): 1 Time(s)
named (38.117.242.11): 1 Time(s)
nfsnobody (38.117.242.11): 1 Time(s)
nscd (38.117.242.11): 1 Time(s)
pcap (38.117.242.11): 1 Time(s)
root (110076.ntpu.edu.tw): 1 Time(s)
root (mail.tskt.co.th): 1 Time(s)
rpc (38.117.242.11): 1 Time(s)
rpcuser (38.117.242.11): 1 Time(s)
rpm (38.117.242.11): 1 Time(s)
shutdown (38.117.242.11): 1 Time(s)
smmsp (38.117.242.11): 1 Time(s)
squid (38.117.242.11): 1 Time(s)
sshd (38.117.242.11): 1 Time(s)
vcsa (38.117.242.11): 1 Time(s)
webalizer (38.117.242.11): 1 Time(s)
xfs (38.117.242.11): 1 Time(s)
A little out of control, if you ask me.
A clever person solves a problem, A wise person avoids it. -Einstein
Many people suggest having no ssh daemon listening on port 22. I
suggest having an ssh daemon on port 22, and also on at least four
other ports. My goal is to reach my home machine from anywhere, even
from an arbitrary wireless network where I have no control over the
policy for outbound TCP. The outbound TCP policy might allow only one
port. I run ssh daemons for all of the common one-allowed-port cases:
port 22 - certainly there are networks that allow outbound SYN packets
only on port 22. Often occurs when the net admin uses ssh himself.
port 80 - very common, especially on networks where the admin forgot
to also allow 443. Or the admin blocked 443 to stop online shopping.
port 443 - if this is the only allowed outbound port, it usually means
that clients are supposed to use a proxy server for port 80.
port 53 - the admin read that blocking DNS was bad, and figured it'd
be simplest to allow port 53 UDP and TCP from all machines.
port 88 - usually means the network was designed to allow Kerberos
traffic outbound. See http://support.microsoft.com/kb/811832
Another handy step is to hack your laptop and your home machine to
support ssh on TCP port 0. This works around a 1-65535 firewall rule.
I'm sure that there are plenty of people, like myself, who have deployed other IDS tools, but don't have time to re-write it :)
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
One technique that has worked very well for me is to close the ssh port to all IPs except those on a whitelist. I can't use a static whitelist since I need to allow logins from anywhere. So I add IPs to the whitelist using a web page that users must access first. The URL is kept secret, and there aren't any links to it, so the URL itself is a kind of password; and of course I could easily protect the web page with a password too.
There is a CGI script connected to the web page that adds the IP of the requester to the whitelist. (This almost always works automatically for me, since the CGI script gets the IP address of the browser that requested it; this will be the correct IP to add to the whitelist unless the web request goes through a proxy.) IPs are removed automatically from the whitelist by a cron job.
This is essentialy a variant of port-knocking, except that you don't have to try to tell unsophisticated users to go to some complicated sequence of ports; they just have to go to a web page, which is something that's pretty easy to understand. You can also use it to protect any port where you're worried about password security (e.g., an IMAP port, etc.).
I get many probes on my ssh port every day, but I get no failed ssh logins. So for the moment this technique seems to have substantially reduced the danger of a breakin through the ssh port from some random machine.
This goes in /etc/hosts.allow
/etc/hosts.deny
sshd,sshdfwd-X11: 192.168.0.1
This goes in
sshd,sshdfwd-X11: ALL
Replace the IP with yours. If you don't have a static IP then put in your netblock. I didn't really have break-in but got sick of seeing hundreds of failed attempts in my system log. After I'd put those lines in I don't seem to get any more attacks.
C.E.
yet another attack due to poor security in Windows. If only everyone used Linux, we'd stop these attacks dead in their tracks...
wait a minute...
Nevermind.
If my call is important, why am I talking to a recording?
I filter by MAC for my internal network and by a single IP so I can get to it from work if I need to. It's not a perfect solution, but the script kiddies are shit out of luck.
So instead of having to worry about your computer being compromised, you now have to worry about ANY of your users' computers being compromised, over which you have no control at all. Epecially if you have sudo users.
For this reason I prefer using OTP keys (S/Key for example). They use a program that generates a different (very long) password every time. A bit like the RSA SecurID token thing does. It's much more work and it's very obvious (you get a challenge asked before connecting) but it is even secure against keylogging on your users' computers, if they are using a key calculator on a different device (I have them on my Palm and Java-enabled mobile phone).
OK, if I were to write a daemon for my zombie Linux cluster that originates SSH root login attempts to machines distributed world wide, I would have no idea that any of my zombies might be passively monitored by any of the systems where my zombies have tried to slip their digits into the root user hotpants.
What the author meant to say is that the attacker would have no idea that this particular host was engaged in passive monitoring. Whoopee dig doo. The puppet master of a zombie cluster has no awareness of any host it zombines are bombarding until some wall is breached.
Let's make this even more colourful. The internet is a like a giant, super crowded night club where the vast majority of the patrons are so drunk or drugged up they fail to even notice random hands prying into their pants. Yes, the internet is pretty darn strange in some ways. And what a clever mode of attack we must confront.
Spare me. Save your breath on this point for a future article about administrating a honey pot.
I'm sure that there are plenty of poeple, like myself, were able to find it in less than ten seconds.
to /etc/sshd/sshd_config so that only users connected to the dialout group can connect from remote addresses.
That way I have total control of which ids can use SSH.
Sigs. We don't need no steenking sigs.
On my server, one can login either using OTP or public key.
It's working nicely for me, as it allows me to conveniently log in from my own computer using public key, and when I login from other computers, I just fire up an OTP client on my phone and log in.