September 2003 - openSUSE Security - openSUSE Mailing Lists

RES: [suse-security] packets still seem to be dropped not routed despite rp_filter=0
by Valter Rehn 11 Sep '03

11 Sep '03

Just my 2 cents... IPSEC uses UDP port 500 AND ( PROTOCOL 50 OR PROTOCOL 51 ) []s Valter Rehn -----Mensagem original----- De: J J [mailto:c_peto@hotmail.com] Enviada em: Thursday, September 11, 2003 17:26 Para: Philipp.Rusch(a)rusch-edv.de Cc: suse-security(a)suse.com Assunto: Re: [suse-security] packets still seem to be dropped not routed despite rp_filter=0 Are you sure? According to the /etc/protocols file there is no protocol 500 - the IP protocols go no higher than 255. That makes sense really seeing as the protocol field in IPV4 is only 8 bits long! (http://www.ietf.org/rfc/rfc0791.txt) This is an extract from my current /etc/sysconfig/SuSEfirewall2... FW_QUICKMODE="no" FW_DEV_EXT="ppp0" FW_DEV_INT="eth0 ipsec0" FW_DEV_DMZ="" FW_ROUTE="no" FW_MASQUERADE="no" FW_MASQ_DEV="$FW_DEV_EXT" FW_MASQ_NETS="" FW_PROTECT_FROM_INTERNAL="no" FW_AUTOPROTECT_SERVICES="yes" FW_SERVICES_EXT_TCP="smtp ssh" FW_SERVICES_EXT_UDP="isakmp" FW_SERVICES_EXT_IP="esp ah" Anyway I made a small amount of extra progress, at least in the way of ruling out problems. I decided to try connecting from the "jellybean" gateway itself to the "Bookman" LAN by creating adjusted entries in ipsec.conf and succeeded. Basically it worked right out of the box, I just removed the leftsubnet declarations on both sides - now the gateway can ping all the servers on the "Bookman" LAN and vice versa. This isn't the long term solution but does at least show that the boxes will talk to each other and send ipsec traffic correctly. Plus I toyed with the latest rdesktop and maybe I can persuade people to use that instead of Win 2k boxes with MSTSC client anyway! :) (ha!) But I'm still not sure why the SuSE 8.2 box is misbehaving and dropping my packets. Do you have any idea how I switch on debugging on the kernel routing code?? >From: Philipp Rusch <Philipp.Rusch(a)rusch-edv.de> >To: J J <c_peto(a)hotmail.com> >CC: "suse-security(a)suse.com" <suse-security(a)suse.com> >Subject: Re: [suse-security] packets still seem to be dropped not routed >despite rp_filter=0 >Date: Thu, 11 Sep 2003 20:05:34 +0200 > >Hi Carl, >You are victim of a very common misunderstanding concerning IPSEC >and the setup of the firewall .... ;-) > >Not PORT 500 is needed to setup the tunnel (after negotiation of SA has >been >done), but PROTOCOL (!!!) 500, which you have to put in the firewall >to be allowed through interface ipsec0 (add this to FW_DEV_EXT). >Since I do not use SuSE firewall anymore (there are better scripts for >iptables) >I am not a 100% sure, but I remember that you have to set this in >SuSEfirewall2-file as variable FW_SERVICES_EXT_IP = 500. > >HTH, Philipp > >J J schrieb: > > > I'm trying to set up a VPN from "home" LAN to "bookman" LAN. > > I've set up Freeswan successfully and it *appears* to be doing it's job >but > > still packets aren't getting through. I suspect that routing isn't >working > > for > > some reason and I've reached the limit of my security knowledge. > > > > Can anyone help? > > > > The set up is this: > > "Bookman" LAN is subnet 192.168.0.0/24 with Ipsec gateway "flanger" on > > IP address 192.168.0.127. "Bookman" LAN connects to internet via ADSL > > ("Vigor") > > router that has "Ipsec passthru". In terms of configuration this means >that > > I've switched off the "Vigor" router's built-in Ipsec processing and set >UDP > > on port 500 to forward direct to "flanger" on 192.168.0.127. The >router's > > software is set to recognize this combination as a signal to switch on >Ipsec > > passthru so that protocols 50 and 51 are also forwarded to the same >internal > > box. > > > > (We've successfully set up and used an SA to a "Fortigate" router based >on > > this > > through to another company "SGPM" and we use that VPN for production > > purposes. > > It's fast and stable and has impressed management!) > > > > "Home" LAN is subnet 192.168.10.0/24 with Ipsec gateway "jellybean" on > > external > > IP address 217.... (hidden for privacy - if that's me being silly I'm >happy > > to > > reveal it!). The "home" gateway has an ethernet card on 192.168.10.1 >with a > > hub connected to that and (at present) one test laptop connected to the >hub > > running Win 2k. > > > > Ipsec gateway on "Bookman" LAN ("flanger") is running SuSE 7.2 and our > > gateway > > here ("jellybean") is running SuSE 8.2 (these seem to be Freeswan 1.91 >and > > 1.99 > > respectively). > > > > The idea is to have a VPN connecting PCs and laptops on the "home" LAN >to > > the > > servers on the "Bookman" LAN in production. > > > > Progress so far: > > With a small amount of tinkering I managed to get the two pluto daemons >to > > talk > > and agree an SA but was unable to ping servers on the "Bookman" LAN from > > either our gateway or our test laptop. After help from Rob Maurizzi on >this > > mailing list I managed to get KLIPS debugging and found that, rather > > boringly, > > the gateway was unable to ping Bookman servers because packets were >being > > seen > > by KLIPS as coming from the WAN address of the router (217....) and so >had > > no > > eroute and were dropped - this was clearly visible in the stats on >ifconfig, > > which helped. > > > > Problem: > > However this didn't explain why the laptop couldn't reach the Bookman >LAN. > > My > > initial thought was that routing needed to be switched on. The box is > > configured as a firewall with a SQUID proxy so the "home" LAN can access >the > > www. SuSEfirewall2 is running to prevent malicious attacks but allow >Ipsec > > traffic. Config is basically - allow external TCP service "ssh" plus > > external > > UDP service "isakmp" plus external IP protocols "ah" and "esp", do not > > protect > > from internal network, reject rather than drop packets (temporary for >debug) > > and log all dropped packets (temporary for debug). > > > > When I ping from the Win 2k laptop to a Bookman server I see nothing in >the > > firewall logs, nothing in KLIPS debug. I see packets arriving on eth0 >but > > nothing on ipsec0 or ppp0 (the WAN interface). > > > > echo "1" > /proc/sys/net/ipv4/ip_forward makes no difference > > > > cat /proc/sys/net/ipv4/conf/*/forwarding gives "1"s for all devices and > > worse > > > > cat /proc/sys/net/ipv4/conf/*/rp_filter gives "0"s for all devices! > > > > Outputs:jellybean:~ # rcipsec start > > ipsec_setup: Starting FreeS/WAN IPsec 1.99... > > ipsec_setup: ipsec > > ipsec_setup: > > done > > jellybean:~ # ipsec auto --up jellybean-bookman > > 104 "jellybean-bookman" #1: STATE_MAIN_I1: initiate > > 106 "jellybean-bookman" #1: STATE_MAIN_I2: sent MI2, expecting MR2 > > 108 "jellybean-bookman" #1: STATE_MAIN_I3: sent MI3, expecting MR3 > > 004 "jellybean-bookman" #1: STATE_MAIN_I4: ISAKMP SA established > > 112 "jellybean-bookman" #2: STATE_QUICK_I1: initiate > > 004 "jellybean-bookman" #2: STATE_QUICK_I2: sent QI2, IPsec SA >established > > jellybean:~ # ip route ls > > 213.123.101.97 dev ppp0 proto kernel scope link src 217.24.128.146 > > 213.123.101.97 dev ipsec0 proto kernel scope link src 217.24.128.146 > > 192.168.0.0/24 via 213.123.101.97 dev ipsec0 > > 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.1 > > default via 213.123.101.97 dev ppp0 > > jellybean:~ # ip rule ls > > 0: from all lookup local > > 32766: from all lookup main > > 32767: from all lookup default > > jellybean:~ # route -n > > Kernel IP routing table > > Destination Gateway Genmask Flags Metric Ref Use > > Iface > > 213.123.101.97 0.0.0.0 255.255.255.255 UH 0 0 0 >ppp0 > > 213.123.101.97 0.0.0.0 255.255.255.255 UH 0 0 0 > > ipsec0 > > 192.168.0.0 213.123.101.97 255.255.255.0 UG 0 0 0 > > ipsec0 > > 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 >eth0 > > 0.0.0.0 213.123.101.97 0.0.0.0 UG 0 0 0 >ppp0 > > jellybean:~ # > > jellybean:~ # ifconfig > > eth0 Link encap:Ethernet HWaddr 00:40:95:30:5C:79 > > inet addr:192.168.10.1 Bcast:192.168.10.255 >Mask:255.255.255.0 > > UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:53 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:100 > > RX bytes:0 (0.0 b) TX bytes:8692 (8.4 Kb) > > Interrupt:5 Base address:0xc000 > > > > ipsec0 Link encap:IPIP Tunnel HWaddr > > inet addr:217.24.128.146 Mask:255.255.255.255 > > UP RUNNING NOARP MTU:16260 Metric:1 > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:10 > > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > > > lo Link encap:Local Loopback > > inet addr:127.0.0.1 Mask:255.0.0.0 > > UP LOOPBACK RUNNING MTU:16436 Metric:1 > > RX packets:32 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:32 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:0 > > RX bytes:2056 (2.0 Kb) TX bytes:2056 (2.0 Kb) > > > > ppp0 Link encap:Point-to-Point Protocol > > inet addr:217.24.128.146 P-t-P:213.123.101.97 > > Mask:255.255.255.255 > > UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 > > RX packets:886 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:957 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:3 > > RX bytes:375562 (366.7 Kb) TX bytes:107243 (104.7 Kb) > > > > jellybean:~ # > > > > (OK so I capitulated - u can see my wan address - hey, I trust >SuSEfirewall2 > > !! :) ) > > (Note eth0 stats aren't accurate at the moment, i just created this >quickly > > before > > rushing to a meeting.) > > > > Does anyone know what happened to my packets?!? > > > > Regards, > > Carl > > > > _________________________________________________________________ > > Tired of 56k? Get a FREE BT Broadband connection > > http://www.msn.co.uk/specials/btbroadband > > > > -- > > Check the headers for your unsubscription address > > For additional commands, e-mail: suse-security-help(a)suse.com > > Security-related bug reports go to security(a)suse.de, not here > _________________________________________________________________ Hotmail messages direct to your mobile phone http://www.msn.co.uk/msnmobile -- Check the headers for your unsubscription address For additional commands, e-mail: suse-security-help(a)suse.com Security-related bug reports go to security(a)suse.de, not here

1 0

packets still seem to be dropped not routed despite rp_filter=0
by J J 11 Sep '03

11 Sep '03

I'm trying to set up a VPN from "home" LAN to "bookman" LAN. I've set up Freeswan successfully and it *appears* to be doing it's job but still packets aren't getting through. I suspect that routing isn't working for some reason and I've reached the limit of my security knowledge. Can anyone help? The set up is this: "Bookman" LAN is subnet 192.168.0.0/24 with Ipsec gateway "flanger" on IP address 192.168.0.127. "Bookman" LAN connects to internet via ADSL ("Vigor") router that has "Ipsec passthru". In terms of configuration this means that I've switched off the "Vigor" router's built-in Ipsec processing and set UDP on port 500 to forward direct to "flanger" on 192.168.0.127. The router's software is set to recognize this combination as a signal to switch on Ipsec passthru so that protocols 50 and 51 are also forwarded to the same internal box. (We've successfully set up and used an SA to a "Fortigate" router based on this through to another company "SGPM" and we use that VPN for production purposes. It's fast and stable and has impressed management!) "Home" LAN is subnet 192.168.10.0/24 with Ipsec gateway "jellybean" on external IP address 217.... (hidden for privacy - if that's me being silly I'm happy to reveal it!). The "home" gateway has an ethernet card on 192.168.10.1 with a hub connected to that and (at present) one test laptop connected to the hub running Win 2k. Ipsec gateway on "Bookman" LAN ("flanger") is running SuSE 7.2 and our gateway here ("jellybean") is running SuSE 8.2 (these seem to be Freeswan 1.91 and 1.99 respectively). The idea is to have a VPN connecting PCs and laptops on the "home" LAN to the servers on the "Bookman" LAN in production. Progress so far: With a small amount of tinkering I managed to get the two pluto daemons to talk and agree an SA but was unable to ping servers on the "Bookman" LAN from either our gateway or our test laptop. After help from Rob Maurizzi on this mailing list I managed to get KLIPS debugging and found that, rather boringly, the gateway was unable to ping Bookman servers because packets were being seen by KLIPS as coming from the WAN address of the router (217....) and so had no eroute and were dropped - this was clearly visible in the stats on ifconfig, which helped. Problem: However this didn't explain why the laptop couldn't reach the Bookman LAN. My initial thought was that routing needed to be switched on. The box is configured as a firewall with a SQUID proxy so the "home" LAN can access the www. SuSEfirewall2 is running to prevent malicious attacks but allow Ipsec traffic. Config is basically - allow external TCP service "ssh" plus external UDP service "isakmp" plus external IP protocols "ah" and "esp", do not protect from internal network, reject rather than drop packets (temporary for debug) and log all dropped packets (temporary for debug). When I ping from the Win 2k laptop to a Bookman server I see nothing in the firewall logs, nothing in KLIPS debug. I see packets arriving on eth0 but nothing on ipsec0 or ppp0 (the WAN interface). echo "1" > /proc/sys/net/ipv4/ip_forward makes no difference cat /proc/sys/net/ipv4/conf/*/forwarding gives "1"s for all devices and worse cat /proc/sys/net/ipv4/conf/*/rp_filter gives "0"s for all devices! Outputs:jellybean:~ # rcipsec start ipsec_setup: Starting FreeS/WAN IPsec 1.99... ipsec_setup: ipsec ipsec_setup: done jellybean:~ # ipsec auto --up jellybean-bookman 104 "jellybean-bookman" #1: STATE_MAIN_I1: initiate 106 "jellybean-bookman" #1: STATE_MAIN_I2: sent MI2, expecting MR2 108 "jellybean-bookman" #1: STATE_MAIN_I3: sent MI3, expecting MR3 004 "jellybean-bookman" #1: STATE_MAIN_I4: ISAKMP SA established 112 "jellybean-bookman" #2: STATE_QUICK_I1: initiate 004 "jellybean-bookman" #2: STATE_QUICK_I2: sent QI2, IPsec SA established jellybean:~ # ip route ls 213.123.101.97 dev ppp0 proto kernel scope link src 217.24.128.146 213.123.101.97 dev ipsec0 proto kernel scope link src 217.24.128.146 192.168.0.0/24 via 213.123.101.97 dev ipsec0 192.168.10.0/24 dev eth0 proto kernel scope link src 192.168.10.1 default via 213.123.101.97 dev ppp0 jellybean:~ # ip rule ls 0: from all lookup local 32766: from all lookup main 32767: from all lookup default jellybean:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 213.123.101.97 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 213.123.101.97 0.0.0.0 255.255.255.255 UH 0 0 0 ipsec0 192.168.0.0 213.123.101.97 255.255.255.0 UG 0 0 0 ipsec0 192.168.10.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0 0.0.0.0 213.123.101.97 0.0.0.0 UG 0 0 0 ppp0 jellybean:~ # jellybean:~ # ifconfig eth0 Link encap:Ethernet HWaddr 00:40:95:30:5C:79 inet addr:192.168.10.1 Bcast:192.168.10.255 Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:53 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:100 RX bytes:0 (0.0 b) TX bytes:8692 (8.4 Kb) Interrupt:5 Base address:0xc000 ipsec0 Link encap:IPIP Tunnel HWaddr inet addr:217.24.128.146 Mask:255.255.255.255 UP RUNNING NOARP MTU:16260 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:10 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:32 errors:0 dropped:0 overruns:0 frame:0 TX packets:32 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:2056 (2.0 Kb) TX bytes:2056 (2.0 Kb) ppp0 Link encap:Point-to-Point Protocol inet addr:217.24.128.146 P-t-P:213.123.101.97 Mask:255.255.255.255 UP POINTOPOINT RUNNING NOARP MULTICAST MTU:1500 Metric:1 RX packets:886 errors:0 dropped:0 overruns:0 frame:0 TX packets:957 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:3 RX bytes:375562 (366.7 Kb) TX bytes:107243 (104.7 Kb) jellybean:~ # (OK so I capitulated - u can see my wan address - hey, I trust SuSEfirewall2 !! :) ) (Note eth0 stats aren't accurate at the moment, i just created this quickly before rushing to a meeting.) Does anyone know what happened to my packets?!? Regards, Carl _________________________________________________________________ Tired of 56k? Get a FREE BT Broadband connection http://www.msn.co.uk/specials/btbroadband

