AW: patch: Port- and netscan detection for netfilter

The problem is, on the most attacks, the hacker try to get
some information on the network. This module implements 3
different situations:

- Netscan (Scan more hosts on less ports)
- Portscan (Scan less Hosts and many ports)
- Combined Scan (Scan many Ports on many)

On the testing-systems we can see, that the attacs to
different service will be less then before! The interesting
thing is, that no more attacks on unknown services are
happens. 

The Portscan is only the one side - the other side is, that
the source can be blocked on a defined time - please read
the documentation ipt-portscan.sourceforge.net. 

LG

Robert

-----Ursprüngliche Nachricht-----
Von: netfilter-devel-bounceslists.netfilter.org
[mailto:netfilter-devel-bounceslists.netfilter.org] Im
Auftrag von Patrick McHardy
Gesendet: Freitag, 16. März 2007 16:41
An: Gladewitz, Robert (FH)
Cc: netfilter-devellists.netfilter.org
Betreff: Re: patch: Port- and netscan detection for
netfilter

Gladewitz, Robert (FH) wrote:
> in my Master-Theses I designed a new kernel- and
netfilter module for
> detection of net- and portscans. Now, the module is
tested on more then
> 10 different firewall-installations. It's working
without any problems
> during the last 8 months.
> 
> Your can read the documentation on
> http://ipt-p
ortnetscan.sourceforge.net/. There is also a possibility
to
> download all versions of Kernel- and IpTables-Patches.
> 
> I would be pleased to see you integrated these patches
into IpTables of
> your use.
> Looking forward to your answer

Please attach patches inline so they can be read in the mail
client.

> +++ linux-2.6.20.2/Documentation/ipt_PORTNETSCAN.txt
>  -0,0 +1,389 
> +Allgemein Informationen zum Modul ipt_PORTNETSCAN

Luckily I speak german 

But seriously, we already had different portscan-detection
matches
submitted, but decided against merging them since its not
clear
what the benefit of detecting scans is. It clearly doesn't
improve
security since

- you can just scan slow enough not to be detected
- you don't need to scan to crack something

