Port Scan Detectors

We usually mean by port scanning the attempt to detect what services are active on a particular host. It is usually achieved by sending specially crafted packets to each port in sequence or randomly. In any case the key heuristic is packet directed to various port on a particular host or (if you want to be paranoid) any packet directed to the inactive or blocked by firewall port.  In simple cases (ping type port scans) a uniform packets can used.

The key to success on port scan detection is "to know the enemy". For example if nmap is used, then IDS an be tuned for better detection of typical NMAP probes. Network IDS that is listening to the incoming to the segment traffic generally can detect any packet that is coming to a particular network and in this sense there is no such thing as "stealth scan" -- just bad signatures :-)

The most efficient method of port scan detection is honeypots usage as any traffic directed to honeypots y definition is a scan or intrusion attempt.

Most network intrusion detection systems (for example Snort) can detect port scan attacks (the more tuning is done, the better detection capability can be achieved).  Snort also has PortScan Plugin which is not that great but can do basic ping-style port scanning :

The Portscan plugin for snort allows you to monitor your snort log files and run a external program on the offending IP whenever a configurable rule is broken. By default this program has been designed to run with nmap.

For complex cases Shadow-style IDS sensors are better as processing of  traffic dumps can be made as complex as you need for successful detection

It is rather easy to discover port scans by aggregating the data TCPdumps ot, if scan triggers at least one signature, IDS logs.

Custom Perl script for detecting port scans can be written if this is a real problem.

Simplistic port scans are detected by just simple aggregation of information for a single host. Here is a relevant information from Port Scanning FAQ:

In the early days of scanning, tools scanned ports sequentially, and simply attempted a full connection with each port. These scans gave interesting results, but became so common that port scan detectors were quickly designed to set off alarms if the computer under attack noticed doors being accessed like this in a sequential manner.

Then came random port scans ... simple randomizing of the order of doors, and intervals between door knocks. This soon became easy to detect also.

Next stage in the arms race: by looking at the protocol involved in knocking on doors, it become possible to program a so-called 'stealth' scan. (TCP SYN Scan). This is more subtle than a straight knock. If your objective is to know whether the door would be answered, but you don't want it to be opened yet, it is possible to do a few different "half-knocks" that reveal whether the door is "alive" but do not alert possible higher level security or logging systems that the door was tried.

Next in port scan technology came the FIN Scan. This is like an inverse half knock(!). It happens that computer packet handlers (tcp stacks) have an interesting characteristic: FIN packets (a type of negotiation packet) addressed to "dead" doors cause a receipt of an RST packet, but alive doors do NOT. Therefore, a FIN scan can identify all the dead doors, and leave you with a list of potentially alive ones. Because the lowest level of the operating system is handling this, most port scan alarm systems have no awareness that this is happening.

If the FIN scan is not good enough, then there is the fragmentation scan. This breaks probe packets up, to possibly get through firewalls or avoid port alarms, and then be reassembled by the victim's computer to possibly reveal an open port.

Once a port scanner has assembled a list of potentially alive port numbers (doors), it has a good chance of identifying the operating system, the machine hardware, and which alive doors may have faulty "doormen" (software) behind them.

You can also try to detect scan on host level. Here a simple aggregation of logs produces "good enough" estimate of whose who does most "open" scans. They are obvious candidates for blacklist althouth is it usually better not to demonstrate them that they are blacklisted by redirecting them to some special (for example "honeypot") subnet. That might help to answer the real question: why they are doing  it.

There are generally two possibilities and two positions of security specialists about this question:

1. Those who scan us are evil people. Let's block them before that can do us any harm.
2. Those who scan are idiots. Let them enjoy this generally harmless for us activity.

Both point of view has some merits although in majority cases the version about idiots (usually with nmap in hands) is slightly more plausible.  Still they should not be completely ignored. You are well advised to know the 'current set of idiots" and set of ports that they are scanning and adjust firewall accordingly.