2 1

Cipe starts before firewalldaemon on SuSe-Live CD
by Jan Frederik Pielhau 11 Sep '03

11 Sep '03

Hi there. We've got a SuSe Linux Firewall on CD 2 and use CIPE to connect a branch office. Because the remote network is on a dialup-line, we use the cipe's ip-up script to insert some iptables rules for the network connection between the LANs. Our Problem is that the CIPE Daemon starts before the FAS Daemon and so the rules defined in the CIPE's ip-up Script become overwritten. On a "normal" Linux machine we renamed the link of the CIPE Daemon in /etc/init.d/rcX.d/@SXXcipe to let cipe start after the Firewallscript. How can i then change the order in which the services start on that SuSe Firewall On CD?? I'm not that into cronjobs, would it be possible to create a job that runs after the Firewallscript has been run successful? Thanks for any comments. Regards, Jan F. Pielhau Systemintegration / Helpdesk inuIT Lyrenstr. 13 D-44866 Bochum Tel.: +49 (2327) 30 92 8 - 0 Fax: +49 (2327) 30 92 8 - 33 eMail: J.Pielhau(a)inuIT.de Web: http://www.inuIT.de

3 2

SuSE Security Announcement: pine (SuSE-SA:2003:037)
by Thomas Biege 11 Sep '03

