ipt_PORTNETSCAN

ipt_PORTNETSCAN is an extension of IpTables for recognition of Portscan, Netscan or combined scans. The development is divided in two parts:

• Kernelmodule
• IpTables extension

Downloads:

• Project summarized
• Documentation TXT formated (Englisch)
• Documentation TXT formated (Deutsch)
• Documentation HTML formated (Deutsch)

Actual we must patch for the usage the IpTables and the Kernel sources together.

Linux Kernel patch

After downloading Linux Kernel from the www.kernel.org or one of the mirror sites you must pack this and then use the patch on the Kernel.

	patch -p0 < linux-2.6xxx.patch

Patchen von IpTables

First you must download the actual version of the IpTables from the www.netfilter.org . After the unpacking you should change the wished parameter into the existent destination system of the make file. The patch follows the commend:

	patch -p0 <  IpTables-xxx.patch

For recognizing the scans we use in the module defined threshold values, which can be set for each situation. Doing this we can subtract and use different characteristics and dependency from the sort of information gaining for the refusal of assault.

The important information of certain assault situation are analyzed and evaluated in the following documentation. In the actual analyses we consider only skills of the family protocol IpV4, because it is the actual version of the used Internet protocol. There is no change planed on the IpV6 at the time.

Detection of a Portscan
At an assault or information seek through a portscan; we scan different ports of the destination system. The inquiring of the port happens often in uncertain order and time schedule.

All packets must pass the outer firewall router before they reached the destination system. This router can also find out through saving of the actual packets in an interval time, that a certain PC tries to use a portscan on the DMZ. In many sources the portscan and netscans make no difference. For the analyses is this very important, because the two scans show differences in their characteristics.

In vielen Quellen werden Portscans und Netscans nicht unterschieden. Zur Analyse ist dies aber unbedingt notwendig, da diese beiden Scans Unterschiede in Ihrer Charakteristik aufweisen.

Here an example: for the portscan we have the destination address 1.1.1.2 and the source address 2.2.2.1 as a basis. Now the scanned ports of the assaulting system are chosen by accident and the following packets be evaluated by the extern router:

The packets, which can be considered by the portscan, are marked red in the table. There can be put together next information for the portscan

• Source address: 2.2.2.1
• Destination address: 1.1.1.2
• Destination ports: 139, 445, 1026, 80

Through its characteristics we can easily econ a portscan: A PC from the internet tries to build up on more ports a connection to a PC in the DMZ.

It is also possible that a source address of non-assaulters gets on more ports of the destination PC, but stays reduced on the number of the allowed services. If there is a web server, which offers port 80 and 443 as web service, each of the source addresses is to be evaluated as an assaulter or observer with more than two destination ports

That is why there is at a defined threshold values of two destination ports on the destination PC one Portscan, if there is no destination server which supports more than two services in the entire destination net. For simplifying the later data implementation we can use a simple formula:

(number of destination ports / number of destination hosts) > defined quota for portscan

The characteristics of a netscan are that from different servers of one PC there can be asked on the same destination port. Some assaulters define a few ports for scanning a net. In this case the assaulter gets an overview of one or more services, which are active in the network.

As an example for netscan in the environment of DMZ of the source net on 1.1.1.0 with the subnet 255.255.255.0 we consider. The assaulter gets the address 2.2.2.1. During the assault we can evaluate the following packages from the outer router:

The important packages are marked red. A source PC tries to reach some of the destination addresses on the same destination port. As the scanned destination port stays mainly the same or only a few destination ports are scanned, we can use a simplified formula for the implementation.

Definition: netscan for source address is recognized when:

(number of destination hosts / number of destination ports) > defined threshold value (quota) for netscan

For later configuration we must take care the threshold value does not go under the number of the destination server defined with the same services.

Detection of a combined scans

A combined scan is more complex. The attacker combines port and net scan together in order to obtain more information about the destination net. In this case there will be asked more destination ports and addresses in a defined time. That means that the two formulas for the recognition of the netscan or portscan cannot be used, as the threshold value for the related calculation doesn't fit anymore for port and netscan performance.

For an investigation there must be considered a destination net from the point of view of the attacker. The attacker doesn't know at this point which services are really offered in the destination net. He must scan; in case of a combined scan the entire destination net with all interesting destination ports to be able to get to the wished information. For such a scan many destination ports and addresses are asked. If we start from