I think that "DNS scanning idiots" usually should be blacklisted. That can be done semi-automatically: reaching a certain threshold can initiate a check for partners subnets and if this is not a partner  installation of , say, TTL type of block (TTL less then say 5 are pretty strange for a legit traffic).  Not TTL types of blocks should not be applied automatically as such a mechanism can be used for denial of service attack.

Usually those who systematically and blindly scan large networks using primitive tools like nmap, etc, especially networks belonging to large corporation with well-fed lawyers are somewhat mentally unstable from my point of view. No amount of zombies can save the butt of those who really managed to attract attention of a large corporation with dedicated security staff and a budget for external consultants unless they are on a different continent. Although for multinationals stupid university students are also pretty much reachable. May be this statement is a little bit of stretch by it correlates with my experience in this area.

Spammers are a notable counter example. Those usually are completely reckless..

Another type of scans is "vulnerability scanning" of  the host. As each tool has its own fingerprint it is usually not that difficult to detect.

NEWS CONTENTS

• 20080822 : Port Scan Attack Detector 2.1.4 by Michael Rash ( Port Scan Attack Detector 2.1.4 , Aug 22, 2008 )
• 20080822 : Port Scanner ( Port Scanner, )
• 20080822 : Lestat ( Lestat, )
• 20080822 : pkdump ( pkdump, )
• 20080822 : Scan Detect ( Scan Detect, )
• 20080822 : Astaro Portscan Detection ( Astaro Portscan Detection, )
• 20080822 : Port Scan Attack Detector by Michael Rash Created : Sun, Apr 15th 2001, Updated: Sat, Sep 11th 2004 ( Port Scan Attack Detector, )
• 20080822 : Shadow Scan Home pages ( Shadow Scan Home pages, )
• 20080822 : Resentment.org - Scan Detector ( Resentment.org - Scan Detector, )
• 20080822 : scanlogd - a port scan detection tool ( scanlogd - a port scan detection tool, )

Old News ;-)

[Aug 22, 2008] Port Scan Attack Detector 2.1.4 by Michael Rash

About: The Port Scan Attack Detector (psad) is a collection of three system daemons that are designed to work with the Linux iptables firewalling code to detect port scans and other suspect traffic. It features a set of highly configurable danger thresholds (with sensible defaults), verbose alert messages, email alerting, DShield reporting, and automatic blocking of offending IP addresses. Psad incorporates many of the packet signatures included in Snort to detect various kinds of suspicious scans, and implements the same passive OS fingerprinting algorithm used by p0f.

Changes: This release restructures Perl module paths to make it easy to introduce a "nodeps" distribution of psad that does not contain any Perl modules. This allows better integration with systems that already have all necessary modules installed (including the IPTables::ChainMgr and IPTables::Parse modules). The main driver for this work is to make all cipherdyne.org projects easily integrated with distributions based on Debian. A bugfix has been made to honor the IPT_SYSLOG_FILE variable in --Analyze-msgs mode. A switch has been made from the deprecated bleeding-all.rules file to the new emerging-all.rules available from Emerging Threats.

Port Scanner

Port Scanner checks to see which ports are open on an IP address and reads any data sent when it connects. If possible, the service on the port will be named.

Lestat

Lestat is a simple system which is designed to allow trends in port scans to be identified and displayed in a simple manner. The system comprises a Perl agent which collects packets and logs them to a database, and a presentation layer which draws graphs and presents a GUI via PHP.

pkdump

pkdump detects TCP and UDP port scans and connection attempt from foreign hosts over the Internet.

Scan Detect

Scan Detect listens on a given TCP port. If a host connects to that port, it uses ipchains to block that host from connecting to your Linux system. To that host it would be like your system isn't connected to the Internet.

Astaro Portscan Detection

Astaro Portscan Detection is a netfilter target which will attempt to detect TCP and UDP port scans and log them to syslog. This target is based upon Solar Designer's scanlogd. It suppports mutliple levels of logging, custom prefixes for entries, weighted total port scan detection, and port scan temporal spread detection.