11 Sep '03

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: pine Announcement-ID: SuSE-SA:2003:037 Date: Thursday, Sep 11th 2003 08:40 MEST Affected products: 7.2, 7.3, 8.0, 8.1, 8.2 SuSE Linux Database Server, SuSE eMail Server III, 3.1 SuSE Linux Enterprise Server 7, 8 SuSE Linux Firewall on CD/Admin host SuSE Firewall on CD 2 SuSE Linux Connectivity Server SuSE Linux Office Server SuSE Linux Desktop 1.0 Vulnerability Type: remote code execution Severity (1-10): 5 SuSE default package: yes Cross References: CAN-2003-0720 CAN-2003-0721 Content of this advisory: 1) security vulnerability resolved: An integer overflow and a buffer overflow in the pine mail reader. problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds: - gkrellmd - gdm2 - kernel/PPC64 - whois - xfs - postgresql 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion, solution, upgrade information The well known and widely used mail client pine is vulnerable to a buffer overflow. The vulnerability exists in the code processing 'message/external-body' type messages. It allows remote attackers to execute arbitrary commands as the user running pine. Additionally an integer overflow in the MIME header parsing code has been fixed. Since there is no workaround, an update is strongly recommended for pine users. Please download the update package for your distribution and verify its integrity by the methods listed in section 3) of this announcement. Then, install the package using the command "rpm -Fhv file.rpm" to apply the update. Our maintenance customers are being notified individually. The packages are being offered to install from the maintenance web. Intel i386 Platform: SuSE-8.2: ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/pine-4.53-109.i586.rpm c3d94808af56ac9fcc77bec85733bc47 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/i586/pine-4.53-109.i586.pat… fff680da5c283d2d50a44419976881a8 source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.2/rpm/src/pine-4.53-109.src.rpm 327935d468b4cd7794dde00168a901c3 SuSE-8.1: ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/pine-4.44-283.i586.rpm 63bc3f723537b18a274404c9b30ea784 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/i586/pine-4.44-283.i586.pat… 1d4711753488a274c8cf168b24c91acf source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.1/rpm/src/pine-4.44-283.src.rpm 9617c79c854c2b800df476aa515ae351 SuSE-8.0: ftp://ftp.suse.com/pub/suse/i386/update/8.0/n1/pine-4.44-281.i386.rpm edea9fbbf85a9f922d2b2aa8bf4a14e8 patch rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/n1/pine-4.44-281.i386.patch.rpm 18c95a919fb8767f3cff10218ce6c08c source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/pine-4.44-281.src.rpm 6bf6b39feed23892faceaa78fd13b751 SuSE-7.3: ftp://ftp.suse.com/pub/suse/i386/update/7.3/n1/pine-4.33-280.i386.rpm 65d24983aa99d276e75ccd557eee557b source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/pine-4.33-280.src.rpm b0ecee1170d1fdec3b22e98d0941071a SuSE-7.2: ftp://ftp.suse.com/pub/suse/i386/update/7.2/n1/pine-4.33-279.i386.rpm 574ae6efcf81a53a26d5d19b763f96ab source rpm(s): ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/pine-4.33-279.src.rpm 14fbade46db5dbc9c9893cf507d57e4a Sparc Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/sparc/update/7.3/n1/pine-4.33-101.sparc.rpm 4e90502bfc4ca5b49c20f8a10cb9d473 source rpm(s): ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/pine-4.33-101.src.rpm c600432ad453999aa329b836490842df PPC Power PC Platform: SuSE-7.3: ftp://ftp.suse.com/pub/suse/ppc/update/7.3/n1/pine-4.33-153.ppc.rpm 0c4323f70d9cc8b95d35f4356351990c source rpm(s): ftp://ftp.suse.com/pub/suse/ppc/update/7.3/zq1/pine-4.33-153.src.rpm 6f6987ad3110ff3bf0bd5edb08ee935a ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - gkrellmd The gkrellmd, part of the gkrellm package, contains a buffer overflow. Only the gkrellm package shipped with SL 8.2 is vulnerable. New update packages will be available on our FTP servers soon. - gdm2 The Gnome Display Manager (GDM) contains a bug which allows local attackers to view any file on the system. Fixed packages will be available on our FTP servers soon. - kernel/PPC64 A locally exploitable vulnerability in the kernel for SLES 8 PowerPC based IBM iSeries Systems allows an attacker to overwrite arbitrary kernel memory. Update packages are being published on our maintenance web, and our customers are being notified individually. - whois A buffer overflow exists in the whois command. New packages will be available on our FTP servers soon. - xfs The X font server (xfs) contains various integer overflows which could allow remote attackers to execute arbitrary commands. SuSE products do not enable xfs by default, but the update packages should be installed as soon as they are available on our FTP servers. - postgresql The SQL database server postgresql of version 7.3.x prior 7.3.4 is vulnerable to buffer overflow attacks. New packages will be available soon. ______________________________________________________________________________ 3) standard appendix: authenticity verification, additional information - Package authenticity verification: SuSE update packages are available on many mirror ftp servers all over the world. While this service is being considered valuable and important to the free and open source software community, many users wish to be sure about the origin of the package and its content before installing the package. There are two verification methods that can be used independently from each other to prove the authenticity of a downloaded file or rpm package: 1) md5sums as provided in the (cryptographically signed) announcement. 2) using the internal gpg signatures of the rpm package. 1) execute the command md5sum <name-of-the-file.rpm> after you downloaded the file from a SuSE ftp server or its mirrors. Then, compare the resulting md5sum with the one that is listed in the announcement. Since the announcement containing the checksums is cryptographically signed (usually using the key security(a)suse.de), the checksums show proof of the authenticity of the package. We disrecommend to subscribe to security lists which cause the email message containing the announcement to be modified so that the signature does not match after transport through the mailing list software. Downsides: You must be able to verify the authenticity of the announcement in the first place. If RPM packages are being rebuilt and a new version of a package is published on the ftp server, all md5 sums for the files are useless. 2) rpm package signatures provide an easy way to verify the authenticity of an rpm package. Use the command rpm -v --checksig <file.rpm> to verify the signature of the package, where <file.rpm> is the filename of the rpm package that you have downloaded. Of course, package authenticity verification can only target an un-installed rpm package file. Prerequisites: a) gpg is installed b) The package is signed using a certain key. The public part of this key must be installed by the gpg program in the directory ~/.gnupg/ under the user's home directory who performs the signature verification (usually root). You can import the key that is used by SuSE in rpm packages for SuSE Linux by saving this announcement to a file ("announcement.txt") and running the command (do "su -" to be root): gpg --batch; gpg < announcement.txt | gpg --import SuSE Linux distributions version 7.1 and thereafter install the key "build(a)suse.de" upon installation or upgrade, provided that the package gpg is installed. The file containing the public key is placed at the top-level directory of the first CD (pubring.gpg) and at ftp://ftp.suse.com/pub/suse/pubring.gpg-build.suse.de . - SuSE runs two security mailing lists to which any interested party may subscribe: suse-security(a)suse.com - general/linux/SuSE security discussion. All SuSE security announcements are sent to this list. To subscribe, send an email to <suse-security-subscribe(a)suse.com>. suse-security-announce(a)suse.com - SuSE's announce-only mailing list. Only SuSE's security announcements are sent to this list. To subscribe, send an email to <suse-security-announce-subscribe(a)suse.com>. For general information or the frequently asked questions (faq) send mail to: <suse-security-info(a)suse.com> or <suse-security-faq(a)suse.com> respectively. ===================================================================== SuSE's security contact is <security(a)suse.com> or <security(a)suse.de>. The <security(a)suse.de> public key is listed below. ===================================================================== ______________________________________________________________________________ The information in this advisory may be distributed or reproduced, provided that the advisory is not modified in any way. In particular, it is desired that the clear-text signature shows proof of the authenticity of the text. SuSE Linux AG makes no warranties of any kind whatsoever with respect to the information contained in this security advisory. Type Bits/KeyID Date User ID pub 2048R/3D25D3D9 1999-03-06 SuSE Security Team <security(a)suse.de> pub 1024D/9C800ACA 2000-10-19 SuSE Package Signing Key <build(a)suse.de> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org mQGiBDnu9IERBACT8Y35+2vv4MGVKiLEMOl9GdST6MCkYS3yEKeueNWc+z/0Kvff 4JctBsgs47tjmiI9sl0eHjm3gTR8rItXMN6sJEUHWzDP+Y0PFPboMvKx0FXl/A0d M+HFrruCgBlWt6FA+okRySQiliuI5phwqkXefl9AhkwR8xocQSVCFxcwvwCglVcO QliHu8jwRQHxlRE0tkwQQI0D+wfQwKdvhDplxHJ5nf7U8c/yE/vdvpN6lF0tmFrK XBUX+K7u4ifrZlQvj/81M4INjtXreqDiJtr99Rs6xa0ScZqITuZC4CWxJa9GynBE D3+D2t1V/f8l0smsuYoFOF7Ib49IkTdbtwAThlZp8bEhELBeGaPdNCcmfZ66rKUd G5sRA/9ovnc1krSQF2+sqB9/o7w5/q2qiyzwOSTnkjtBUVKn4zLUOf6aeBAoV6NM CC3Kj9aZHfA+ND0ehPaVGJgjaVNFhPi4x0e7BULdvgOoAqajLfvkURHAeSsxXIoE myW/xC1sBbDkDUIBSx5oej73XCZgnj/inphRqGpsb+1nKFvF+rQoU3VTRSBQYWNr YWdlIFNpZ25pbmcgS2V5IDxidWlsZEBzdXNlLmRlPohcBBMRAgAcBQI57vSBBQkD wmcABAsKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyl8sAJ98BgD40zw0GHJHIf6d NfnwI2PAsgCgjH1+PnYEl7TFjtZsqhezX7vZvYCIRgQQEQIABgUCOnBeUgAKCRCe QOMQAAqrpNzOAKCL512FZvv4VZx94TpbA9lxyoAejACeOO1HIbActAevk5MUBhNe LZa/qM2JARUDBRA6cGBvd7LmAD0l09kBATWnB/9An5vfiUUE1VQnt+T/EYklES3t XXaJJp9pHMa4fzFa8jPVtv5UBHGee3XoUNDVwM2OgSEISZxbzdXGnqIlcT08TzBU D9i579uifklLsnr35SJDZ6ram51/CWOnnaVhUzneOA9gTPSr+/fT3WeVnwJiQCQ3 0kNLWVXWATMnsnT486eAOlT6UNBPYQLpUprF5Yryk23pQUPAgJENDEqeU6iIO9Ot 1ZPtB0lniw+/xCi13D360o1tZDYOp0hHHJN3D3EN8C1yPqZd5CvvznYvB6bWBIpW cRgdn2DUVMmpU661jwqGlRz1F84JG/xe4jGuzgpJt9IXSzyohEJB6XG5+D0BiF0E ExECAB0FAjxqqTQFCQoAgrMFCwcKAwQDFQMCAxYCAQIXgAAKCRCoTtronIAKyp1f AJ9dR7saz2KPNwD3U+fy/0BDKXrYGACfbJ8fQcJqCBQxeHvt9yMPDVq0B0W5Ag0E Oe70khAIAISR0E3ozF/la+oNaRwxHLrCet30NgnxRROYhPaJB/Tu1FQokn2/Qld/ HZnh3TwhBIw1FqrhWBJ7491iAjLR9uPbdWJrn+A7t8kSkPaF3Z/6kyc5a8fas44h t5h+6HMBzoFCMAq2aBHQRFRNp9Mz1ZvoXXcI1lk1l8OqcUM/ovXbDfPcXsUVeTPT tGzcAi2jVl9hl3iwJKkyv/RLmcusdsi8YunbvWGFAF5GaagYQo7YlF6UaBQnYJTM 523AMgpPQtsKm9o/w9WdgXkgWhgkhZEeqUS3m5xNey1nLu9iMvq9M/iXnGz4sg6Q 2Y+GqZ+yAvNWjRRou3zSE7Bzg28MI4sAAwYH/2D71Xc5HPDgu87WnBFgmp8MpSr8 QnSs0wwPg3xEullGEocolSb2c0ctuSyeVnCttJMzkukL9TqyF4s/6XRstWirSWaw JxRLKH6Zjo/FaKsshYKf8gBkAaddvpl3pO0gmUYbqmpQ3xDEYlhCeieXS5MkockQ 1sj2xYdB1xO0ExzfiCiscUKjUFy+mdzUsUutafuZ+gbHog1CN/ccZCkxcBa5IFCH ORrNjq9pYWlrxsEn6ApsG7JJbM2besW1PkdEoxak74z1senh36m5jQvVjA3U4xq1 wwylxadmmJaJHzeiLfb7G1ZRjZTsB7fyYxqDzMVul6o9BSwO/1XsIAnV1uuITAQY EQIADAUCOe70kgUJA8JnAAAKCRCoTtronIAKyksiAJsFB3/77SkH3JlYOGrEe1Ol 0JdGwACeKTttgeVPFB+iGJdiwQlxasOfuXyITAQYEQIADAUCPGqpWQUJCgCCxwAK CRCoTtronIAKyofBAKCSZM2UFyta/fe9WgITK9I5hbxxtQCfX+0ar2CZmSknn3co SPihn1+OBNyZAQ0DNuEtBAAAAQgAoCRcd7SVZEFcumffyEwfLTcXQjhKzOahzxpo omuF+HIyU4AGq+SU8sTZ/1SsjhdzzrSAfv1lETACA+3SmLr5KV40Us1w0UC64cwt A46xowVq1vMlH2Lib+V/qr3b1hE67nMHjysECVx9Ob4gFuKNoR2eqnAaJvjnAT8J /LoUC20EdCHUqn6v+M9t/WZgC+WNR8cq69uDy3YQhDP/nIan6fm2uf2kSV9A7ZxE GrwsWl/WX5Q/sQqMWaU6r4az98X3z90/cN+eJJ3vwtA+rm+nxEvyev+jaLuOQBDf ebh/XA4FZ35xmi+spdiVeJH4F/ubaGlmj7+wDOF3suYAPSXT2QAFEbQlU3VTRSBT ZWN1cml0eSBUZWFtIDxzZWN1cml0eUBzdXNlLmRlPokBFQMFEDbhLUfkWLKHsco8 RQEBVw4H/1vIdiOLX/7hdzYaG9crQVIk3QwaB5eBbjvLEMvuCZHiY2COUg5QdmPQ 8SlWNZ6k4nu1BLcv2g/pymPUWP9fG4tuSnlUJDrWGm3nhyhAC9iudP2u1YQY37Gb B6NPVaZiYMnEb4QYFcqv5c/r2ghSXUTYk7etd6SW6WCOpEqizhx1cqDKNZnsI/1X 11pFcO2N7rc6byDBJ1T+cK+F1Ehan9XBt/shryJmv04nli5CXQMEbiqYYMOu8iaA 8AWRgXPCWqhyGhcVD3LRhUJXjUOdH4ZiHCXaoF3zVPxpeGKEQY8iBrDeDyB3wHmj qY9WCX6cmogGQRgYG6yJqDalLqrDOdmJARUDBRA24S0Ed7LmAD0l09kBAW04B/4p WH3f1vQn3i6/+SmDjGzUu2GWGq6Fsdwo2hVM2ym6CILeow/K9JfhdwGvY8LRxWRL hn09j2IJ9P7H1Yz3qDf10AX6V7YILHtchKT1dcngCkTLmDgC4rs1iAAl3f089sRG BafGPGKv2DQjHfR1LfRtbf0P7c09Tkej1MP8HtQMW9hPkBYeXcwbCjdrVGFOzqx+ AvvJDdT6a+oyRMTFlvmZ83UV5pgoyimgjhWnM1V4bFBYjPrtWMkdXJSUXbR6Q7Pi RZWCzGRzwbaxqpl3rK/YTCphOLwEMB27B4/fcqtBzgoMOiaZA0M5fFoo54KgRIh0 zinsSx2OrWgvSiLEXXYKiEYEEBECAAYFAjseYcMACgkQnkDjEAAKq6ROVACgjhDM /3KM+iFjs5QXsnd4oFPOnbkAnjYGa1J3em+bmV2aiCdYXdOuGn4ZiQCVAwUQN7c7 whaQN/7O/JIVAQEB+QP/cYblSAmPXxSFiaHWB+MiUNw8B6ozBLK0QcMQ2YcL6+Vl D+nSZP20+Ja2nfiKjnibCv5ss83yXoHkYk2Rsa8foz6Y7tHwuPiccvqnIC/c9Cvz dbIsdxpfsi0qWPfvX/jLMpXqqnPjdIZErgxpwujas1n9016PuXA8K3MJwVjCqSKI RgQQEQIABgUCOhpCpAAKCRDHUqoysN/3gCt7AJ9adNQMbmA1iSYcbhtgvx9ByLPI DgCfZ5Wj+f7cnYpFZI6GkAyyczG09sE= =LRKC - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iQEVAwUBP2AXoney5gA9JdPZAQEpmggAiKfQGjFnHwmI6UQfK/6rmI1HTlIq8pyF XO+WOoMjgtczzxrMExlHDGVFgMvm6I9aIvdTDEv1+eTMmbVEm1cAXznLAZh3ZBZU asXrbJPZ8oYCLS2n5/pE7GMyZbrwZ4qx7dfdZCwPuG4y3xedLdkrREqzhFLV9Bms JC12tTF3Oz8XvrcnW4dLVqzTPtjEljwAO7iG7+G1tLjWqbaT3Oaa/iXfugMDeknK gfRa5PXLPVEPo/6N2UKBUayGp63pD4oAvhDeIogLs+tu0FNZ/49zUMqnzPw74Pv8 VRpQYvwk4/1Y7CSbDM9I4XAcxnzXB9RBuUpq/6EGwK3+lqCHO+7+MA== =qffc -----END PGP SIGNATURE----- Bye, Thomas -- Thomas Biege <thomas(a)suse.de>, SuSE Linux AG, Security Support & Auditing "lynx -source http://www.suse.de/~thomas/contact/thomas.asc | pgp -fka" Key fingerprint = 51 AD B9 C7 34 FC F2 54 01 4A 1C D4 66 64 09 83 -- ... bring the pieces back together, we discover communication... - Maynard James Keenan