• two web server (http),
• one web server SSL (https),
• two DNS server and
• one SMTP server

in the DMZ that means, that there are on six servers six services. If a client use all services he would use twelve different destination addresses and ports. That fore we can use a simple formula for recognition (combined scan for a source address):

(number of destination ports / number of destination hosts) > defined threshold value (quota) for combined scan

Installation

IpTables / Netfilter

Usage and documentation of the Kernel module

The Kernel module is automatically downloaded with the usage if the new IpTables rules with the parameter -m PORTSCAN in Kernel. The parameters are described as follows. Especially there must be considered the parameterization depending on the usage intension. False parameterization can cause the failure of the network. The possible application areas we describe as follows:

• monitoring of refused packets
• monitoring of certain services or net areas

General synopsis for the appeal of the module ipt_PORTSCAN

The module is called up through a IpTables filter regulation with the option -m PORTSCAN.

iptables [iptables options] -m PORTNETSCAN [Options]

Constriction or filter rules can be defined in IpTables through all implemented IpTables options. The functions of this module are called up, only if the afore defined filter or constriction are valid in the IpTables option.

The module PORTNETSCAN has some options, which we describe as follows.

Overview of the options

--tree-deep [1|2|4|8|16|32]
Standard: --tree-deep 4

This option gives the tree deepness of the search index (trace tree/supervising list). At a given tree deepness of 1 we use a simple chain list as search index. For independent test rows the tree deepness of 4 turned out as optimal. At these tests we considered more than 1000 simultaneous connections.

--trace-time [Seconds] (10-3600)
Standard: --trace-time 120 (2 minutes)

The Option trace-time gives the time in seconds, that a source address is monitored. As long as packets are monitored through the rule, the monitoring time begins anew. This means that e.g. in the case of a value the monitoring entry of the source address is not removed by 20 in this option before then when these 120 seconds' no test anymore has required, that is that in this time slot no packet was sent to rule for the inspection onto the module by the . This is normally the case if the machine does not have any connection anymore to the destination system.

--block-time [Seconds] (0-172800)
Standard: --block-time 3600 (1 hour)

The Option block-time gives the time in seconds, that the source address of a machine is blocked out if one of the defined threshold values (Quotas) is fulfilled. The machine is cleared in the case of surpassing the threshold value (Quota) from the monitored entries and moved into the refusal list. This list is a normal concatenated list in the memory and is in addition not indexed.

--clean-interval [Seconds] (1-60)
Standard: --clean-interval 1 (1 seconds)

standard: --clean-interval 1(1 second) This Option defines the interval after which obsolete entries are deleted from the monitoring and refusal lists. Also in the kernel is defined a global interval after which obsolete entries of all configuration environments are cleared

--max-deny-entries [Count] (10-2000)
Standard: --max-deny-entries 10

The Option max-deny-entries set how many entries are stored maximally per configuration environment in the refusal list. When the maximum defined number is surpassed, the oldest entry is removed from the refusal list and the new one added. Since a tree does not index this list, the value must not be defined too large otherwise this can have an influence on the network performance.

--max-trace-entries [Count] (10-20000)
Standard: --max-trace-entries 3000

Through the option max-trace-entries we define how many entries are stored maximum per configuration environment in the monitoring list. If this value is surpassed, the oldest entry is removed from the list and a new one added

--port-scan-quota [Quota] (3-1000)
Standard: --port-scan-quota 10

This Option determines from which threshold value (Quota) a port scan is recognized. A port scan is considered when the following prerequisite is fulfilled: (Destination ports / destination addresses) > port-scan-quota

--net-scan-quota [Quota] (3-1000)
Standard: --net-scan-quota 10

By means of this option it is determined from which threshold value (Quota) a Combined-scan would be recognized. A Netscan is considered when the following prerequisite is fulfilled: (Destination address / destination port) > net-scan-quota

--combined-quota [Quota] (6-1000)
Standard: --combined-quota 50

Through this option it is determined from which threshold value (Quota) a Combined-Scan is recognized. A Combined-Scan is considered when the following prerequisite is fulfilled: (Destination addresses + destination ports) > combined-quota

--check_deny_entries
Standard [No Parameter]

If this option is specified, a check is performed whether the source address is in the refusal list. For this case a positive value is returned to IpTables.

Distinction operational areas

