I run SSH on a publicly open server and see following attempts in /var/log/auth.log which I was told by some one could be port scanning attempts.(Not sure though)
How can I block above such attempts?

One method would be block the ssh port i.e 20 for all using iptables (if using iptables for firewall) and allow ssh to only trusted clients or users.

0 members found this post helpful.

No that is not possible.The legitimate users come from internet and various ISP's and I want to know how can port scan attempts be blocked not blocking the port itself.

If you dont want to block ssh port then configure psad to automatically block the source of such scans
upon detection.

Follow this link:

http://www.linuxsecurity.com/content/view/134248/171/

This thread is solved with this link I got some thing useful for my question I am sharing here might help some one.
http://www.ossramblings.com/using_ip...vent_portscans

iptables recent module
http://www.debian-administration.org/articles/187

0 members found this post helpful.

You did not understood my answer.I do know what rate limiting IPTABLE is.I mentioned the link to stop port scan attempt not to rate LIMIT iptables.The logs I posted above are from a server where Rate limited IPTABLEs are working.Rate limiting connections to a port via IPTABLES ensures that incoming connection to the port or service restricted via IPTABLES more than specified threshold is blocked for a specified time.
An example would be
Where ssh attempt more than 4 time i.e. 5th time would be blocked for next 60 seconds.
But that does not deal when some one does not wants to login but just want to scan the service running on the port.Hence I gave the second link.
The link I just mentioned above your post means this thread is solved.
I welcome if you have any thing else to add to block port scan attempt not to RATE Limit IPTABLES,

IMHO, this is overkill for simply getting rid of some relatively harmless (and even potentially useful) log entries.

In any case, just wanted to chime in and say that if you do go down this path then you should make sure you have TCP SYN cookies enabled (while understanding the implications), and that your rules match SYN packets specifically (not just packets in state NEW). Otherwise, you'd have created a brand new denial-of-service vulnerability on your server.

Having said that, aren't those iptables rules kinda ridiculous in this specific case? I mean, does your current firewall log show evidence that the DROP rule would have been triggered for any of the offending IPs? Nothing you've posted so far would indicate that.

I do not understand this part of your message.Please elaborate it so that many others who might read it may find this thread useful.I am not clear with
1) TCP SYN cookies (this part I can Google and read since you mentioned so I asked you can choose to ommit)
2) but how it creates a brand new dos vulnerability
Also I came across one more tool
http://sourceforge.net/projects/sentrytools/

Wikipedia has a good article. It's an anti-SYN flood technique, but since what it achieves is anti-spoofing it's also useful in non-flood cases such as this one. On GNU/Linux, you enable them like:Because, without TCP SYN cookies (and with the iptables rules from the blog you linked), you're making it possible for the bad guys to lock out your legitimate users by simply sending spoofed packets to your server (with your clients' source IPs on them).

I would be hesitant to recommend such an old, unmaintained software tool to anyone. If you want a port scan detector, my advice is to go with something like psad instead. Granted, it gets fed from an iptables log file, so although it's great for detecting scans in general, it's probably not a solution to your current dilemma (unconfirmed scans against one particular publicly-available service).

Also note that you can use fail2ban for this sort of thing, which would eliminate the need for any of this iptables absurdity. As always, though, verify that you don't create new problems (such as the previously mentioned DoS vulnerability).

1 members found this post helpful.

tkmsr, I writtee scripts which read logs i.e. auth.log and count frecuently occurs unique IP adress. Scripts has rule which talks him when and what iptables rule add. Unfortunately is not documentations in english but polish: http://debian.linux.pl/entries/30-Im...Pythonie-cz.-1 (3 part)
His work like fail2ban

I came across 2 more links
http://www.configserver.com/cp/csf.html
http://www.rfxn.com/projects/

I know this is a dead thread, but it's still drawing a lot of Google traffic so I wanted to add these comments:

I understand why you might think that, but consider that we're talking about stopping the low-hanging fruit, not targeted attacks. The idea here is to tragically slow down portscan attempts so that the average script-kiddie moves on to greener pastures.

Really though, if you're going to be targeted (i.e. APT as it's been dubbed) you have a whole slew of other problems. You're talking about not taking steps to protect yourself against the 99.99% of attackers that hit you, because it might cause you an immediately noticeable DOS problem (and raise the alarm bells) if you are attacked by that .01%. Sure, there's tradeoffs with every security decision. Personally I believe that taking a few easy steps to protect against information gathering by ALL attackers (i.e. portscans) is going to give me a better return on investment than not taking those steps because an attacker might be smart enough to then cause a DOS attack by spoofing packets- which most modern ISP's actively block these days. I know both my home and work ISP's prevent spoofed packets now.