1 0

setup of openldap2 to replace nis
by Paul Elliott 10 Sep '03

10 Sep '03

What is the proper way to setup an openldap2 server to replace NIS? server and clients SuSE 8.2? I have seen the openldap2 CLIENT setup under YAST, but don't see anything for server. Is there a way you don't have to have a password stored in a file? Thank You. -- Paul Elliott 1(512)837-1096 pelliott(a)io.com PMB 181, 11900 Metric Blvd Suite J http://www.io.com/~pelliott/pme/ Austin TX 78758-3117

4 3

HELP ! YOU-Update on SuSE 8.1 firewall did something eval to my kernel
by Philipp Rusch 10 Sep '03

10 Sep '03

Hi all, yesterday I updated my SuSE 8.1 system with the recommended (auto) updates through YOU. I noticed that there was a kernel update in the list, but I didn't mind. Today, when under stress, my firewall gives hundres of messages like: Sep 10 11:53:27 proxy1 kernel: NET: 39 messages suppressed. Sep 10 11:53:27 proxy1 kernel: Neighbour table overflow. Sep 10 11:53:27 proxy1 kernel: neigh_alloc(): neighbour table flood for neigh_table c0329840 Sep 10 11:53:32 proxy1 last message repeated 61 times Sep 10 11:53:32 proxy1 kernel: NET: 59 messages suppressed. Sep 10 11:53:32 proxy1 kernel: Neighbour table overflow. Sep 10 11:53:32 proxy1 kernel: neigh_alloc(): neighbour table flood for neigh_table c0329840 Sep 10 11:53:38 proxy1 last message repeated 60 times Sep 10 11:53:38 proxy1 kernel: NET: 59 messages suppressed. Sep 10 11:53:38 proxy1 kernel: Neighbour table overflow. Sep 10 11:53:38 proxy1 kernel: neigh_alloc(): neighbour table flood for neigh_table c0329840 Sep 10 11:53:43 proxy1 last message repeated 59 times Sep 10 11:53:43 proxy1 kernel: NET: 59 messages suppressed. Sep 10 11:53:43 proxy1 kernel: Neighbour table overflow. Sep 10 11:53:43 proxy1 kernel: neigh_alloc(): neighbour table flood for neigh_table c0329840 Sep 10 11:53:49 proxy1 last message repeated 59 times Sep 10 11:53:49 proxy1 kernel: NET: 59 messages suppressed. Sep 10 11:53:49 proxy1 kernel: Neighbour table overflow. Sep 10 11:53:49 proxy1 kernel: neigh_alloc(): neighbour table flood for neigh_table c0329840 Sep 10 11:53:52 proxy1 last message repeated 11 times Sep 10 11:53:52 proxy1 kernel: NET: 11 messages suppressed. Sep 10 11:53:52 proxy1 kernel: Neighbour table overflow. Sep 10 11:53:55 proxy1 kernel: neigh_alloc(): neighbour table flood for neigh_table c0329840 Sep 10 11:53:59 proxy1 kernel: neigh_alloc(): neighbour table flood for neigh_table c0329840 Sep 10 11:53:59 proxy1 kernel: NET: 1 messages suppressed. Sep 10 11:53:59 proxy1 kernel: Neighbour table overflow. Sep 10 11:54:03 proxy1 kernel: neigh_alloc(): neighbour table flood for neigh_table c0329840 Sep 10 11:54:03 proxy1 kernel: Neighbour table overflow. Sep 10 11:54:03 proxy1 kernel: neigh_alloc(): neighbour table flood for neigh_table c0329840 Sep 10 11:54:08 proxy1 last message repeated 3 times Sep 10 11:54:08 proxy1 kernel: NET: 3 messages suppressed. Sep 10 11:54:08 proxy1 kernel: Neighbour table overflow. I did NOT change a thing besides those updates and rebooted. The firewall is done through iptables and configured with the "shorewall" script which have been in use for over a year now without any problems. Now the firewall simply stops after a certain while. Unfotunately I cannot log in because the SSH process is crashing as well and I am not on site, but I managed to get the logs via email. Any hint / help is appreciated very much. Thank you in advance, Philipp Rusch

