Hallo suse-security, every time a client (running NT4) issues the command "net time \\<linuxserver>" the Linuxserver (SuSE8.2) reports an error in /var/log/messages Aug 6 16:09:16 <linuxserver> kernel: martian source 192.168.80.1 from 10.68.26.117, on dev eth2 Aug 6 16:09:16 <linuxserver> kernel: ll header: 00:50:04:45:33:f5:00:01:02:e2:39:4e:08:00 In this example 10.68.26.117 is the client ip adress. eth0 is the internal interface to the clients, eth1 external eth2 another internal network to which the client has no direct access 192.168.80.1 is <linuxserver>´s ip adress on eth2 The time synchronization attempt times out after some time on client side. If I stop SuSEfirewall2 'net time' works without problems. What has to be configured in SuSEfirwall2 to get 'net time' working? -- Mit freundlichen Grüßen, André Sänger
* André Sänger wrote on Wed, Aug 06, 2003 at 16:33 +0200:
Aug 6 16:09:16 <linuxserver> kernel: martian source 192.168.80.1 from 10.68.26.117, on dev eth2 Aug 6 16:09:16 <linuxserver> kernel: ll header: 00:50:04:45:33:f5:00:01:02:e2:39:4e:08:00
In this example 10.68.26.117 is the client ip adress.
eth0 is the internal interface to the clients, eth1 external eth2 another internal network to which the client has no direct access
192.168.80.1 is <linuxserver>´s ip adress on eth2
So it seems strange why the client connects to that address - seems to be the wrong one. Are you sure that there is really no routing for the client via eth2? Did you verified with tcpdump or similar tools?
The time synchronization attempt times out after some time on client side.
If I stop SuSEfirewall2 'net time' works without problems.
What has to be configured in SuSEfirwall2 to get 'net time' working?
There are situations, where rp_filter does not work. You can turn it off. SuSEfirwall2 turns it on, but you can change that. Somewhere there should be an echo "1" > ..../rp_filter, try to change the 1 to 0 like echo "0" > .../rp_filter and restart SuSEfirwall2. Sorry, I cannot help much with SuSEfirwall2, maybe there is a better way to do that - but should solve you problem for the time you're looking for best solution :-) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hello Steffen, Wednesday, August 06, 2003, 11:51:12 PM, you wrote:
So it seems strange why the client connects to that address - seems to be the wrong one. Are you sure that there is really no routing for the client via eth2? Did you verified with tcpdump or similar tools?
According to the routing table the client can reach the 192.168.80.0 net via its default gateway 10.68.26.1, which has an ip adress in the 192.168.80.0 net. But why should it try to connect to 192.168.80.1 in the first place? Samba is configured with "time server = yes" and to use only eth0 and eth2 interfaces. If I read the logmessage it seems like a packet comes from the client with a source ip adress of 192.168.80.1? How´s that possible? Or do I misunderstand the log message?
There are situations, where rp_filter does not work. You can turn it off. SuSEfirwall2 turns it on, but you can change that. Somewhere there should be an echo "1" > ..../rp_filter, try to change the 1 to 0 like echo "0" > .../rp_filter and restart SuSEfirwall2.
Sorry, I cannot help much with SuSEfirwall2, maybe there is a better way to do that - but should solve you problem for the time you're looking for best solution :-)
How can I put that command in the SuSEfirewall2 script so that I don´t have to issue it manuelly after SuSEfirewall2 is restarted? -- Best regards, André mailto:Andre.Saenger@gmx.de
* André Sänger wrote on Thu, Aug 07, 2003 at 09:24 +0200:
Wednesday, August 06, 2003, 11:51:12 PM, you wrote:
So it seems strange why the client connects to that address - seems to be the wrong one. Are you sure that there is really no routing for the client via eth2? Did you verified with tcpdump or similar tools?
According to the routing table the client can reach the 192.168.80.0 net via its default gateway 10.68.26.1, which has an ip adress in the 192.168.80.0 net. But why should it try to connect to 192.168.80.1 in the first place?
Well, I do not understand windows naming resolve algo. There is some broadcast and whatever based name caching that often is used instead of DNS. Well, it is difficult to understand I think. Keep in mind that the Windows system isn't designed for clear concepted networks but to allow some kind of plug'n'play. Stations in a LAN can "browse" each other without any central service as DNS or WINs. An NT router does some netbios name proxying and other magic things. Often, it is difficult to trace on the system. Yesterday we had some problem, when the DHCP server sent "sub.domain.com domain.com" as DNS seachlist. Windows happily requests "server.sub.domain.com domain.com" from the DNS server, or even "server.sub.domain.com;domain.com", not noticing that ";" isn't a valid character. Don't rely on the error messages you get from nslookup or such. Use tcpdump to see what windows is trying in reality :-) Maybe it do sent such a packet to the server and it gets droppend by rp_filter.
If I read the logmessage it seems like a packet comes from the client with a source ip adress of 192.168.80.1? How´s that possible? Or do I misunderstand the log message?
trace it! There are so many things that could have been happend ;) But yes, I think you misunderstood the message. martian source 192.168.80.1 from 10.68.26.117, on dev eth2 Aug 6 (AFIAK) this means: on eth2 arrived a packet for 192.168.80.1 (sent by 10.68.26.117). Such packet should arrvie on eth0 in your case (because it is more "near" to that network). Well, on multi-homed boxes this won't work well, because "routing to itself" produces this "martian" source - an attack isn't the case here I think :-). It is correct to reach a multihomed box by any of it's IPs from any of "allowed" interfaces (it has to "virtually" route to itself, like eth2 -> eth0 routing, but this is OK and working). So rp_filter isn't working here.
Sorry, I cannot help much with SuSEfirwall2, maybe there is a better way to do that - but should solve you problem for the time you're looking for best solution :-)
How can I put that command in the SuSEfirewall2 script so that I don´t have to issue it manuelly after SuSEfirewall2 is restarted?
Patch it! I have no copy of SuSEfirewall2 around here, so I just write from memory :-) As start, try $ cd /etc/rc.d/ $ grep "rp_filter" SuSEfi* Expect something like echo "1" > /proc/sys/net/ipv4/conf/all/rp_filter If eth0 and eth2 are internal (somewhat trusted) devices, you may wish to protect eth1 only, because if on eth1 arrives a packet for 192.168.80.1, this indicates a spoof or something (because it is from outside, and RFC1918 should not be routed by internet!). Here rp_filter may be a good idea (in some cases). So you may wish to have instead (simply make a BACKUP and the edit the file found by the grep command, search the position, comment out the original line and add): echo "0" > /proc/sys/net/ipv4/conf/all/rp_filter echo "1" > /proc/sys/net/ipv4/conf/eth1/rp_filter (untested). You can issues those commands (as root) on any shell for testing (but of course not reboot-persistent). In case it works, change the SuSEscript, document your changes as you'll have to reply them on next version/update :-) diff+patch are your friends ( $ diff -u SuSEfirewall2.dist SuSEfirewall2 > SuSEfirewall_rp_eth1_only.patch (check the patch file if it looks reasonable) if SuSEfirewall2 is replaced, re-apply your changes: $ patch < SuSEfirewall_rp_eth1_only.patch or something like this. Well, we're getting OT :-) oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.
Hello Steffen, Thursday, August 07, 2003, 11:50:37 AM, you wrote:
(AFIAK) this means: on eth2 arrived a packet for 192.168.80.1 (sent by 10.68.26.117). Such packet should arrvie on eth0 in your case (because it is more "near" to that network). Well, on multi-homed boxes this won't work well, because "routing to itself" produces this "martian" source - an attack isn't the case here I think :-). It is correct to reach a multihomed box by any of it's IPs from any of "allowed" interfaces (it has to "virtually" route to itself, like eth2 -> eth0 routing, but this is OK and working). So rp_filter isn't working here.
Thank you very much for the explanation, now I understand. echo "0" >> /proc/sys/net/ipv4/conf/all/rp_filter echo "1" >> /proc/sys/net/ipv4/conf/eth1/rp_filter I edited /sbin/SuSEfirewall2 Works fine (until the next update I guess) :-) -- Best regards, André mailto:Andre.Saenger@gmx.de
participants (2)
-
André Sänger
-
Steffen Dettmer