The sequence of rules is important during the use of IpTables. An improper use can restrict access to a service or to the Internet.

For the use of the module two scenarios are suggested. These are distinguished generally and later a more precise definition is given.

Application of the module of a packet rejected for the monitoring

In the first consideration of the module application is gone out from a firewall with already a clearly| reduced filter rules for the used services and applications. The use of the module broadens the firewall by the dynamic recognition and refusal of Port-, network engineering tool- or Combined-Scans. Through that also services, which are allowed in the firewall for certain, servers can be hidden from an attacker. It is simultaneously guaranteed that the services without restrictions can be used.

For this scenario following rules must be kept to:

1. The module is only fully operable; if the firewall is based on the design "Everything not explicitly specified is prohibited".
2. Before the rule is available the option "--check-deny-entries" should be set by calling the module. .
3. After these rules all rules must follow for allowed network traffic.en.
4. At the end of the rule list of IpTables the module without the option "--check-deny-entries" must be called.
5. Otherwise the same configuration parameters must be used as before in order to have the same configuration environment in all calls of the module.

In the following sketch the correct use is displayed:

Application of the module for monitoring specific services or network domains

A further possible application is the use of the module for purely monitoring the firewall. Other filter rules, which are used for necessary services in the firewall, are only processed after calling the module PORTNETSCAN. Before these rules exceptions must be defined in order to prevent packets been incorrectly rejected. The following diagram describes the sequence of the processing for this purpose:

By the use of this module for this scenario it must be checked exactly for which servers or clients in the internal network multiple connections must be allowed. Furthermore a clear restriction should be placed in the called rule in IpTables. Restrictions can be for e.g.: - to the TCP SYN bit of a TCP connection or the destination ports of an application.

With this operation it is recommended to use several configuration environments and an allocation of different rules so that the states of the firewalls can be recognized.

Information about the module status in the proc-file system

By the implementation of the kernel module ipt_PORTNETSCAN an automatic entry is created under Proc- proc/net/stat/portnetscan. Here lies all information over the status of the module.

Through the number of the monitored entries the number of the output lines can become very large. Therefore the lines are outputted according to contents of information with a defined first letter for the identifier:

	G  - Number of global configuration environments
	U  - Current time (Unix time)
	J  - Current kernel time (jiffies)
	C  - Next global cleanup task (jiffies)
	L  - Configuration environment entry
	D  - Refusal entry list
	T  - Monitoring entry list
	

Subsequently a sample output with a monitored entry is displayed:

# IpTables PORTNETSCAN MODUL
# --------------------------
#
G       Count_Global_Conf: 1
U       Updating_Time(Unix): 1151670238
#
J       Updating_Time(jiffies): 170718608
C       Next_Cleanup_Time(jiffies): 170725409
#
# Conf_Entries
# ------------
#
#       confn/tree-deep/trace-time/clean-interval/port-scan-quota/net-scan-quota/combined-quota/max-deny-entries/max-trace-entries/block-time/tree-count/endnode-count/denylist-count
L       0       4       3600    1       4       4       8       50      10000   36000   20      5       5
#
# Deny_Entries
# ------------
#
#       confn/ipaddress/starttime/endtime/count/reason
D       0       202.99.174.208  1151666423      1151702423      6       netscan_detected
D       0       220.45.224.26   1151666512      1151702512      499     netscan_detected
D       0       222.76.210.149  1151666756      1151702756      16      netscan_detected
D       0       206.155.58.83   1151667516      1151703516      105     netscan_detected
D       0       64.114.81.195   1151668641      1151704641      161     netscan_detected
#
# Trace_Entries
# -------------
#
#       confn/ipaddress/firsttime/lasttime/count/countdst/countdpt
T       0       219.136.206.12  1151665723      1151668290      6       3       1
T       0       195.22.30.100   1151667986      1151667995      3       1       1
T       0       80.247.193.215  1151668045      1151668488      2       2       1
T       0       193.189.68.70   1151668446      1151668449      2       1       1
T       0       65.214.44.227   1151669558      1151669567      3       1       1

All variables are separated with the character ":" All list values would be TAB separated. Thus information over the state of the module can be struck in scripts or external programmes easily. All entries for the refusal list (Deny_Entries) and the monitoring list (Trace_Entries) are outputted along with the configuration environment (conf). As already noted above, it can happen that a source address appears repeatedly, however, per configuration environment only once!

An example of the practical application

In this example only packages and connections are supervised, that were not permitted according to the rules for services and applications by the Firewall. The following environment is accepted:

Netz DMZ: 1.1.1.0/24
Network card external Router:
	- eth0: to the Internet
	- eth1: to DMZ
Web server Standard http Port 80:
	- 1.1.1.4
	- 1.1.1.43
DNS-Server
	- 1.1.1.3
Proxy-Server (http-Proxy)
	-1.1.1.2

The following example script of the Firewall is represented without use of additional chains for IpTables or data structures in Scripts, in order to emphasize substantial contents and increase the legibility.

#!/bin/bash
#...
##############################################################################
# PORTNETSCAN: Examining refusal list
iptables -A FORWARD -i eth0 -o eth1 -m PORTNETSCAN --check-deny-entries\
         --trace-entries 12000 -j DROP
#
# Standard packet filter rules
##############################################################################
# Webserver 1.1.1.4
iptables -A FORWARD -j ACCEPT -p TCP -i eth0 -o eth1 -d 1.1.1.4/32 --dport 80 \
	--sport 1024:
iptables -A FORWARD -j ACCEPT -p TCP -i eth1 -o eth0 -s 1.1.1.4/32 --sport 80 \
	--dport 1024: !--syn
# Webserver 1.1.1.43
iptables -A FORWARD -j ACCEPT -p TCP -i eth0 -o eth1 -d 1.1.1.43/32 \
	--dport 80 --sport 1024:
iptables -A FORWARD -j ACCEPT -p TCP -i eth1 -o eth0 -s 1.1.1.43/32 \
	--sport 80 --dport 1024: !--syn
##############################################################################
# DNS Server 1.1.1.3
# DNS: Server - Server
iptables -A FORWARD -j ACCEPT -p UDP -i eth0 -o eth1 -d 1.1.1.3/32 --sport 53 \
	--dport 53
iptables -A FORWARD -j ACCEPT -p UDP -i eth1 -o eth0 -s 1.1.1.3/32 --sport 53 \
	--dport 53
# DNS: Server - Client
iptables -A FORWARD -j ACCEPT -p UDP -i eth0 -o eth1 -d 1.1.1.3/32 --sport 53 \
	--dport 1024:
iptables -A FORWARD -j ACCEPT -p UDP -i eth1 -o eth0 -s 1.1.1.3/32 \
	--sport 1024: --dport 53
# DNS: Client - Server
iptables -A FORWARD -j ACCEPT -p UDP -i eth0 -o eth1 -d 1.1.1.3/32 \
	--sport 1024: --dport 53
iptables -A FORWARD -j ACCEPT -p UDP -i eth1 -o eth0 -s 1.1.1.3/32 \
	--sport 53 --dport 1024:
##############################################################################
# Proxy Server (only standard ports 80 und 443)
iptables -A FORWARD -j ACCEPT -p TCP -i eth1 -o eth0 -s 1.1.1.2/32 \
	--sport 1024: --dport 80
iptables -A FORWARD -j ACCEPT -p TCP -i eth0 -o eth1 -s 1.1.1.2/32 \
	--dport 1024: --sport 80 !--syn 
iptables -A FORWARD -j ACCEPT -p TCP -i eth1 -o eth0 -s 1.1.1.2/32 \
	--sport 1024: --dport 443
iptables -A FORWARD -j ACCEPT -p TCP -i eth0 -o eth1 -s 1.1.1.2/32 \
	--dport 1024: --sport 443 !--syn 
# Ende aller Standard-Regeln
##############################################################################
# PORTNETSCAN 
iptables -A FORWARD -i eth0 -o eth1 -m PORTNETSCAN --trace-entries 12000 \
	-j DROP
##############################################################################
# DROP here
iptables -A FORWARD -j DROP
##############################################################################
# Policy-Standard-Rule setting (is not mandatory the last rule.) 
#Rule for all packets "DROP"
IPTABLES -P FORWARD DROP't

In this script the change of the parameters of the module was displayed. The argument "--trace-entries" was set to the value 12000. This must happen in both calls of the module so that the two calls are executed in the same configuration environment.

In the first call with the arguments

-m PORTNETSCAN --check-deny-entries --trace-entries 12000

In the second call after the standard rules the module would be called with the arguments

-m PORTNETSCAN --trace-entries 12000