3 5

Re: [suse-security] KLIPS Debugging no longer supported in Suse 8.2 ????
by J J 10 Sep '03

10 Sep '03

Thanks Rob, Funnily enough I'd independantly hit on this as the way of fixing it after I posted my message! I was still hopeful that I could avoid compiling the kernel: in the old days (when I started with Linux on a Slackware distro. in 1995) I used to do it all the time but these days with SuSE's kernel being so good I've gotten lazy! Anywayz it gave me a chance to trim my kernel modules down to the ones that I'll *ever* use (sadly I'm unlikely to ever have an FDDI or ATM card in my machine :) ) and cut compile time down by about 90%! Finally also I got to set the debug and NAT traversal options on - yipee!! I still think SuSE were silly for switching off even the possibility of debug. It's all controlled by ipsec klipsdebug when compiled in anyway! I did it slightly differently - documentation was "pants" and didn't tell men what target to make + make without a target just gave an obscure error - so I scanned the Makefile and make a couple of the targets I saw "kmodule" and "klink". After that I was able to make xconfig in the /usr/src/linux tree and set all the IPSEC config variables and make my shiny new ipsec.o with debugging kernel module! For some reason I lost my nvidia module so I had to reconfigure X so I think it's now not using 3D ?? Couldn't find any setting in xconfig or menuconfig for this and couldn't see a km_* package for it either! Now all I have to do is figure out why the ?%&! my VPN isn't working... ;) Regards, Carl >From: r.maurizzi(a)digitalpha.it >To: suse-security(a)lists.suse.com >Subject: Re: [suse-security] KLIPS Debugging no longer supported in Suse >8.2 ???? >Date: Tue, 9 Sep 2003 11:52:28 +0200 > > > > > > > It seems that KLIPS debugging is no longer possible since > > SuSE 8.2. > >NAT-Traversal patch isn't enabled, too. > > > What's the point behind this change?? > >Probably, the fact that in 2.4.22 crypto routine were added in the kernel, >and IPSEC changed a lot. > > > I've tried installing the km_freeswan package and compiling > > stuff there but just get compile errors. > >You should: >- install the kernel sources for your running kernel >- copy the config for your running kernet to the source dir (usually, go in >/usr/src/linux, and do zcat /proc/config.gz > .config) >- "make menuconfig" and check the options. Save the config and do "make >dep" >- go in /usr/src/kernel_modules/zz_freeswan >- type "make insert", this inserts the IPSEC patches in the kernel tree >- go back in /usr/src/linux, do "make menuconfig" and go in the Network >Option to check the IPSEC settings >- recompile the kernel :-) > >Beware: doing so will trash all other SuSE kernel modules that are added >independently from the main kernel sources... check that you do not use any >module that have its sources in a km_*.rpm packages, and eventually compile >it. > >Ciao, > Rob! > >P.S. >If someone has a better way to do some of the things II explained here, >comments and corrections are VERY welcome :-) > > >-- >Check the headers for your unsubscription address >For additional commands, e-mail: suse-security-help(a)suse.com >Security-related bug reports go to security(a)suse.de, not here > _________________________________________________________________ Get Hotmail on your mobile phone http://www.msn.co.uk/msnmobile