So all it offers is a bit of correlated information
("you were scanned
by ..."), that can also be extracted from log-files.

Gladewitz, Robert (FH) wrote:
> The problem is, on the most attacks, the hacker try to
get some information on the network. This module implements
3 different situations:

Putting aside the question of the usefulness of this, whats
the
difference to using the three rules below?

> - Netscan (Scan more hosts on less ports)

iptables -A PREROUTING -m state --state NEW 
		       -m hashlimit --hashlimit-name netscan 
				    --hashlimit-mode dstip 
				    --hashlimit n/sec 
		       -j DROP

> - Portscan (Scan less Hosts and many ports)

iptables -A PREROUTING -m state --state NEW 
		       -m hashlimit --hashlimit-name portscan 
				    --hashlimit-mode dstport 
				    --hashlimit n/sec 
		       -j DROP

> - Combined Scan (Scan many Ports on many)

iptables -A PREROUTING -m state --state NEW 
		       -m hashlimit --hashlimit-name portnetscan 
				    --hashlimit-mode dstip,dstport 
				    --hashlimit n/sec 
		       -j DROP

Hello Patrick,

This module is not designed for using as locally firewall,
it is designed for router in networks with dmz. For this,
all connection is saved in an tree-structure. Internal, I
look for all Connection the rule sends to check. (Look at
the time background) If the module have same connection
(source - Destination) the the module decide on following
rules (positive or false answered -from -m). For this, the
module saves source-ip, dest-ip and dest-port.

Definition: netscan for source address is recognized when: 
----------------------------------------------------------
(number of destination hosts / number of destination ports)

> Defined threshold value (quota) for netscan


Definition: portscan for source address is recognized when:
----------------------------------------------------------
(number of destination ports / number of destination hosts)

> Defined quota for portscan

Definition: combined-scan for source address is recognized
when:
----------------------------------------------------------
(number of destination ports / number of destination hosts)

> Defined threshold value (quota) for combined scan


For all actions your can be sure, that a port- or netscan is
be happening, not only less / many - port / hosts!! The
module can be sure deside, that the many dest-port (for
axamlpe) comes from this source-host!

Please read the documentation /and or source - it is
completely different to all other modules. The Idea is, that
your look for all connection, which are match by the rule -
the state is totally uninteresting. 

If a source-host is identified as a scan-host you can drop
the all packages from dir source-ip for a defined time. The
interesting is also, that you can use it for DROP-Packet on
the end of all rules also (In the documentation I have
defined 2 sceneries). On the start of the rules, your have
only a check-line - on the end of all rules, you test if the
client have to much denied traffic - then you can drop all
package up this time.

The next is, your can check the state of connections and
DENY-Hosts in /proc/net/stat/portnetscan

For the future, I planed a detection of Bot-Net-Scans.

Cu

Robert


-----Ursprüngliche Nachricht-----
Von: Patrick McHardy [mailto:kabertrash.net] 
Gesendet: Montag, 19. März 2007 05:59
An: Gladewitz, Robert (FH)
Cc: netfilter-devellists.netfilter.org
Betreff: Re: AW: patch: Port- and netscan detection for
netfilter

Gladewitz, Robert (FH) wrote:
> The problem is, on the most attacks, the hacker try to
get some information on the network. This module implements
3 different situations:

Putting aside the question of the usefulness of this, whats
the
difference to using the three rules below?

> - Netscan (Scan more hosts on less ports)

iptables -A PREROUTING -m state --state NEW 
		       -m hashlimit --hashlimit-name netscan 
				    --hashlimit-mode dstip 
				    --hashlimit n/sec 
		       -j DROP

> - Portscan (Scan less Hosts and many ports)

iptables -A PREROUTING -m state --state NEW 
		       -m hashlimit --hashlimit-name portscan 
				    --hashlimit-mode dstport 
				    --hashlimit n/sec 
		       -j DROP

> - Combined Scan (Scan many Ports on many)

iptables -A PREROUTING -m state --state NEW 
		       -m hashlimit --hashlimit-name portnetscan 
				    --hashlimit-mode dstip,dstport 
				    --hashlimit n/sec 
		       -j DROP

On Mar 19 2007 14:12, Gladewitz, Robert (FH) wrote:
>
>This module is not designed for using as locally
firewall, it is designed
>for router in networks with dmz.

Who said -m hashlimit/-m recent was limited to a local
firewall?

>For all actions your can be sure, that a port- or
netscan is be
>happening, not only less / many - port / hosts!! The
module can be sure
>deside, that the many dest-port (for axamlpe) comes from
this
>source-host!

Do yourself a favor: Add a rule -m hashlimit
--hashlimit-mode srcip,dstip
to your router (not 'local firewall') and do a portscan.
Watch the
iptables -nvL counters on that rule rise.

>Please read the documentation /and or source - it is
completely different
>to all other modules. The Idea is, that your look for
all connection,
>which are match by the rule - the state is totally
uninteresting.

The state _is_ interesting. Because ESTABLISHED connections
are, with the
exception of Connect and Grab scans [ct], always
"good" ones, i.e. the
firewall cannot decide, with the exception of [l7] and [l7]
is also more
like [l5], if traffic is good or evil.

>
>If a source-host is identified as a scan-host you can
drop the all
>packages from dir source-ip for a defined time.

You fail to explain, given that we know a certain host is
"evil", why -m
recent cannot be used to drop its evil packets.

>The interesting is also, that you can use it for
DROP-Packet on the end
>of all rules also (In the documentation I have defined 2
sceneries). On
>the start of the rules, your have only a check-line - on
the end of all
>rules, you test if the client have to much denied
traffic - then you can
>drop all package up this time.

Your check line is equivalent to -m recent
--rcheck/--update.

The one at the end of the rules is eqv. to -m recent --set.

>The next is, your can check the state of connections and
DENY-Hosts in
>/proc/net/stat/portnetscan

(And ipt_recent has also its own proc file for listing
denied/matched hosts)


>-----Ursprüngliche Nachricht-----
>Von: Patrick McHardy [mailto:kabertrash.net] 
>Gesendet: Montag, 19. März 2007 05:59
>An: Gladewitz, Robert (FH)
>Cc: netfilter-devellists.netfilter.org
>Betreff: Re: AW: patch: Port- and netscan detection for
netfilter
>
>Gladewitz, Robert (FH) wrote:
>> The problem is, on the most attacks, the hacker try
to get some information on the network. This module
implements 3 different situations:
>
>Putting aside the question of the usefulness of this,
whats the
>difference to using the three rules below?
>
>> - Netscan (Scan more hosts on less ports)
>
>iptables -A PREROUTING -m state --state NEW 
>		       -m hashlimit --hashlimit-name netscan 
>				    --hashlimit-mode dstip 
>				    --hashlimit n/sec 
>		       -j DROP
>
>> - Portscan (Scan less Hosts and many ports)
>
>iptables -A PREROUTING -m state --state NEW 
>		       -m hashlimit --hashlimit-name portscan 
>				    --hashlimit-mode dstport 
>				    --hashlimit n/sec 
>		       -j DROP
>
>> - Combined Scan (Scan many Ports on many)
>
>iptables -A PREROUTING -m state --state NEW 
>		       -m hashlimit --hashlimit-name portnetscan 
>				    --hashlimit-mode dstip,dstport 
>				    --hashlimit n/sec 
>		       -j DROP
>
>
>

Jan
--