Portscan Detection exclusions?

I'm also having trouble with Portscan Detection.  The only notifications I ever receive are from one of my internal servers.  Given past experience with public servers it hard to believe that in the month or so that we have been running Astaro we haven't been port scanned at least once.  Another thing I find odd, is that a simple nmap -P0 -T Aggressive [IP ADDRESS] on any of my public or private addresses doesn't trigger a Portscan notification.  Do packet filters happen before Portscan Detection?  That might make sense, because then most of the packet would be getting dropped before the Portscan Detection can look at them...and since most internal traffic is allowed out that would explain why I still get them from internal addresses.

Any of that sound right?

The builtin help says packetfilters come first.

BTW, I've found that our mailserver is triggering portscans on the IDENT (113) port.

Must be getting too many incoming emails.

I wish there was a way to exclude the mailserver, or just that port, from PSD.

I'm also seeing PSD alerts from normal http traffic against our web server.

Barry

Packet filters coming first is a puzzle.
In most environments, nearly all port-scan activity will be blocked by default pakcet filter rules.  Port scans are by definition a flood of packets over a broad range of ports.  If default packet filter rules only allow a few through which are then analyzed to see if they meet the definition of a port scan, this should almost never be triggered even though an interface is receiving a multitude of port scans.

I'm not sure if this is done to preserve cpu cycles, but I think it would be VERY important to know key data of ALL portscans.
Specifically: WHO is implementing them? [ip address]
                   WHEN are the scans implemented?
Without this very basic information, a network is potentially vulnerable to prolonged scrutiny by a potential intruder.

I believe this model defeats the purpose of port scan detection.  Very little is being detected if packet filters are set up carefully.

Someone show me how I'm wrong, please.

Packet filters coming first is a puzzle.
In most environments, nearly all port-scan activity will be blocked by default pakcet filter rules.  Port scans are by definition a flood of packets over a broad range of ports.  If default packet filter rules only allow a few through which are then analyzed to see if they meet the definition of a port scan, this should almost never be triggered even though an interface is receiving a multitude of port scans.

I'm not sure if this is done to preserve cpu cycles, but I think it would be VERY important to know key data of ALL portscans.
Specifically: WHO is implementing them? [ip address]
                   WHEN are the scans implemented?
Without this very basic information, a network is potentially vulnerable to prolonged scrutiny by a potential intruder.

I believe this model defeats the purpose of port scan detection.  Very little is being detected if packet filters are set up carefully.

Someone show me how I'm wrong, please.

I still get lots of PS alerts, but we have a whole public subnet behind ASL.

The snort in ASL is "inline" which means it only sees packets which are passing through the firewall, not ones which are blocked. It's probably more reliable this way.

If you really want to detect ALL of them, you can run an IDS on the outside of the firewall.

Or, voiding your ASL support, you can install another copy of Snort, and run it in promiscous mode on the EXT interface.
This will see all the traffic, including packets blocked by ASL.
You can have it log to a MySQL database on another computer and use ACID or BASE or whatever.

Barry

I AM running IDS on the external interface...


No portscans are flagged, though on a Comcast cable connection, I'm sure I'm getting plenty.

[ QUOTE ]
I AM running IDS on the external interface...

No portscans are flagged, though on a Comcast cable connection, I'm sure I'm getting plenty. 

[/ QUOTE ]Typically there will be a lot of probing for open ports, I'm seeing 20 to 50 per hour, but no port scans. The probing for open ports on the Internet has become so prevalent that one has to take it in stride, like the background radiation in the universe.

To test your portscan detection, use the Gibson ShieldsUP! web site and scan your external IP address from there. That will trigger  port scan notification emails from ASL. You can get to ShieldsUP! from the URL below:

http://www.grc.com/

 [ QUOTE ]
I AM running IDS on the external interface...

[/ QUOTE ] 

But it's NOT promiscous.
That was my point.

Barry

Ahhh I see.

I still contend that not knowing about the lions share of actual incoming port scans is a major problem if this is going to be a serious contender in network security tools.

Perhaps this would be a usefull option to have on the IDS setup (run snort inline or promiscous)? Running in promiscous ahead of the packet filter would give you more information about possible network scans, etc. but would make for bigger logs and more CPU cycles. Not everyone is going to care about that level of detail (since much of it may never make it past the firewall anyway) and running it inline may be fine for them (smaller logs, less CPU, but can still catch strange traffic making it to the internal network).

http://searchsecurity.techtarget.com/tip/1,289483,sid14_gci962158,00.html

talks a bit about where to place the IDS and the tradeoffs.

If you don't run it inline, then it can't work as an IPS (Intrusion PREVENTION System); it'd just be an IDS.
(IPS can block/drop hostile traffic, IDS cannot.)

What I was suggesting was to add another snort sensor on the external network somewhere if you want to log all hostile traffic, even if it is blocked by your packetfilter rules.
You can do this with a passive tap off of your incoming internet connection.
Or, you can run a separate snort installation on ASL, but this will likely void your support  contract.

Barry

Good point. I was thinking just in terms of monitoring traffic (detection vs. prevention). One of those trade offs.