Forgive me if this does not go with the right topic, I am on digest and responding to a topic sometimes makes it start a new one.
My reason for the iptables questions is to not follow the practice of putting up a wall and ignoring hackers. I want to be more proactive.
If I have set my ssh port to 55994 and am not using port 22, but hackers are pounding on my port 22 looking for Ssh, then I want to not only know about it, I want to log them and prevent them access to my server and web applications. At least temporarily.
I see now that many of the programs are log users and not real time. And many like fail2ban actually add chains to iptables that I Could do myself. It looks like getting some books on netfilter may be the way to go.
I would rather stop stuff at the firewall then trust apache, php, sendmail, vsftp, etc. I would rather use them as back up failsafes while I work on hack proofing the single point of entry.
I have a server sitting right on the net and the constant barrage of 100s of Ips trying thousands of times at port 22 is insane. I examine my logs and see so much in the way of dns posion attacks, ssh-mail-ftp, etc attacks that I do not want to just sit back and Think I am fine because I have a firewall and centos will send me bug fixes.
That firewall seems like the 100% way of going at stopping and preventing issues. If an IP is doing something it should not be doing, most likely you do not want it probing anything else either.
That's why I ask.
On Tue, Aug 10, 2010 at 07:12:59PM -0400, Bob Hoffman wrote:
I have a server sitting right on the net and the constant barrage of 100s of Ips trying thousands of times at port 22 is insane.
You're quite sane. Anyone likely to hit your ssh at its new port is likely to try port 22 first. So if they show up there first, blocking them is good - unless you have legitimate users who may forget to go to your special port and so get locked out after trying the default port first.
There are several packages that integrate port scanning detection with iptables rule generation. One such is here:
- Whit
From: Whit Blauvelt whit@transpect.com
On Tue, Aug 10, 2010 at 07:12:59PM -0400, Bob Hoffman wrote:
I have a server sitting right on the net and the constant barrage of 100s
of
Ips trying thousands of times at port 22 is insane.
You're quite sane. Anyone likely to hit your ssh at its new port is likely to try port 22 first. So if they show up there first, blocking them is good
- unless you have legitimate users who may forget to go to your special port
and so get locked out after trying the default port first.
There's also port knocking...
JD
2010/8/11 John Doe jdmls@yahoo.com:
From: Whit Blauvelt whit@transpect.com
On Tue, Aug 10, 2010 at 07:12:59PM -0400, Bob Hoffman wrote:
I have a server sitting right on the net and the constant barrage of 100s
of
Ips trying thousands of times at port 22 is insane.
You're quite sane. Anyone likely to hit your ssh at its new port is likely to try port 22 first. So if they show up there first, blocking them is good
- unless you have legitimate users who may forget to go to your special port
and so get locked out after trying the default port first.
There's also port knocking...
how about enabling ssh login only with public keys ?
-- Eero, RHCE
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
thus Eero Volotinen spake:
I have a server sitting right on the net and the constant barrage of 100s
of
Ips trying thousands of times at port 22 is insane.
You're quite sane. Anyone likely to hit your ssh at its new port is likely to try port 22 first. So if they show up there first, blocking them is good
- unless you have legitimate users who may forget to go to your special port
and so get locked out after trying the default port first.
There's also port knocking...
how about enabling ssh login only with public keys ?
What about using a different port, if narrowing down the networks/hosts *allowed* to connect to the machine is not an option, as it seems?
Timo
-- Eero, RHCE
From the iptables manual:
recent Allows you to dynamically create a list of IP addresses and then match against that list in a few different ways. For example, you can create a "badguy" list out of people attempting to connect to port 139 on your firewall and then DROP all future packets from them without considering them.
[...]
Steve’s ipt_recent website (http://snowman.net/projects/ipt_recent/) also has some examples of usage.
I think that's what you were looking for ;)
On 11/08/10 00:12, Bob Hoffman wrote:
Forgive me if this does not go with the right topic, I am on digest and responding to a topic sometimes makes it start a new one.
My reason for the iptables questions is to not follow the practice of putting up a wall and ignoring hackers. I want to be more proactive.
If I have set my ssh port to 55994 and am not using port 22, but hackers are pounding on my port 22 looking for Ssh, then I want to not only know about it, I want to log them and prevent them access to my server and web applications. At least temporarily.
Do you have any evidence that those IPs banging away on port 22 are also attacking other ports? Don't get me wrong, I'm all for getting proactive with security but I'm not convinced site wide blocking of IPs probing port 22 will translate to other services.
After moving ssh to an alternative port, I typically see around 3 probes a day on port 22 in my firewall logs. How many are you seeing? If it's significantly more than that, why?
On 08/10/10 10:43 PM, Ned Slider wrote:
After moving ssh to an alternative port, I typically see around 3 probes a day on port 22 in my firewall logs. How many are you seeing? If it's significantly more than that, why?
some subnets seem to get hit alot more often by the drones. bad randomizers? lists of preferred scan targets based on prior vulnerable targets? probably a mix.
-
Bob Hoffman -
Eero Volotinen -
John Doe -
John R Pierce -
kalinix -
Ned Slider -
Timo Schoeler -
Whit Blauvelt