I doubt that’s the problem, but I don’t see it, so though it worth checking.
It doesn’t look like you have an open relay there…and I’m not sure the logs you’re seeing indicate relaying (there should be more after those messages, I think).
OK I figured out how to grep and yes there were more instances of that ID and it looks like it was just spam being send from a single outside source TO to of my mail accounts at the same time so all is ok
The other lines were about 200 lines down in the log because some clown was doing a dictionary attack and I had gazillion Aborted lines in the file.
in other words you can’t prevent the attack afaik
you can secure the system better by creating non-dictionary passwords with min. length of 15 characters like hnJyg$42#eds@kjJ
many users use passwords like: “thisismypasswordandnoonewilleverguess” and that’s what dic-attacks are looking for.
Minimum length of 8 characters is fine, as long as the password is strong–numbers, upper/lower letters, and/or symbols. No dictionary words. A strong 8 character password could take years for a brute force attack to find…the attacker will move on to greener pastures after a couple of days.
There have also been discussions here in the forums about other techniques. Lief brought up some nice iptables rules for tackling the problem a couple of years back, and lots of people have had good success using them for all sorts of services (the discussion was about ssh, but they can be applied to almost any service because iptables is awesome like that).
I have been using IPTables to stop unwanted entry by tying some services to my home office IP only and that stopped brute force on the attempted ports dead. Since I am the only user on the box and don’t have hosting customers I can do things like that
I know about Leifs cool reject rules and the last time I tried to implement them I was on a Virtuozzo VPS running CentOS 4.6 and the needed kernel module could not be added to allow me to run those rules in the VE space.
I am now on an OpenVZ VE running CentOS 5.1 and will try them again as I would rather use that method to stop entry so I don’t have to worry about being able to access if I am at a different location.
have you heard of the super computer NASA has?
According to an article this baby can crack passwords in a few seconds while the strongest home PC would take more than 100 years.
I’m just saying…no one is safe if the FBI gets their hands on that toy, haha
If the US government is after you, you’re already in serious trouble.
According to an article this baby can crack passwords in a few seconds while the strongest home PC would take more than 100 years.
They’d have to have access to your shadow file to be able to attack any faster than us mere mortals. They still have the limits imposed by the network and the services that they are using as an attack vector. e.g. they can only send so many requests to ssh before they run out of bandwidth into your server or the ssh daemon can’t keep up any more.
The government (NSA, not NASA, by the way!) certainly have serious tools for invading your privacy, but they aren’t usually who we all have to worry about. Most of our security foes are merely looking for more servers to use for sending spam…and they aren’t all that smart, generally. They mostly use off-the-shelf tools, and just look for the low-hanging fruit (Windows boxes, mostly).
DenyHosts is a script intended to be run by Linux system administrators to help thwart SSH server attacks (also known as dictionary based attacks and brute force attacks).
If you’ve ever looked at your ssh log (/var/log/secure on Redhat, /var/log/auth.log on Mandrake, etc…) you may be alarmed to see how many hackers attempted to gain access to your server. Hopefully, none of them were successful (but then again, how would you know?). Wouldn’t it be better to automatically prevent that attacker from continuing to gain entry into your system?
DenyHosts attempts to address the above… and more.