1 0

Re: [suse-security] Unwanted routing between subnets
by Marc Samendinger 10 Sep '03

10 Sep '03

> -----Original Message----- > From: Marc Samendinger > Sent: Wednesday, September 10, 2003 11:26 AM > > > > Thanks, that helped. > > > > I tried this before, but only on the INPUT chain. Too busy to > > see the obvious > > :-] > > > > However, adding a ruleset for the INPUT chain is still > > necessary to protect > > the interfaces on the router itself, as these are not handled > > by the FORWARD > > chain. > > since the INPUT chain is only responsible for packets > destinated to local services on your Router there should > be no packet that matches > > > iptables -A INPUT -i eth0 -s 192.168.0.0/16 -d 172.16.0.0/16 -j DROP > > iptables -A INPUT -i eth0 -s 172.16.0.0/16 -d > 192.168.0.0/16 -j DROP Sorry for this misleading statement, please forget this post. I should have reread your post > if I really unterstood you right and you wanted to block > the packets like that. > > this behaviour changed between ipchains and iptables. > > > Bye, > > Holger again I'm sorry for my misleading post and the unnecessary noise marc

1 0

Unwanted routing between subnets
by Holger Schletz 10 Sep '03

10 Sep '03

Hi, I'm running a router on SuSE 8.2 which connects 2 local subnets to the internet. The subnets run over the same NIC with virtual interfaces: eth0, subnet 192.168.0.0/255.255.0.0 (call it subnet A) eth0:1, subnet 172.16.0.0/255.255.0.0 (call it subnet B) (Yes, this is a mess, but fixing up this naturally grown network topology might induce even more trouble.) eth1 connects to the internet. The setup works; both subnets have internet access. However, subnet A is still accessible from subnet B and vice versa. This is not what I want; instead I want the two subnets to be invisible to each other. There is no route from A to B or from B to A specified in the /etc/sysconfig/network directory (is there another place to look at?). Maybe this problem comes from the virtual interface stuff? I tried to set up routing rules with the "unreachable", "prohibit" or "blackhole" option, but I did't find useful documentation on usage of these options and it did not work as expected. I also tried some custom rules for SuSEfirewall2, but no success either. So what routing options and/or iptables rules do I have to use? Thanks, Holger

6 8

Re: [suse-security] Unwanted routing between subnets
by Marc Samendinger 10 Sep '03

10 Sep '03

> -----Original Message----- > From: Holger Schletz [mailto:h.schletz@dokom.net] > Sent: Wednesday, September 10, 2003 11:04 AM > > Thanks, that helped. > > I tried this before, but only on the INPUT chain. Too busy to > see the obvious > :-] > > However, adding a ruleset for the INPUT chain is still > necessary to protect > the interfaces on the router itself, as these are not handled > by the FORWARD > chain. since the INPUT chain is only responsible for packets destinated to local services on your Router there should be no packet that matches > iptables -A INPUT -i eth0 -s 192.168.0.0/16 -d 172.16.0.0/16 -j DROP > iptables -A INPUT -i eth0 -s 172.16.0.0/16 -d 192.168.0.0/16 -j DROP if I really unterstood you right and you wanted to block the packets like that. this behaviour changed between ipchains and iptables. > Bye, > Holger marc

1 0