Port Scan Attack Detector by Michael Rash Created : Sun, Apr 15th 2001, Updated: Sat, Sep 11th 2004

Website: Cipherdyne -- Security Software

Port Scan Attack Detector (psad) is a collection of three lightweight system daemons written in Perl and C that are designed to work with Linux iptables firewalling code to detect port scans and other suspect traffic. It features a set of highly configurable danger thresholds (with sensible defaults provided), verbose alert messages that include the source, destination, scanned port range, begin and end times, TCP flags and corresponding nmap options, email alerting, DShield reporting, and automatic blocking of offending IP addresses via dynamic configuration of iptables firewall rulesets. In addition, psad incorporates many of the TCP, UDP, and ICMP signatures included in Snort to detect highly suspect scans for various backdoor programs (e.g. EvilFTP, GirlFriend, SubSeven), DDoS tools (mstream, shaft), and advanced port scans (syn, fin, Xmas) which are easily leveraged against a machine via nmap. Psad also uses packet TTL, IP id, TOS, and TCP window sizes to passively fingerprint the remote operating system from which scans originate

Shadow Scan Home pages

contain ShadowPortGuard. Detects connects to ports

Resentment.org - Scan Detector

"J-Dog's Scan Detector 1.1" is almost identical to version 1.0 except that in 1.1 I finally got around to building some 'reation' systems which gathers data on the host who is scanning you. This script uses 'nmap' 'queso' and 'nmbnamex'. What this script does upon connection to a port (you specify which port to listen on) it grabs the IP and tries to resolve it to a hostname and then performs a tcp connect() scan on it (yap, that's visible, so watchout =P ) and then tries to grab the NetBIOS name of the scanner and then uses queso to resolve the Ip to an OS.

This update as with the original script was written as a kind of 'gee I am bored.. lets write something' project and while it can be used to detect portscans, it is not meant as a SERIOUS portscan detection util.

I am not interested in making this script really any more user friendly or cleaning up my code, or debugging this tool any further since I do not consider this tool to be a serious portscan detection util, but rather a POC program that I wrote to satisfy some boredom.

Note: I was just thinking about something... If 2 boxes were running this script and box A connected to box B and box B's tcp scan range was withing the range of ports that box A's scanner was on.. and vice versa.. you could get a really nice DoS going.. ;) w00t

Feel Free to download the Source Code

"J-Dog's Scan Detector" is provide Free of Charge to whoever wants to user it. I provide no warranty or guarantee that it will work.

If you have any questions or comments, please send them to J-Dog

scanlogd - a port scan detection tool

scanlogd is a TCP port scan detection tool, originally designed to illustrate various attacks an IDS developer has to deal with, for a Phrack Magazine article (see below). Thus, unlike some of the other port scan detection tools out there, scanlogd is designed to be totally safe to use.

This release of scanlogd can be built with support for one of several packet capture interfaces. In addition to the raw socket interface on Linux, scanlogd is now aware of libnids and libpcap.

The use of libpcap alone is discouraged. If you're on a system other than Linux and/or want to monitor the traffic of an entire network at once, you should be using libnids in order to handle fragmented IP packets.

Please read the scanlogd(8) manual page and the original Phrack Magazine article.

Download:

• scanlogd 2.2.5 and its signature
• "Designing and Attacking Port Scan Detection Tools", the Phrack Magazine article

These files, as well as the third-party libraries listed below, are also available via FTP.

Follow this link for information on verifying the signatures.

Related third-party raw IP networking libraries:

• libpcap and a local copy of libpcap 0.8.3 (signature)
• libnet and a local copy of libnet 1.0.2a (required for libnids)
• libnids and a local copy of libnids 1.18 (signature)

Commercial support for scanlogd is available, please check our services. We may help you configure, compile and install both scanlogd itself and any or all of the third-party raw IP networking libraries.

scanlogd is a part of Owl, Debian GNU/Linux, Gentoo Linux, SuSE Linux, and distributions by ALT Linux team. There's an OpenBSD port of scanlogd in the OpenBSD ports collection and now also a FreeBSD port in the FreeBSD ports collection.

