Back to files

IP Masquerade Log

The following is related to version 1.0.2

** What does this patch do?

Scenario

You are the network administrator of yourdomain.com and you have (at least part of) your network behind a masquerader. Suddenly the net admin of victim.com calls you saying that someone from your network last night has cracked (or tried to crack) his machines. He says to you: "the attack to crackme.victim.com (on port 31337) came from masquerader.yourdomain.com (port 666)". Your boss is furious and orders you to find the *%@$$#@! luser that did that __NOW__. Unfortunately you can't do this since there's no way to know who, at that time, was using that port on the masquerader...

Solution

This patch allows a Linux masquerader to log all the (masqueraded) outgoing TCP connections. Other connections (such as non-masqueraded ones) are not logged. Moreover only the masquerader has to be modified: the clients could even use different OS.

It works by logging:
[-1-] the IP address and the port of the client [-2-] the IP address and the port of the server [-3-] the IP address and the port of the masquerader

With this information you can know, in the above scenario, that the connection masquerader.yourdomain.com:666 [-3-] ==> crackme.victim.com:31337 [-2-] was started by attacker.yourdomain.com [-1-] from port 1234.

Now please note that this is NOT enough: if attacker.yourdomain.com is a multiuser machine at that time there could be 100 users logged in. Moreover a malicious user could attack crackme.victim.com from attacker.yourdomain.com even without being logged in (with either cron or with a background job or... etc.).

Since we don't want the users being able to hide themselves in this way, the masquerader makes a IDENT query to the client and, if IDENT is available, adds the response to the log together with [-1-], [-2-] and [-3-].

It's therefore recommended (although it's optional) that you enable the IDENT service on all hosts on the internal network. Please note that if you restrict the IDENT service (e.g. with TCP wrappers) to the masquerader it won't work (exercise: can you understand why?).
If your network configuration on the masquerader is OK, remote hosts won't be able to do IDENT queries (since they can't pass through the masquerader). Therefore allowing "everyone" to do IDENT queries on the clients should be safe enough. If you wish to allow remote hosts to do IDENT queries you can install a special IDENT server on the masquerader, like pnidentd (for example).

** Requirements:

• Linux 2.2.19 source tree

It's possible that this patch won't work anymore with newer kernels. In that case, fix it and send me the new patch ;-)

• IDENT service on the clients (optional but recommended).

If you have IDENT the user name will be logged too.

** Installation:

1. Unpack the kernel tree somewhere (let's say /usr/src/) in a directory called linux/
2. Change directory to /usr/src/
3. Do:

# patch -p0 < /path/to/ip-masq-log-1.0.2/patch.diff

4) Now change directory to linux/ and configure your kernel as usual. Enable masquerading log support. Please note that in order to see that option you must enable:
- masquerading (obviously)
- module support (even if this patch doesn't directly use modules :-) - kmod (Kernel module loader)
- transparent proxy support

5) Do (as usual):

# make clean ; make dep ; make bzImage ; make modules ; make modules_install

or something analogous for installing the kernel. Don't forget to rerun lilo, etc. etc.

6) Return to the ip-masq-log directory

7) If you don't want /var/log/masquerader as the log file, modify masq_log.c

8) Run "make install" : this will install masq_log in /sbin

9) Reboot.

If you have troubles, look at kernel logs (usually /var/log/messages) for errors.

** Suggestions:

If you don't want to install masq_log in /sbin, you must modify the hardcoded path in linux/net/ipv4/ip_masq_log.c

If you use ssh (or openssh) on some host in your network, do yourself a favor and remove the suid bit from the ssh1 executable. You may wish to see the ssh man page before doing so.
This is because suid ssh and IDENT don't mix well. Try it.

** Notes:

Remember that if some users on your network have root access on their box, you can't trust IDENT responses. Moreover they could even change the IP address, etc.

Because of implementation and performance reasons, the TCP data stream is asynchronous with the IDENT query. This means there's a race: if the TCP connection is opened and then quickly closed, the log will probably show an error IDENT response (i.e. the IDENT daemon will answer "there's no user on the port"). This happens if a client tries to connect to a server on a closed port, too. (I don't think this can cause troubles, however).

A new masq_log process is started on a masquerader every time a TCP connection is opened or closed in the following way: 1- TCP connection opened & masqueraded
2- a new masq_log process starts
3- the masq_log process does an IDENT query 4- the masq_log process logs the result of the query and dies 5- while 2,3,4 are executed, data can pass on the original TCP masqueraded

connection
6- data keeps on passing
7- the TCP connection is closed and the masq timeout expires 8- a new masq_log process starts
9- the masq_log process logs "connection closed" and dies

(no IDENT query this time since it's useless) If the number of new connections per second is very high a lot of processes may be spawned on the masquerader, possibly causing a __crash_of_the_masquerader__!.
This can be a very dangerous DoS (though the luser causing that will be logged). To prevent abuse, I put a limit to the number of processes spawned from kmasqlogd (look at the code). This also means that some TCP connections won't be logged on heavy load (though you will know who is flooding your masquerader). If this ever happens, it will be logged via syslog (usually this is logged in /var/log/messages). In any case, weigh the power of your masquerader with the flow of your network. If you are a kernel hacker, you could certainly write a better masqlogd than mine.

The IDENT queries generate some more traffic on the internal network (but not very much, IMHO).

** Authors:

Roberto Zunino <zunrob@users.sourceforge.net>