Release notes for IP Sentinel, version 0.11 =========================================== In a perfect environment there are managed switches with one host per port. Unfortunately, in the reality there are often unmanaged switches, there are more than one host on a port, it takes too much effort to update the MAC-port table of the switches and so on. When having a small or middle-sized company without a seperate network department, people will take free IPs without asking the responsible part-time admin. It can be imagined easily, that this will cause problems when the device/host will not be used for a certain time, another host takes its IP and the original device will be turned on again. DHCP seems to remove the reasons for static IPs. But because there are some cases which require fixed IPs (e.g. IP-tied licences, elder applications which do not understand DNS), you will see people choosing arbitrary IPs when the part-time admin is not available for a short time (e.g. lunch break). Another example might be an ethernet subnet where people have to pay for the usage but can plugin their machines without problems (e.g. when there is a connnection port in each room). Although external usage can be prevented by packetfilters, internal and bandwidth robbing traffic (e.g. Doom deathmatches, CDROM transfer) is still possible. "IP Sentinel" tries to prevent such an unauthorized usage by giving a faked answer to ARP requests. After receiving such a faked reply, the requesting party stores the MAC in their ARP table and will send future packets to this invalid MAC which renders the IP unreachable. Beside this, "IP Sentinel" has to follwing features: - freely customizable IPs and netmasks - usual security attributes like non-root and chroot execution - protection against basic DOS attacks - small memory footprint when built with dietlibc OPERATION DETAILS ----------------- The following example demonstrates the process when an unauthorized host 'M' tries to enter a subnet: 1. Host 'M' takes reserved IP 192.168.0.1 2. Host 'A' (IP 192.168.0.2) wants to communicate with 'M' (it resolved M's IP e.g. through NetBIOS). 3. Host sends ARP-request "who-has 192.168.0.1" 4. M sends "M is-at ..." 5. "IP Sentinel" sees the request from 3. and sends a random reply "M is-at de:ad:be:ef:0:4". This step will be repeated a few times. 6. 'A' receives both replies and will store the latter one 7. 'A' sends packages for 'M' to the 'de:ad:be:ef:0:4' MAC Because "IP Sentinel" is probably slower than 'M' (there are search- and general administration cost), it can not be guaranteed that packages from 'A' do arrive 'M'. But because of the repeating of step 5, the faked MAC will be make known to 'A' after some time and a communication is impossible. Some machines check before step 1 whether an IP is already in use by sending an "who-has " (arping). Because "IP Sentinel" answers on this query, it is highly probable that 'M' will refuse to bring-up its network. Beside this operation-mode, ip-sentinel can answer arp-requests originated by an intruder also. INSTALLATION ------------ After unpacking, "IP Sentinel" can be installed with the usual './configure && make all install' steps. There are some ./configure-flags which might be interesting: * --disable-dietlibc: Because "IP Sentinel" uses low-level interfaces which are not standardized by SUSv3, there may occure problems with dietlibc<0.21. Usage of a detected dietlibc can be explicitely turned off with this flag. * --with-username=USER: "IP Sentinel" drops its privileges by going into a chroot()-directory and setuid()/setgid()'ing to another user. The passwd-entries (homedirectory, gid) of this user are used to determine the needed arguments of these operations. The default-name of this user can be set with this option but IP Sentinel allows to specify these parameters on the commandline also. By default, 'nobody' will be assumed and you *SHOULD* use this option to set a more proper name. * --with-configfile=FILE: "IP Sentinel" reads its configuration from this file which must be located inside the chroot-environment mentioned above. * --enable-release turns on various optimizations and should be used when running "IP Sentinel". Because these optimizations are making the developing impossible (e.g. no stackframe-pointers) they are disabled by default. * --enable-developing turns on extra checks and should not be used unless you want to develop "IP Sentinel". After installation, the executables 'ip-sentinel' resides in /sbin (or whatever you specified with '--sbindir'). On startup it will lookup the passwd-entries of the specified user, chdir() & chroot() into its homedirectory and call setuid()/gid() there. Under certain circumstances like a dietlibc-compiled 'ip-sentinel' and remote NIS, such passwd-lookups are failing. Then the needed parameters (uid, gid, rootdirectory) MUST be given on the commandline. Please see ip-sentinel(8) for details. The contrib/-directory in the source-tarball contains an initscript suitable for Red Hat Linux and support for 'minit'. To test some aspects of the software, it is shipped with an extensive test-suite whose tests will be executed with 'make check'. The 'src/simulate' program which is generated in this step might be useful to test real-world situations since it prints the generated ethernet/arp headers in a human-readable format. This tool is called with the same arguments like the final 'ip-sentinel' and fed on its stdin with 'A-ip A-mac B-ip B-mac' tuples: | $ echo '192.168.0.1 11:11:11:11:11:11 192.168.0.10 22:22:22:22:22:22' | \ | src/simulate -i src/testsuite/data/simulate.cfg eth0 10>&1 CONFIGURATION ------------- After successful installation, the reserved IPs can be told in the configfile (default: /ips.cfg) by the following two ways: - single IPs (e.g. 192.168.0.1) - netmasks (e.g. 192.168.0.1/255.255.255.1 or 10.0.0.0/8) - ranges (e.g. 192.168.0.{1-5}) When adding an exclamation mark ('!') in front of an IP or network specification, this IP/net will be removed from a less-specified reservation list. Analogously, IPs or networks can be added if they are more-specified than fitting negation-lists "Less-specified" means that the corresponding netmask has not so many set bits like the other mask; IPs have a mask of 32 and are most-specified. E.g. the net 192.168.0.0/16 is less-specified than 192.168.0.0/24 or the IP 192.168.0.1. When there are overlapping and conflicting statements which are specified in a similar manner, the behavior is undefined. A MAC can be assigned to single IPs or entiry networks. When not giving such a MAC, a random one will be choosen in a switch-friendly way. "Switch-friendly" means that only a small amount (32) of random MACs will be used in a certain period, so that the MAC-buffer of the switch will not overflow. Specifying a MAC will probably not work in a switched environment because the switch will see an IP at different ports and will be confused therefore. Because of the common format of the random MACs, the corresponding 'arpwatch' messages can be filtered out easily by putting | * ^ ethernet address: de:ad:be:ef:0: | * ^old ethernet address: de:ad:be:ef:0: | /dev/null into .procmailrc. EXAMPLES -------- 1. ./ipsentinel -u 42 -g 42 -r /var/lib/ip-sentinel -i x.dat eth0 Runs with an uid and gid of 42, uses /var/lib/ip-sentinel as its chroot-environment, reads 'x.dat' there and gives answers on ARP-requests on interface eth0. 2. A sample 'x.dat' might be: 0.0.0.0/0 ## block anything by default !192.168.0.0/24 ## allow IPs from 192.168.0.* 192.168.0.23 ## but reserve 192.168.0.23 192.168.{20-30}.0/24 ## and all /24 subnets between 192.168.20.0 ## and 192.168.30.0 192.168.0.42 a:b:c:d:e:f ## and 192.168.0.42 and use a specific ## MAC there 10.0.0.1@a:a:a:a:a:a ## two tagged src-ip addresses 10.0.0.2@!1:1:1:1:1:1 *@1:1:1:2:2:2 ## host with a certain MAC on every IP When "IP Sentinel" receives a request for 169.254.1.2 or 192.168.0.23, a reply like '... is-at de:ad:be:ef:0:29' will be created. IPs like 192.168.0.1 will not be handled. When an intruder is at "10.0.0.1" and uses the mac "a:a:a:a:a:a:", a faked reply will be generated. Users at the same ip but another mac will be ignored. In opposite, users with ip "10.0.0.2" and mac "1:1:1:1:1:1" will be ignored but intruders with other macs (e.g. "2:2:2:2:2:2") are getting faked replies. When --poision is used, ip-sentinel will generate a "10.0.0.2 is at 1:1:1:1:1:1" arp-reply to a broad address. The host with the MAC 1:1:1:2:2:2 will be blocked everytime; which might be wanted because it spreads viruses e.g. 'src/testsuite/data' contains other sample configfiles and expected result. TODO ---- - validate the test-results - check if it is cheaper to have the 70 bytes of data or a pointer to this data in the scheduler-heap; pointers have hidden costs for memory-management and destroy L1/L2 caching