LinuxQuestions.org
Visit the LQ Articles and Editorials section
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices



Reply
 
Search this Thread
Old 11-19-2010, 12:53 AM   #1
tkmsr
Member
 
Registered: Oct 2006
Distribution: Ubuntu,Open Suse,Debian,Mac OS X
Posts: 798

Rep: Reputation: 39
how can I block port scanning attempts


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)
Code:
Nov 18 23:50:19 server sshd[21716]: Did not receive identification string from 186.0.80.197
Nov 19 00:05:57  server sshd[24056]: Did not receive identification string from 85.108.110.66
How can I block above such attempts?
 
Old 11-19-2010, 01:04 AM   #2
prayag_pjs
Senior Member
 
Registered: Feb 2008
Location: Pune - India
Distribution: Fedora,RedHat,CentOS,Gentoo
Posts: 1,138
Blog Entries: 4

Rep: Reputation: 147Reputation: 147
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.
Old 11-19-2010, 01:15 AM   #3
tkmsr
Member
 
Registered: Oct 2006
Distribution: Ubuntu,Open Suse,Debian,Mac OS X
Posts: 798

Original Poster
Rep: Reputation: 39
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.
 
Old 11-19-2010, 01:45 AM   #4
prayag_pjs
Senior Member
 
Registered: Feb 2008
Location: Pune - India
Distribution: Fedora,RedHat,CentOS,Gentoo
Posts: 1,138
Blog Entries: 4

Rep: Reputation: 147Reputation: 147
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/
 
Old 11-20-2010, 03:44 AM   #5
tkmsr
Member
 
Registered: Oct 2006
Distribution: Ubuntu,Open Suse,Debian,Mac OS X
Posts: 798

Original Poster
Rep: Reputation: 39
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

Last edited by tkmsr; 11-20-2010 at 06:03 AM.
 
Old 11-20-2010, 05:55 AM   #6
grzesiek
LQ Newbie
 
Registered: Nov 2010
Location: Poland
Distribution: Debian
Posts: 20

Rep: Reputation: 0
iptables recent module
http://www.debian-administration.org/articles/187
 
0 members found this post helpful.
Old 11-20-2010, 05:57 AM   #7
tkmsr
Member
 
Registered: Oct 2006
Distribution: Ubuntu,Open Suse,Debian,Mac OS X
Posts: 798

Original Poster
Rep: Reputation: 39
Quote:
Originally Posted by grzesiek View Post

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
Quote:
Chain INPUT (policy ACCEPT)
target prot opt source destination
DROP tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: UPDATE seconds: 60 hit_count: 5 name: DEFAULT side: source
tcp -- 0.0.0.0/0 0.0.0.0/0 tcp dpt:22 state NEW recent: SET name: DEFAULT side: source
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,

Last edited by tkmsr; 11-20-2010 at 06:03 AM.
 
Old 11-20-2010, 06:17 AM   #8
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by tkmsr View Post
Ok I got some thing useful for my question I am sharing here might help some one.
http://www.ossramblings.com/using_ip...vent_portscans
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.

Last edited by win32sux; 11-20-2010 at 06:23 AM.
 
Old 11-20-2010, 07:07 AM   #9
tkmsr
Member
 
Registered: Oct 2006
Distribution: Ubuntu,Open Suse,Debian,Mac OS X
Posts: 798

Original Poster
Rep: Reputation: 39
Quote:
Originally Posted by win32sux View Post
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.
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/

Last edited by tkmsr; 11-20-2010 at 07:13 AM.
 
Old 11-20-2010, 07:25 AM   #10
win32sux
Guru
 
Registered: Jul 2003
Location: Los Angeles
Distribution: Ubuntu
Posts: 9,870

Rep: Reputation: 371Reputation: 371Reputation: 371Reputation: 371
Quote:
Originally Posted by tkmsr View Post
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)
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:
Code:
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
Quote:
2) but how it creates a brand new dos vulnerability
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).

Quote:
Also I came across one more tool
http://sourceforge.net/projects/sentrytools/
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).

Last edited by win32sux; 11-20-2010 at 07:56 AM.
 
1 members found this post helpful.
Old 11-21-2010, 07:14 AM   #11
grzesiek
LQ Newbie
 
Registered: Nov 2010
Location: Poland
Distribution: Debian
Posts: 20

Rep: Reputation: 0
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
 
Old 11-21-2010, 10:52 AM   #12
tkmsr
Member
 
Registered: Oct 2006
Distribution: Ubuntu,Open Suse,Debian,Mac OS X
Posts: 798

Original Poster
Rep: Reputation: 39
I came across 2 more links
http://www.configserver.com/cp/csf.html
http://www.rfxn.com/projects/
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
SSH tricks -- any way to block failed attempts by IP address tensigh Linux - Security 10 06-06-2008 04:46 PM
Is there a way to get psad to block the port scanning IP with the APF firewall? abefroman Linux - Security 1 04-15-2008 11:57 AM
Port Scanning and ssh2 brute force attempts Fedora Core 4 hazmatt20 Linux - Security 12 02-05-2006 10:09 PM
repeated attempts at port 800 from inside floppywhopper Linux - Security 3 08-17-2005 03:01 AM
How do I block IP's to prevent unauthorized SSH login attempts? leofoxx Linux - Security 6 05-23-2005 10:36 PM


All times are GMT -5. The time now is 11:59 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration