ipt_PORTNETSCAN --------------- ipt_PORTNETSCAN is an extension of IpTables for recognition of Portscan, Netscan or combined scans. The development is divided in two parts: o Kernelmodule o IpTables extension Actual we must patch for the usage the IpTables and the Kernel sources together. Linux Kernel patch ------------------ Before we can patch IpTables, we must patch the Kernel itself, because the IpTables check at the compiling which modules exist in Kernel and activates or not the extension in the IpTables. 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 Patch from 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. Instalation ------------ 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 option] –m PORTSCAN [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 (2minutes) 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 <[IpTables]>. 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 (1hour) 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 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 [Number] (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 [Number] (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 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. 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: | --------------------------------------------------------------- | | iptables -A ... -m PORTNETSCAN --check-deny-entries -j DROP | -- | --------------------------------------------------------------- | | | | | V | | --------------------------------------- | | | iptables -A ... | -- | | --------------------------------------- | | | --------------------------------------- | | | | iptables -A ... | -| -------- | | --------------------------------------- |->|ACCEPT| | | --------------------------------------- | -------- | | | iptables -A ... | -| | | --------------------------------------- | | | --------------------------------------- | | | | ... | -- | | --------------------------------------- | | | | | V | | --------------------------------------------------------------- | | | iptables -A ... -m PORTNETSCAN -j DROP | -- | --------------------------------------------------------------- | ------ | --------------------------------------------------------------- |->|DROP| | | iptables -A ... -J DROP | -- ------ | --------------------------------------------------------------- V IpTables rules 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: | --------------------------------------- | | iptables -A ... (Ausnahme1) | -- | --------------------------------------- | | --------------------------------------- | | | iptables -A ... (Ausnahme1) | -| -------- | --------------------------------------- |->|ACCEPT| | --------------------------------------- | -------- | | iptables -A ... (AusnahmeXXX) | -- | --------------------------------------- | | | V | --------------------------------------------------------------- | | iptables -A ...(Einschränkungen) -m PORTNETSCAN -j DROP | -- | --------------------------------------------------------------- | | --------------------------------------- | | | iptables -A ... | -- | | --------------------------------------- | | | --------------------------------------- | | | | iptables -A ... | -| -------- | | --------------------------------------- |->|ACCEPT| | | --------------------------------------- | -------- | | | iptables -A ... | -| | | --------------------------------------- | | | --------------------------------------- | | | | ... | -- | | --------------------------------------- | | --------------------------------------------------------------- | ------ | | iptables -A ... -J DROP | --->|DROP| | --------------------------------------------------------------- ------ 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 # ################################################################################# # Web server 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 for standard connections Port 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 # End of all Standard-Rules ################################################################################# # PORTNETSCAN Überprüfung Auffälligkeiten iptables -A FORWARD -i eth0 -o eth1 -m PORTNETSCAN --trace-entries 12000 \ -j DROP ################################################################################# # Rest Ablehen iptables -A FORWARD -j DROP ################################################################################# # Policy-Standard-Rule setting (is not mandatory the last rule. # Rule for all packets "DROP" IPTABLES -P FORWARD DROP 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 is checked only whether the source address of the machine is already in the refusal list. An unusual behavior like Port-, net-, or combined scan would not be seen in the monitoring entries. In the second call after the standard rules the module would be called with the arguments -m PORTNETSCAN --trace-entries 12000 Now it is checked from the module, whether an unusual behavior is available and if it surpasses one of the set threshold values. If this should be the case, the entry is moved into the refusal list. From this moment on while calling the function of the module in IpTables a successful event is reported back for this source address. In the case of specification of "-DROP j" in IpTables the packet is rejected in the Kernel.