There's a Win32 port of scanlogd, by Michael Davis.

Support further work on this software with donations.

Looking for a good port scanner to test your installation of scanlogd? Use Nmap.

Recommended Links

Softpanorama Recommended

Top articles

Sites

Linux-Sec.net

NIC-based intrusion detection: A feasibility study
File Format: Microsoft Powerpoint 97 - View as HTML
... Conclusions. Basic Algorithms. Port Scan Detector (PSD). Anomaly Detector. ... NIC-based
Naïve Bayes Classifier. Port Scan Detector. Is memory constrained? No. ...
www-users.cs.umn.edu/~aleks/icdm02w/srinivasan.ppt - Similar pages

Port Scanning FAQ 1.0 General Info

Perl-based

psad by Michael Rash

Port Scan Attack Detector by Michael Rash. Created : Sun, Apr 15th 2001, Updated: Sat, Sep 11th 2004 12:09 PDT

Port Scan Attack Detector (psad) is a collection of three lightweight system daemons written in Perl and C that are designed to work with Linux iptables firewalling code to detect port scans and other suspect traffic. It features a set of highly configurable danger thresholds (with sensible defaults provided), verbose alert messages that include the source, destination, scanned port range, begin and end times, TCP flags and corresponding nmap options, email alerting, DShield reporting, and automatic blocking of offending IP addresses via dynamic configuration of iptables firewall rulesets. In addition, psad incorporates many of the TCP, UDP, and ICMP signatures included in Snort to detect highly suspect scans for various backdoor programs (e.g. EvilFTP, GirlFriend, SubSeven), DDoS tools (mstream, shaft), and advanced port scans (syn, fin, Xmas) which are easily leveraged against a machine via nmap. Psad also uses packet TTL, IP id, TOS, and TCP window sizes to passively fingerprint the remote operating system from which scans originate

Autobuse by Grant Taylor

http://www.picante.com/~gtaylor/autobuse/ by - January 11th 1999, 19:04 EST

Autobuse is Perl daemon which identifies probes and the like in logfiles and automatically reports them via email. This is, in a way, the opposite of logcheck in that autobuse identifies known badness and deals with it automatically, while logcheck identifies known goodness and leaves you with the rest. autobuse readme

Others

PortSentry

Detects and responds to port scans against a target host inreal-time.
Jun 26th 1998, 19:36
stable: 0.90 - devel: none

PortSentry is part of the Abacus Project suite of security tools. It is a program designed to detect and respond to port scans against a target host in real-time. It runs on TCP and UDP sockets and works on most UNIX systems. Advanced stealth detection modes are available under Linux only and detect SYN, FIN, NULL, XMAS, and Oddball packet scans. All modes support real-time blocking and reporting of violations.

FakeBO

FakeBO fakes trojan server responses (Back Orifice, NetBus, etc.) and logs every attempt to a logfile, stdout/stderr or syslog. It is able to send fake pings and replies back to the client which is trying to access your system.

Courtney

A program that tries identifies the use of SATAN on a subnet. The program tcpdump will also be needed in order to run Courtney. See below for information about tcpdump.
Additional Info: CIAC Notes 08

Klaxon

A daemon that is used to identify the use of port scanners like ISS and SATAN.

Scan-Detector

Determines when an automated scan of UDP/TCP ports is being done on a host running this program. Logs to either syslog or strerr. Additional Info: COAST Projects' Tools

sentry-0.61-1

A security tool designed to detect and stop port scanner programs in real-time.
Linux/i386 sentry-0.61-1 Stop port scanners like sniffit

ippl - IP Protocols Logger

ippl is a daemon which logs IP packets sent to a computer. It runs in the background, and displays information about the incoming packets. Criteria can be used to specify what packets should be logged and what packets should be ignored.

sockscan

Sockscan runs in the background of your Linux system looking for ICMP Floods, TCP/IP Port scans, Back Orifice pings, DoS attacks, and more. It can log to file, system log, or even connect to your mIRC client on a remote machine. Sockscan requires root priviledges to open the ethernet device in raw mode.

ftp://dustball.com/pub/sockscan/sockscan-1.0.tar.gz

Resentment.org - Scan Detector

"J-Dog's Scan Detector 1.1" is almost identical to version 1.0 except that in 1.1 I finally got around to building some 'reation' systems which gathers data on the host who is scanning you. This script uses 'nmap' 'queso' and 'nmbnamex'. What this script does upon connection to a port (you specify which port to listen on) it grabs the IP and tries to resolve it to a hostname and then performs a tcp connect() scan on it (yap, that's visible, so watchout =P ) and then tries to grab the NetBIOS name of the scanner and then uses queso to resolve the Ip to an OS.

This update as with the original script was written as a kind of 'gee I am bored.. lets write something' project and while it can be used to detect portscans, it is not meant as a SERIOUS portscan detection util.

I am not interested in making this script really any more user friendly or cleaning up my code, or debugging this tool any further since I do not consider this tool to be a serious portscan detection util, but rather a POC program that I wrote to satisfy some boredom.

Note: I was just thinking about something... If 2 boxes were running this script and box A connected to box B and box B's tcp scan range was withing the range of ports that box A's scanner was on.. and vice versa.. you could get a really nice DoS going.. ;) w00t

Feel Free to download the Source Code

"J-Dog's Scan Detector" is provide Free of Charge to whoever wants to user it. I provide no warranty or guarantee that it will work.

If you have any questions or comments, please send them to J-Dog

Related Tools

Argus

A powerful tool for monitoring IP networks. It provides tools for sophisticated analysis of network activity that can be used to verify the enfforcement of network security policies, network performance analysis, and more.

Arpwatch

An ethernet monitor program that keeps track of ethernet/IP address pairings.

Icmpinfo

Displays unusual ICMP messages received by a host. This can be used to detect suspicious network activity.
Additional Info: icmpinfo man page

Netlog

Network logging and monitoring of all TCP and UDP connections on a subnet. Netlog also includes tools to analyzing the output.

Rscan

A extensible network scanner that checks for common network problems and SGI specific vulnerabilities.
Additional Info: Rscan: Heterogeneous Network Interrogation

iplog 1.4 by Maruchanda Vishitu - March 01st 1999, 13:35 EST

http://www.ojnk.org/~eric/
iplog is a collection of daemons that log tcp, udp, and icmp traffic. It
has features not available in other traffic logging programs, including
detecting 'stealth' scans used by port scanners such as nmap, protection
against SYN floods, and logging of remote user information.

Changes: Fixed strange byte ordering problems, added some things to
avoid a port scan DoS, now logfile can be specified. Consider this the
final version.

Etc

Society

Groupthink : Two Party System as Polyarchy : Corruption of Regulators : Bureaucracies : Understanding Micromanagers and Control Freaks : Toxic Managers :   Harvard Mafia : Diplomatic Communication : Surviving a Bad Performance Review : Insufficient Retirement Funds as Immanent Problem of Neoliberal Regime : PseudoScience : Who Rules America : Neoliberalism  : The Iron Law of Oligarchy : Libertarian Philosophy

Quotes

War and Peace : Skeptical Finance : John Kenneth Galbraith :Talleyrand : Oscar Wilde : Otto Von Bismarck : Keynes : George Carlin : Skeptics : Propaganda  : SE quotes : Language Design and Programming Quotes : Random IT-related quotes :  Somerset Maugham : Marcus Aurelius : Kurt Vonnegut : Eric Hoffer : Winston Churchill : Napoleon Bonaparte : Ambrose Bierce :  Bernard Shaw : Mark Twain Quotes

Bulletin:

