Hi everybody, I got a weird problem here and would like to hear the opinion of other security-minded people, regarding this effect. First, excuse my bad english, i hope you will be able to understand anyway. This is (part of) my current (strictly private) setup: INTERNET | --------------- | Masq-Router | --------------- | ------------- --------- |-----| FTP-Server | | Sniffer |--| | 192.168.1.5 | --------- | ------------- -------- | Router | -------- | ------------------ | FTP + NFS-Server | | 192.168.2.3 | ------------------ The masq-router (Kernel 2.2.19 - SuSEfirewall 4.6) is configured to forward FTP-connections to the outer FTP with the following rule: FW_FORWARD_MASQ_TCP="0/0,192.168.1.5,21" The outer FTPs public FTP directory is mounted ro from the inner FTP/NFS, this is done like this: On the inner NFS: #/etc/exports /usr/local/ftp/pub 192.168.1.5(ro,insecure,all_squash) On the outer FTP: # mount -t nfs 192.168.2.3:/usr/local/ftp/pub /usr/local/ftp/pub I tried to connect to the FTP from an internet-client, login to the FTP seemed to work, directory listings seemed to work, but when i tried to get a file sized 1MB, the transmission startet (always with about 4kb/s - min 7kb should be possible), but then the transmission seemed to get slower and slower until it stand still. For further investigation, i set the variable FW_LOG_ACCEPT_ALL to "yes" and made another attempt, to see whats going wrong. But then, surprise, surprise, the transmission startet with correct speed at 7kb/s, and the file was transmitted nearly perfect. I verified this behaviour many times, it definitely depends on the changed logging parameter. I made a ipchains -L -n > with_logging ipchains -L -n > without_logging diff with_logging without_logging but the result seemed to be ok, only difference - as expected - where the differing ----l- flags. But I know, if the system is compromised by a LKM/rootkit, i can´t rely on that data anyway. To take a closer look on whats going on, i put a sniffer in the choke-net to work out what´s happening there. To my surprise, the error didn´t occur on the FTP-Client to FTP connection, instead the inner NFS to outer FTP connection seems to be faulty. Here´s what happens (NFS-specific) with logging: 192.168.1.5.2344796719 > 192.168.2.3.2049: 108 getattr fh Unknown/1 (DF) (ttl 64, id 0) 192.168.2.3.2049 > 192.168.1.5.2344796719: reply ok 96 getattr REG 100644 ids 0/0 sz 1232295 (ttl 63, id 31871) 192.168.1.5.2361573935 > 192.168.2.3.2049: 108 getattr fh Unknown/1 (DF) (ttl 64, id 0) 192.168.2.3.2049 > 192.168.1.5.2361573935: reply ok 96 getattr REG 100644 ids 0/0 sz 1232295 (ttl 63, id 31873) No probs, after this NFS-packets, FTP-transmission is nearly perfect. Now here´s what happens, when FW_LOG_ACCEPT_ALL is set to "no": First 4 packets are same as above, then errors occur: 192.168.1.5.918733359 > 192.168.2.3.2049: 124 lookup fh Unknown/1 [|nfs] (DF) (ttl 64, id 0) 192.168.2.3.2049 > 192.168.1.5.918733359: reply ok 28 lookup ERROR: No such file or directory (ttl 63, id 31781) After this, the FTP-transmission seems to get "confused" (sorry, don´t know better - yet) and stucks completely (i can send the logs of both transmissions, if wanted) I don´t get it. How can a logging-parameter on the masq-router take influence to the NFS-FTP-transmission? My first idea would be something like a LKM/rootkit, that came over my network in code-red-style (I´m a lazy patcher, my beginners-config isn´t secure anyway, i guess - but as this is my private net, i dont bother to much ;). This maybe could somehow make the net work properly if extensive logging is enabled - could this be possible, or am i way to paranoid? Or could there be some sort of misconfiguration, that could lead to the weird effect described above, i wouldn´t know, where to search... :o\ So, maybe someone here knows about those symptoms and can help me out a bit. TIA, Matthias