Vol 25, No.12 (December, 2013) Rational Fools vs. Efficient Crooks The efficient markets hypothesis : Political Skeptic Bulletin, 2013 : Unemployment Bulletin, 2010 :  Vol 23, No.10 (October, 2011) An observation about corporate security departments : Slightly Skeptical Euromaydan Chronicles, June 2014 : Greenspan legacy bulletin, 2008 : Vol 25, No.10 (October, 2013) Cryptolocker Trojan (Win32/Crilock.A) : Vol 25, No.08 (August, 2013) Cloud providers as intelligence collection hubs : Financial Humor Bulletin, 2010 : Inequality Bulletin, 2009 : Financial Humor Bulletin, 2008 : Copyleft Problems Bulletin, 2004 : Financial Humor Bulletin, 2011 : Energy Bulletin, 2010 : Malware Protection Bulletin, 2010 : Vol 26, No.1 (January, 2013) Object-Oriented Cult : Political Skeptic Bulletin, 2011 : Vol 23, No.11 (November, 2011) Softpanorama classification of sysadmin horror stories : Vol 25, No.05 (May, 2013) Corporate bullshit as a communication method  : Vol 25, No.06 (June, 2013) A Note on the Relationship of Brooks Law and Conway Law

History:

Fifty glorious years (1950-2000): the triumph of the US computer engineering : Donald Knuth : TAoCP and its Influence of Computer Science : Richard Stallman : Linus Torvalds  : Larry Wall  : John K. Ousterhout : CTSS : Multix OS Unix History : Unix shell history : VI editor : History of pipes concept : Solaris : MS DOS :  Programming Languages History : PL/1 : Simula 67 : C : History of GCC development :  Scripting Languages : Perl history   : OS History : Mail : DNS : SSH : CPU Instruction Sets : SPARC systems 1987-2006 : Norton Commander : Norton Utilities : Norton Ghost : Frontpage history : Malware Defense History : GNU Screen : OSS early history

Classic books:

The Peter Principle : Parkinson Law : 1984 : The Mythical Man-Month :  How to Solve It by George Polya : The Art of Computer Programming : The Elements of Programming Style : The Unix Hater’s Handbook : The Jargon file : The True Believer : Programming Pearls : The Good Soldier Svejk : The Power Elite

Most popular humor pages:

Manifest of the Softpanorama IT Slacker Society : Ten Commandments of the IT Slackers Society : Computer Humor Collection : BSD Logo Story : The Cuckoo's Egg : IT Slang : C++ Humor : ARE YOU A BBS ADDICT? : The Perl Purity Test : Object oriented programmers of all nations : Financial Humor : Financial Humor Bulletin, 2008 : Financial Humor Bulletin, 2010 : The Most Comprehensive Collection of Editor-related Humor : Programming Language Humor : Goldman Sachs related humor : Greenspan humor : C Humor : Scripting Humor : Real Programmers Humor : Web Humor : GPL-related Humor : OFM Humor : Politically Incorrect Humor : IDS Humor : "Linux Sucks" Humor : Russian Musical Humor : Best Russian Programmer Humor : Microsoft plans to buy Catholic Church : Richard Stallman Related Humor : Admin Humor : Perl-related Humor : Linus Torvalds Related humor : PseudoScience Related Humor : Networking Humor : Shell Humor : Financial Humor Bulletin, 2011 : Financial Humor Bulletin, 2012 : Financial Humor Bulletin, 2013 : Java Humor : Software Engineering Humor : Sun Solaris Related Humor : Education Humor : IBM Humor : Assembler-related Humor : VIM Humor : Computer Viruses Humor : Bright tomorrow is rescheduled to a day after tomorrow : Classic Computer Humor

The Last but not Least Technology is dominated by two types of people: those who understand what they do not manage and those who manage what they do not understand ~Archibald Putt. Ph.D

The statements, views and opinions presented on this web page are those of the author (or referenced source) and are not endorsed by, nor do they necessarily reflect, the opinions of the Softpanorama society. We do not warrant the correctness of the information provided or its fitness for any purpose. The site uses AdSense so you need to be aware of Google privacy policy. You you do not want to be tracked by Google please disable Javascript for this site. This site is perfectly usable without Javascript.

Last modified: March 12, 2019