April 2002 - openSUSE Security - openSUSE Mailing Lists

how to keep nimda and code red from filling apache logs
by Mathias Homann 25 Sep '03

25 Sep '03

Hi all, here's a bit of a step-by-step description on how to keep nimda and codered from filling your apache logs. Parts used: - SuSE 7.2 Professional - SuSEfirewall2 - iptables 1.2.3 - linux kernel 2.4.13-pre5 steps: 1. install kernel sources for a kernel >> 2.4.9, running 2.4.13- pre5 here, works fine so far 2. get the sources for iptables 1.2.3 from http://netfilter.samba.org 3. unpack sources somewhere 4. export KERNEL_DIR=$(where you put the kernel tree) 5. cd into unpacked iptables sources, there's a subdirectory named patch-o-matic there 6. apply wanted patches by running ./runme $(name.of.patch)patch for this here You'll want the string patch You can also apply other patches, like the irc-conntrack patch 7. now there's a little bug in this patch... here's a diff: --- linux/net/ipv4/netfilter/ipt_string.c~ Sun Oct 21 00:16:29 2001 +++ linux/net/ipv4/netfilter/ipt_string.c Sun Oct 21 16:54:45 2001 @@ -62,7 +62,7 @@ sk = skip[haystack[right_end - i]]; sh = shift[i]; - right_end = max(int, right_end - i + sk, right_end + sh); + right_end = max(right_end - i + sk, right_end + sh); } return NULL; 8. now, make config/menuconfig/xconfig... as usual. You can import your running kernel's config first. 9. enable the experimental stuff 10. go to networking options->netfilter, there's an option there to enable string matching; set that to M 11. compile and install kernel as usual; remember to uncomment the export INSTALL_PATH=/boot in the main makefile. 12. now build a rpm file for the new iptables stuff by installing the source rpm which comes with suse, then edit the spec file, put the iptables source in /usr/src/packages/SOURCE and rebuild. 13. now there are some small changes to the firewall config files. a) uncomment the last line in /etc/rc.config.d/firewall2.rc.config: FW_CUSTOMRULES="/etc/rc.config.d/firewall2-custom.rc.config" b) edit that file, I got the following stuff in mine: for forbidden_string in root.exe cmd.exe .ida; do iptables -I input_ext -p tcp --dport http -m string \ --string $forbidden_string -m state \ --state ESTABLISHED -j REJECT --reject-with tcp-reset done put that in the last supfunction defined in the custom rc file. c) change the FW_LOG setting in firewall2.rc.config from reading -log-level warning to -log-level kernel.warning 14. last: some small changes to /sbin/SuSEfirewall2 search in the script for the parts where the modules are loaded and unloaded; be sure to add ipt_string (and the other new modules you created by patching the kernel and enabling them in make config) to the modules loading/unloading code there. 15. reboot 16. if you try now to access (from outside, of course) one of the nimda or codered URLS, all you get is a 'connection reset by peer', and the request doesn't show in apache log files. btw, no guarantees, and the usual YMMV :) bye [L]

7 7

suse samba server
by jonathan 23 Jan '03

23 Jan '03

Hello I have basically a suse samba server setup. Eth0 is for the internet connection (cable). Eth1 is my internal network. I use eth1 for my samba server. When i have the shares/ drive letters mapped, whatever, Ill goto access them and that computer will just lockup or timeout for about 1 minute, then it will resume operation normally. I have approx. 5 comptuers on the suse server, and they all do this from windows xp to windows 98se. I am using set up addresses of 192.168.0.x, where is greater than 2. My question is have or is there something Ive setup wrong to cause this pause to occur. ? Its becomming very annoying..and frustrating. Im using kernel 2.4.18-64GB-SMP with a dual processor setup. If anyone has any ideas please let me know. Every package installed is orginal versions from the suse install cdroms. (no updates done). Anything come to mind. btw, ive replaced the switch, with a new netgear one, and all the networks at startech ST100 Realtek 8139 chipsets on 100Tx. Anyone... !

4 5

Urgggggg!!! SuSEFirewall2 is getting on my nerves!!!!!
by Chris Bek 08 Jan '03

08 Jan '03

Hi there SuSErs... Well I must be doing something really wrong because everything that I do with SuSEFirewall2 is just not working! I have a small network with 5 PCs (all Win9X) and a Linux box (Currently SuSE 7.3) acting as a server. The server is a DHCP server and a Samba server for the entire network. So far everything is working perfect!!! Users log on the network, logon script executes etc.... Then a new task came up: let's input the internet into the network. Configured a 56Kbps modem on the server with YAST. Manged to get my account setup and running. Made a test connection and netscape works great on the server as well as e-mail (pop3). I tried configuring SuSEfirewall to manage all incoming requests from the PCs of the network. The firewall warned me about masquerading etc. so I downloaded the latest version of SuSEfirewall2 from the internet and installed it. Since I only need direct masquerading to be done (no proxies are currently working on the net) I made all the necessary changes as outlined in the examples supplied with the software. Since I needed to have Samba to keep working on the network, I opened (among others) 139 port for samba to work. Double checked all the changes that I have made and run rcSuSEfirewall2 to see what happens. Strange enough when wvdial executes it tells me that DNS is not functioning properly since www.suse.com cannot be found (or something like that please forgive me I am away from the Linux station now). Further on, when I open mIRC or other like programs (winmx etc) from a station, I look at the activity of IPtraf (I check this to see what happens) and I see no connections being created whatsoever.... mIRC prompts me that there was an error trying to find the host.... I have made no changes to the Win9X PCs. Is there something that I am forgeting to do?? I undestand that it is impossible for all of you to react to this since I have no output of the SuSEfirewall.conf file being published to this message.... I understand. Can someone please send me their configuration file so I can see what you have done, on a system that currently is working fine?? In addition, is there something that I have to do regarding route or routing?? What about the Win9X PCs?? Is there something that I have to do there?? I thank you so very much for all your help is advance!!!! I am killing myself trying to figure this one out for about 2 weeks now and managed nothing more than thin air!!!!! Chris

11 10

SSH Authentication
by Joao Reis 18 Nov '02

18 Nov '02

Hi! I implemented a ssh conection from the outside to my intranet. This ssh requires a username and a password. In terms of security what is more secure: require authentication (username and password) or having the public key of each user that connects to our intranet in the authorized public key lists (in this case there is no need for username and password)? In the second case there is no need of authentication and only the users wich have the public keys in the list are allowed to enter in my intranet. This second solution is a good solution or that brings other security problems ? Thanks. -- Farewell. "Keep your friends close, but your enemies closer." "Do or do not. There is no try" - Yoda João Reis -------------------------------------------------------

2 1

Spamming ...
by Martin Schichl 27 May '02

27 May '02

Morning! Since some days I get Returned Mails from unknown mail-users which seems that someone is spamming from our machine. But when i analyze the header of the original mail i fin a line: >> Received: from 210.97.42.1 (HELO scc.co.at) (210.97.42.1) << Although the IP of scc.co.at is 193.81.182.39 The IP 210.97.42.1 will change permanently when reading other similar mails. My questions: 1) Is it possible that someone beoke into our machine and sent this mail directly over scc.co.at 2) What can I do to stop those spammers ... ThanX Martin The header file of the original Message --------------------------------------------------------------- X-Track: 92154: 2 X-Rocket-Spam: 210.97.42.1 X-YahooFilteredBulk: 210.97.42.1 Return-Path: <rjnr3245i37(a)scc.co.at> Received: from 210.97.42.1 (HELO scc.co.at) (210.97.42.1) by mta514.mail.yahoo.com with SMTP; 28 Feb 2002 15:32:36 -0800 (PST) Reply-To: <rjnr3245i37(a)scc.co.at> Message-ID: <001a07e37abc$2777d8d5$6ce83be4@lplwmr> From: <rjnr3245i37(a)scc.co.at> To: <doctorbutcher(a)yahoo.com> --------------------------------------------------------------- ----------------------------------------------------------------- Dipl.-Ing. Martin Schichl SC&C Software, Communication & Consulting GmbH & Co KEG Grottenhofstr. 3, A-8053 Graz Tel. +43/(0)316/265-205, Fax +43/(0)316/265-234 mschichl(a)scc.co.at, http://scc.co.at

9 12

Sendmail out-of-box secure enough?
by Pep Serrano 20 May '02

20 May '02

Hello list, Here is a question perhaps a little naive :-) I am not sendmail expert at all and I do wonder... Is sendmail in SuSE Linux out-of-thebox secure enough for a with permanent connection to inet? I mean just setting the configuration "Host with permanent network connection" in Yast2... In case it is not (I guess) what minimal config do you propose to run a sendmail to just deliver emails from localhost to inet and to allow receiving only emails for its own domain? Any good recommendations? Cheers Pep Serrano.

13 19

VPN masquerading
by Joost van der Lugt 06 May '02

06 May '02

Hi all, I am trying to set up VPN masquerading, for a Windows box, and just wondered if there was an easy way to do this, using just the firewall.rc.config script, or do both that plus the custom config script have to be used? I have seen the VPN how-to, however just wondered about a how to aply this with SuSE's scripts. Thanks for any suggestions, (PS if there is someone familiar with setting upo VPN on the SuSe box itself, I would be very interested as well..., of course) - Cheers, Joost

4 4

Partitions
by Ricardo Javier Aranibar León 06 May '02

06 May '02

Hi list, I need information about secure partitions, I have HD 40G, I like a web server an mail server. I saw that web master partitions yours disk with var/, boot/, home/, I like to know what directorys create and how I can asing size for this? If someone can help me, I will Thank full Thanks, Ricardo _________________________________________________________________ Envíe y reciba su correo de Hotmail desde el móvil: http://mobile.msn.com

7 9

file creation with a different gid?
by Axel Zindler 05 May '02

05 May '02

Hi, was wondering how to create files with a different gid then the standard group. Suppose one wants to share files with a second (or third and so far) user. They create a common group different from (standard) users, ie. projectx. If both users are now members of projectx and keep the membership of users the files will be written always with the uid of users, ie: -rw-r--r-- 1 axel users 16 Mär 31 22:50 test.txt How is it possible to edit a file and save files in that way to achive the following without doing a chgrp after the file is saved? -rw-r--r-- 1 axel projectx 16 Mär 31 22:50 test.txt

4 3

Need help with iptables: missing .so -- and I can't use DENY or ACCEPT
by JW 03 May '02

03 May '02

Hello, I have been trying for 2 days to get iptables to work. Something is really really wrong. Initially I was trying on a 7.3 install that had been upgraded from 7.2. I thought maybe the software was just messed up so I just finished a clean install of 8.0, yet I am getting exatly the same error messages: bismuth:~ # iptables -A INPUT -p tcp -i eth0 -s 192.168.0.110 -j DENY iptables v1.2.5: Couldn't load target `DENY':/usr/lib/iptables/libipt_DENY.so: cannot open shared object file: No such file or directory Try `iptables -h' or 'iptables --help' for more information. bismuth:~ # iptables -A INPUT -p tcp -i eth0 -s 192.168.0.110 -j deny iptables v1.2.5: Couldn't load target `deny':/usr/lib/iptables/libipt_deny.so: cannot open shared object file: No such file or directory Try `iptables -h' or 'iptables --help' for more information. bismuth:~ # iptables -A INPUT -s 65.166.138.61 -j DENY iptables v1.2.5: Couldn't load target `DENY':/usr/lib/iptables/libipt_DENY.so: cannot open shared object file: No such file or directory Try `iptables -h' or 'iptables --help' for more information. bismuth:~ # I've tried dozens ot test commands too, any of the that use DENY or ACCEPT fail. Even more interesting: According to the Linuxnewbie.org tutorial, both of the following commands should prevent 192.168.0.110 from being able to access the machine running iptables: iptables -A INPUT -s 192.168.0.110 -j DENY iptables -A INPUT -s 192.168.0.110 -j DROP Yet, the exact _opposite_ happens: the local machine ends up not being able to to anything to the remote host, yet the remote host is still able to log in via telnet just fine. Disgusting. Thinking that maybe I was just misunderstanding something, I tried -d in place of -s and that does nothing at all, both hosts are able to log into each other. Something is badly amiss. Please, can anyone explain this? I get similar errors when I try to use ACCEPT. All I'm trying to do is restrict port 5000 (I'm using 5001 as a test) so that only 1 IP can access it. Eventually that IP will be 65.166.138.61 but I'm using 192.168.0.110 as a test. Please, someone strighten me out. And before you say RTFM, I've been reading it for 2 days. I'm going precisly by the book, and it's not working. Something is just plain wrong. Also please don't ask me to use SuSE Firewall2, I've tired it quite a few times and I'm never able to get it to work. Thanks in advance. -- ---------------------------------------------------- Jonathan Wilson System Administrator Clickpatrol.com Cedar Creek Software http://www.cedarcreeksoftware.com

4 6

Re: [Users] IPSEC and SuSEFirewall2 v2.1
by Robert Klein 01 May '02

01 May '02

> I have modified the SuSEfirewall2 Script (Version 2.1) for better > support of FreeSWAN/IPSEC. Nice idea. > Any comments/suggestions/feedback? Two questions: Is it possible to use more than one IPSEC device? E.g. FW_DEV_IPSEC="ipsec0 ipsec1" and: Can I use more than one remote network? E.g. FW_IPSEC_REMOTENET="192.168.3.0/24 192.168.4.0/24" Robert

3 2

Re: [suse-security] iptables blocking telnet 25 ?
by spam 30 Apr '02

30 Apr '02

Hi! from comp.mail.sendmail: ---snip--- #!/bin/sh COUNTRIES="kr cn tw" for i in $COUNTRIES; do lynx --dump 'http://www.apnic.net/apnic-bin/'\ 'ipv4-by-country.pl?country='$i \ |grep ]APNIC|awk '{print $2;}' done ---snip--- you run the script and save the result to file /etc/rogue-state-ips then you add this to your firewall script (depending on your os version) ---snip--- # blocking countries for i in `cat /etc/rogue-state-ips | grep /`; do $IPTABLES -A input -i eth0 -p tcp --dport 25 -j DENY -s $i done ---snip---

1 0

Infiltration possible?
by Pierre Bernhardt 30 Apr '02

30 Apr '02

Hi, I've got following messages in my firewalllog: Apr 30 01:53:26 starflake kernel: IN=eth0 OUT= MAC=00:e0:4c:90:79:54:00:50:fc:21:9a:82:08:00 SRC=62.176.78.125 DST=193.174.11.198 LEN=78 TOS=0x00 PREC=0x00 TTL=8 ID=2103 PROTO=UDP SPT=3268 DPT=137 LEN=58 Apr 30 01:53:26 starflake kernel: klogd 1.4.1, ---------- state change ---------- Apr 30 01:53:26 starflake kernel: Inspecting /boot/System.map-2.4.18-64GB-SMP Apr 30 01:53:26 starflake kernel: Loaded 13537 symbols from /boot/System.map-2.4.18-64GB-SMP. Apr 30 01:53:26 starflake kernel: Symbols match kernel version 2.4.18. Apr 30 01:53:26 starflake kernel: Loaded 548 symbols from 32 modules. Port 137 above is loged and filtered by my iptablerules. Some of ports on my computer are accessible from internet, e.g. 22 for ssh. My rules logs only forbidden acces. I dont understand the kernelmessages about the Inspecting of the Kernel-Modules at the same time as the forbidden port-access ist logged. What is your opinion? More Infos? Here are my iptables loaded for my interface on my computer: At the moment i have only running dhcp-server, sun-rpc, ssh, squid and cups on 631. Smaba, popd and imapd are not installed at the moment. Chain INPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp dpt:ssh ACCEPT tcp -- <my-net/my-nm> anywhere tcp dpt:smtp ACCEPT tcp -- <my-net/my-nm> anywhere tcp dpt:pop3 ACCEPT tcp -- <my-net/my-nm> anywhere tcp dpt:imap ACCEPT tcp -- <my-net/my-nm> anywhere tcp dpt:http-alt ACCEPT udp -- <my-net/my-nm> anywhere udp dpt:netbios-ns ACCEPT udp -- <my-net/my-nm> anywhere udp dpt:netbios-dgm ACCEPT tcp -- <my-net/my-nm> anywhere tcp dpt:netbios-ssn ACCEPT udp -- <nameserver> anywhere udp spt:domain ACCEPT tcp -- <nameserver> anywhere tcp spt:domain ACCEPT udp -- <my-net/my-nm> anywhere udp spt:bootpc dpt:bootps ACCEPT icmp -- anywhere anywhere icmp echo-reply ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT icmp -- anywhere anywhere icmp destination-unreachable ACCEPT icmp -- anywhere anywhere icmp source-quench ACCEPT icmp -- anywhere anywhere icmp time-exceeded ACCEPT icmp -- anywhere anywhere icmp parameter-problem REJECT tcp -- anywhere anywhere tcp dpt:ident reject-with tcp-reset LOG all -- anywhere anywhere LOG level warning DROP all -- anywhere anywhere Chain FORWARD (policy DROP) target prot opt source destination Chain OUTPUT (policy DROP) target prot opt source destination ACCEPT all -- anywhere anywhere state RELATED,ESTABLISHED ACCEPT tcp -- anywhere anywhere tcp spts:1024:65535 dpt:http ACCEPT tcp -- anywhere anywhere tcp spts:1024:65535 dpt:ssh ACCEPT udp -- anywhere anywhere udp spts:1024:65535 dpt:domain ACCEPT tcp -- anywhere anywhere tcp spts:1024:65535 dpt:domain ACCEPT udp -- anywhere <my-net/my-nm> spt:bootps dpt:bootpc ACCEPT icmp -- anywhere anywhere icmp echo-request ACCEPT icmp -- anywhere anywhere icmp echo-reply ACCEPT icmp -- anywhere anywhere icmp destination-unreachable LOG all -- anywhere anywhere LOG level warning REJECT tcp -- anywhere anywhere reject-with tcp-reset REJECT udp -- anywhere anywhere reject-with icmp-port-unreachable DROP all -- anywhere anywhere

1 0

FLASH !
by Corneliu MUSAT 30 Apr '02

30 Apr '02

http://pagitta.com/flash/flashmenu.html ;o) Tzupiiiic ! -- Cornel. tel.:4092743604

2 1

SuSE Security Announcement: sudo (SuSE-SA:2002:014)
by Sebastian Krahmer 30 Apr '02

30 Apr '02

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: sudo Announcement-ID: SuSE-SA:2002:014 Date: Tue Apr 30 16:00:00 MEST 2002 Affected products: 6.4, 7.0, 7.1, 7.2, 7.3, 8.0, SuSE Firewall Adminhost VPN, SuSE Linux Admin-CD for Firewall, SuSE Linux Enterprise Server, SuSE Linux Connectivity Server Vulnerability Type: local privilege escalation Severity (1-10): 6 SuSE default package: yes Other affected systems: All systems with sudo installed. Content of this advisory: 1) security vulnerability resolved: Heap overflow in sudo. problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion, solution, upgrade information The sudo program allows local users to execute certain configured commands with root priviledges. Sudo contains a heap overflow in its prompt assembling function. The input used to create the password prompt is user controlled and not properly length-checked before copied to certain heap locations. This allows local attackers to overflow the heap of sudo, thus executing arbitrary commands as root. We would like to thank GlobalInterSec for finding and researching this vulnerability. As a temporary workaround you may remove the setuid bit from sudo by issuing the following command as root: "chmod -s /usr/bin/sudo". 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. i386 Intel Platform: SuSE-8.0 ftp://ftp.suse.com/pub/suse/i386/update/8.0/ap1/sudo-1.6.5p2-79.i386.rpm b54f68ff4b32f9d920f2f1ff887d1ddc source rpm: ftp://ftp.suse.com/pub/suse/i386/update/8.0/zq1/sudo-1.6.5p2-79.src.rpm fd1ccf6fe52c6b999c5ed24a2f3a4e65 SuSE-7.3 ftp://ftp.suse.com/pub/suse/i386/update/7.3/ap1/sudo-1.6.3p7-83.i386.rpm 80edbf5caf02c519cf2c01d6ba76d22f source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/sudo-1.6.3p7-83.src.rpm 77962932840740ce5e3dfe57a887592d SuSE-7.2 ftp://ftp.suse.com/pub/suse/i386/update/7.2/ap1/sudo-1.6.3p6-92.i386.rpm 669aa8db134e39f462cb9f2648f6735f source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/sudo-1.6.3p6-92.src.rpm 249b1ef0135dcfede3648982900e277c SuSE-7.1 ftp://ftp.suse.com/pub/suse/i386/update/7.1/ap1/sudo-1.6.3p6-91.i386.rpm 6b3b84f0a4c687e91da179937b87048a source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.1/zq1/sudo-1.6.3p6-91.src.rpm bf59a6b200a0fb130f3528ce23698be0 SuSE-7.0 ftp://ftp.suse.com/pub/suse/i386/update/7.0/ap1/sudo-1.6.3p6-90.i386.rpm 5b67ef9fed383242111953d942c62174 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.0/zq1/sudo-1.6.3p6-90.src.rpm c35f6390b360500b7b649e4590a748cc SuSE-6.4 ftp://ftp.suse.com/pub/suse/i386/update/6.4/ap1/sudo-1.5.9p1-87.i386.rpm 82d98116eccc73c7a0ce03a51e9b5378 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/6.4/zq1/sudo-1.5.9p1-87.src.rpm e75e2608036a963a7339fe4632a2550b Sparc Platform: SuSE-7.3 ftp://ftp.suse.com/pub/suse/sparc/update/7.3/ap1/sudo-1.6.3p7-33.sparc.rpm bd492b6d601ceb30486e3e970a2211a3 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/sudo-1.6.3p7-33.src.rpm d2435d180cdd76647e1f1416e93c2420 SuSE-7.1 ftp://ftp.suse.com/pub/suse/sparc/update/7.1/ap1/sudo-1.6.3p6-37.sparc.rpm bbad36265f93fac25d59f8c26b1ccd52 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.1/zq1/sudo-1.6.3p6-37.src.rpm a328d2eb0fdc816341a68febfeb5a33a SuSE-7.0 ftp://ftp.suse.com/pub/suse/sparc/update/7.0/ap1/sudo-1.6.3p6-36.sparc.rpm 48e7b360b45bae0b3e9e90b3bf945f75 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.0/zq1/sudo-1.6.3p6-36.src.rpm bd8f11a8916340e0d243ae1cc647df26 AXP Alpha Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/axp/update/7.1/ap1/sudo-1.6.3p6-40.alpha.rpm 4505dd58fe309ef0a4515db6a6980ec4 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/7.1/zq1/sudo-1.6.3p6-40.src.rpm 85dfbe40da4d93d54d3c16f6489a7f32 SuSE-7.0 ftp://ftp.suse.com/pub/suse/axp/update/7.0/ap1/sudo-1.6.3p6-40.alpha.rpm b67858459774e5e04c9c22e84d5899ff source rpm: ftp://ftp.suse.com/pub/suse/axp/update/7.0/zq1/sudo-1.6.3p6-40.src.rpm 6d0537068d16785bfdbca936c6395abb PPC Power PC Platform: SuSE-7.3 ftp://ftp.suse.com/pub/suse/ppc/update/7.3/ap1/sudo-1.6.3p7-65.ppc.rpm 1734f578b1fa87c26e51a11e3dc90d18 source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.3/zq1/sudo-1.6.3p7-65.src.rpm ebff8b3e7b86ef9bb69fb13da37903ce SuSE-7.1 ftp://ftp.suse.com/pub/suse/ppc/update/7.1/ap1/sudo-1.6.3p6-45.ppc.rpm 4318adbde184c1c8fff6eb581f02c11e source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.1/zq1/sudo-1.6.3p6-45.src.rpm 771f9e7f6d1fc1ba4df119147e48ddcd SuSE-7.0 ftp://ftp.suse.com/pub/suse/ppc/update/7.0/ap1/sudo-1.6.3p6-45.ppc.rpm 6ae150cfa793f20e49ed751aa686fdea source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.0/zq1/sudo-1.6.3p6-45.src.rpm ede5fedf45ffe6b59c43e082fcef50f4 SuSE-6.4 ftp://ftp.suse.com/pub/suse/ppc/update/6.4/ap1/sudo-1.5.9p1-85.ppc.rpm 0677a205615f631a41ca308be03db7bd source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/6.4/zq1/sudo-1.5.9p1-85.src.rpm 71da4a7d43043b20eefd5e05048616d8 ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - ifup-dhcp could be tricked into executing arbitrary commands as root by DHCP servers handing out illegal values (e.g. containing spaces), because it sourced dhcpcd's info file, where not all variable values are quoted. This problem has been fixed. ______________________________________________________________________________ 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 uninstalled 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 toplevel 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 annoucements 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 cleartext signature shows proof of the authenticity of the text. SuSE GmbH 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: 2.6.3i Charset: noconv iQEVAwUBPM6l7Hey5gA9JdPZAQHErAf/dsMrQSaSHlJHFirNNw9XTsyHFb8uxArI JRgmYIQZValzHicRhxXwRTYRPta3jDx40HH2UqY3VxgWMcHl5fRDne6inYNqlNg5 N70ER3lnHhFyei5er3sX/Rx9sOM/4ONXOk5ZsD/Bdooj0pGJ5hcU9xI1akNxm76k C1B4I8NW7Z9BnH1tiekNYChRv+lG9cw73ElpHGBNJNt0yIpWp3/idjG8/+J9YUod ToRV7owlXwTK/N7DTiYbOVTnRZOGKmRc7WC11xPL19xuIDT8GcmHH590jbCWaYNp DWSoooGuP1w1M1JSS/b+oSIDk4j6/5u9xGmSolDUjjHK/VKjY+dE7w== =lMC8 -----END PGP SIGNATURE----- -- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer(a)suse.de - SuSE Security Team ~

1 0

RE: [suse-security] iptables blocking telnet 25 ?
by Peer Stefan 30 Apr '02

30 Apr '02

Hi, > From: Axel Leitner [mailto:axel.leitner@muenchen-mail.de] > Hello, > > I want to filter, secure 110 with authentication, open 25 > only to relayable > hosts, drop all other trying access 25, if you know the trusted hosts then it's no problem to open port 25 for them. just add the according iptables-rule for each host/subnet ... 'secure 110' is plain pop3, it is unencrypted and therefore to be regarded as insecure. you can activate SSL-encryption via pop3, which is called pop3s (it uses port 995). > domain blocking is not my intend because blacklists have more > disadvantages than the right affect on security. black lists may not increase the security of your system, but they do help to keep spam away from you. and that's what you asked for. > > Axel > > > Why would you use iptables for that? Reasonable MTAs nowadays have > > a feature which honors blacklists. > > If you want to do the blocking yourself you will need some script > > or whatever to collect the IP addresses of spamming hosts - and the > > tricky part will be how you know IN ADVANCE if a host will > spam you ;-) > > By uing blacklists your can increase your chance because a spamming > > host will mabye already make it into the blacklist database bofore > > he attempts to spam you. > > > > Hope I made sense ;-) > > > > Erwin > > > > --- > > Axel Leitner wrote: > > > > > Hello everybody, > > > > > > has someone a suggestion how to block unauthorizied spam > access with an > > > iptables rule thru 25/tcp ? > > > > > > Bye > > > > > > Axel > > > > > > > > > > > > > > > -- > > Erwin Zierler | web- / host- / postmaster - stubainet.at > > | erwin.zierler(a)stubainet.at / webmaster(a)stubainet.at > > | Tel.: 0 5225 - 64325 Fax 99 Mobil: 0664 - 130 67 91 > > > > > > -- > > To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com > > For additional commands, e-mail: suse-security-help(a)suse.com > > Security-related bug reports go to security(a)suse.de, not here > > > > > > > -- > To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com > 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

iptables blocking telnet 25 ?
by Axel Leitner 30 Apr '02

30 Apr '02

Hello everybody, has someone a suggestion how to block unauthorizied spam access with an iptables rule thru 25/tcp ? Bye Axel

3 3

RE: [suse-security] Firewall Linux? Firewall software
by Paxton, Michael 30 Apr '02

30 Apr '02

Oracle generally requires an application proxy to use SQL*net/Net8 through a firewall. Oracle provides its proxying code "free of charge" to firewall vendors. (Of course free of charge doesnt necessarily mean compatible with open licensing arrangements). The application proxy is also part of Oracle connection manager which, presumably, you could set up on your firewall box. In theory connection manager + any firewall software = oracle friendly firewall I guess. This is, of course, only if you are using SQL*Net/Net8 to communicate between client and server. Michael Paxton ------------------------------------------- Michael Paxton - Michael.Paxton(a)aihw.gov.au Data & Information Technology Unit Australian Institute of Health & Welfare -----Original Message----- From: Reckhard, Tobias [mailto:tobias.reckhard@secunet.com] Sent: Tuesday, April 30, 2002 2:22 PM To: suse-security(a)suse.com Subject: RE: [suse-security] Firewall Linux? Firewall software > Chaps and chapesses, does anyone out there know a good > location or doc for > firewall security with Oracle? Metalink (Oracle's site > doesn't seem to be > too hot). Inside / Outside the firewall pro's and con's > issues, how to set > up that sort of thing. On Linux of course. Is there a > firewall version of > Linux? Is it not just normal Linux with some packages > installed and some > tweaking? Am I barfing up the wrong tree? Why would you want something specific to Oracle? The dangers facing servers are very similar, be it that they serve web, news, mail, directory or database content and functions. The differences from a firewalling perspective lie in the direction of communication and the protocol used, the question whether an application layer gateway is available, and the ports used. IMHO, you'd be a fool not to shield an Oracle database with a firewall if you're allowing access from a potentially hostile environment. Many people prefer to place 'staging' databases in DMZ networks that hold only the bare records necessary to perform their function and that exchange data with the production database on the internal network, so that the latter never has direct contact with the hostile environment. Really, apply common sense and security principles and you'll get a sound design, no matter what type of service you're dealing with. > This message is confidential and may also contain privileged [snip] You do realise that your disclaimer is twice as long as the mail you wrote? <shrug> Tobias -- To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com 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

RE: [suse-security] Firewall Linux? Firewall software
by Reckhard, Tobias 30 Apr '02

30 Apr '02

> Chaps and chapesses, does anyone out there know a good > location or doc for > firewall security with Oracle? Metalink (Oracle's site > doesn't seem to be > too hot). Inside / Outside the firewall pro's and con's > issues, how to set > up that sort of thing. On Linux of course. Is there a > firewall version of > Linux? Is it not just normal Linux with some packages > installed and some > tweaking? Am I barfing up the wrong tree? Why would you want something specific to Oracle? The dangers facing servers are very similar, be it that they serve web, news, mail, directory or database content and functions. The differences from a firewalling perspective lie in the direction of communication and the protocol used, the question whether an application layer gateway is available, and the ports used. IMHO, you'd be a fool not to shield an Oracle database with a firewall if you're allowing access from a potentially hostile environment. Many people prefer to place 'staging' databases in DMZ networks that hold only the bare records necessary to perform their function and that exchange data with the production database on the internal network, so that the latter never has direct contact with the hostile environment. Really, apply common sense and security principles and you'll get a sound design, no matter what type of service you're dealing with. > This message is confidential and may also contain privileged [snip] You do realise that your disclaimer is twice as long as the mail you wrote? <shrug> Tobias

1 0

[suse-security] Partitions
by Michael Stern 29 Apr '02

29 Apr '02

> Although I'm not a suse expert all I did was make a partition called > /cryptomaniac and have it format it as reiser FS instead of ext2. > Added the > password, and now when suse boots it asks for the password. > > I need information about secure partitions, I have HD 40G, I like a web > > server an mail server. I wouldn't store that important data an the server anyway. crypto-fs is good if you have a laptop and need to know noone can easily decipher your data in case it's being stolen. if you have a server and mount an encrypted-partition at server-bootup, anyone compromising your server will be able to see your data, and even if you haven't mounted the partition there is nothing really preventing a possible intruder to install a keylogger and trojan your system. better use your time to secure the server and install an IDS and take other precautions such as a dedicated log-host, signed files, etc. michael

1 0

**** Urgent Help Needed : SuSEfirewall2 and 2nd network ****
by Huseyin Selan 29 Apr '02

29 Apr '02

Hi All, We have the following configuration. - 1 branch office and 1 HQ - 2 routers using VPN - SuSE Linux running SuSEfirewall2 in HQ - 1 interface to internet, 1 interface to internal LAN in the Linux box - branch office comes from external interface with the IP of 10.0.0.0/24 - internal IP is 192.168.1.0/24 - no DNS, etc. using ISP's DNS - using firewall2.rc.config file So, using the configuration above, how will I allow the clients to access to internet ? Thanks in advance,

3 2

Firewall Linux? Firewall software
by Stelios Charalambides (5794) 29 Apr '02

29 Apr '02

Chaps and chapesses, does anyone out there know a good location or doc for firewall security with Oracle? Metalink (Oracle's site doesn't seem to be too hot). Inside / Outside the firewall pro's and con's issues, how to set up that sort of thing. On Linux of course. Is there a firewall version of Linux? Is it not just normal Linux with some packages installed and some tweaking? Am I barfing up the wrong tree? This message is confidential and may also contain privileged information. If you are not the intended recipient, please contact the NHBC IT Dept. on +44 1494 735353 or ITRCMSG(a)nhbc.co.uk (You should not disclose its content to any other person). The contents of this email are, unless the contrary is expressed, solely the view of the writer(s) and not of NHBC. NHBC has not authorised this email (unless the contrary is expressed) and the fact that it is sent on the NHBC system is not authorisation. NHBC is not responsible for the contents and accepts no responsibility for them. Data Protection Act 1998. NHBC is the Data Controller for the purposes of the Act. It stores this email and may record details taken from it as record of your communication. NHBC may pass your details to other organisations if the reason for your contacting us makes it appropriate. If you do not want your details passed on please inform NHBC immediately. This email has been scanned for viruses however the NHBC does not accept any liability in respect of damage caused by any virus which is not detected.NHBC is a member of the General Insurance Standards Council.

1 0

SuSE Security Announcement: radiusd-cistron (SuSE-SA:2002:013)
by Sebastian Krahmer 29 Apr '02

29 Apr '02

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: radiusd-cistron Announcement-ID: SuSE-SA:2002:013 Date: Mon Apr 29 13:00:00 CEST 2002 Affected products: 6.4, 7.0, 7.1, 7.2, 7.3, Enterprise Server 7 Vulnerability Type: remote command execution Severity (1-10): 7 SuSE default package: No Other affected systems: Various radius clients and servers. Content of this advisory: 1) security vulnerability resolved: digest calculation buffer overflow, invalid attribute length calculation problem description, discussion, solution and upgrade information 2) pending vulnerabilities, solutions, workarounds 3) standard appendix (further information) ______________________________________________________________________________ 1) problem description, brief discussion, solution, upgrade information The radius daemon as shipped with the radiusd-cistron package is responsible for the RADIUS authentication service in networks and therefore considered a security critical application. ZARAZA reported security releated bugs in various radius server and client software. The list of vulnerable servers includes the cistron radius package. Within the cistron package, a buffer overflow in the digest calculation function and miscalculations of attribute lengths have been fixed which could allow remote attackers to execute arbitrary commands on the system running the radius server. Beside the cistron radius package the following radius packages have been vulnerable to the same attacks and have been fixed: freeradius, radiusclient and livingston-radius. The only workaround for this bug is to disable the radius-server until the new packages have been installed. 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. Once you successfully updated your radius packages, make sure you restart the radius server by issuing the following command as root: "/etc/rc.d/radiusd restart" "/etc/rc.d/radiusd" automatically invokes the correct radius-server which is part of either the cistron, livingston or freeradius package. i386 Intel Platform: SuSE-7.3 ftp://ftp.suse.com/pub/suse/i386/update/7.3/n3/radiusd-cistron-1.6.4-168.i3… 8215e7113e8937844ab5d2deba8bbb13 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.3/zq1/radiusd-cistron-1.6.4-168.s… 978edf49cf7fa28c5e872bc48ba504ab SuSE-7.2 ftp://ftp.suse.com/pub/suse/i386/update/7.2/n3/radiusd-cistron-1.6.4-167.i3… 964904ef67f81b2d19f1c8ef2ccc6f61 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/radiusd-cistron-1.6.4-167.s… 6ffd720c4ceb0e0c6d22446178d8bf11 SuSE-7.1 ftp://ftp.suse.com/pub/suse/i386/update/7.1/n3/radiusd-cistron-1.6.4-168.i3… 52ec1da0c4b750fe63d506713ff56c5e source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.1/zq1/radiusd-cistron-1.6.4-168.s… 6d34cc16bf9adcc93eac095570f49748 SuSE-7.0 ftp://ftp.suse.com/pub/suse/i386/update/7.0/n2/cistron-1.6.3-76.i386.rpm 52a9b0c7fcbd45973db6508d155edf21 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.0/zq1/cistron-1.6.3-76.src.rpm a22a646d5f04dd853906db9cc465f14a SuSE-6.4 ftp://ftp.suse.com/pub/suse/i386/update/6.4/n2/cistron-1.6.2-25.i386.rpm bed8804bf53822d7f7bcdd54f00a9d89 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/6.4/zq1/cistron-1.6.2-25.src.rpm b47877d68465e895fe899da9ba89709d Sparc Platform: SuSE-7.3 ftp://ftp.suse.com/pub/suse/sparc/update/7.3/n3/radiusd-cistron-1.6.4-65.sp… 3230120f925437fd36b648991a3b4851 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.3/zq1/radiusd-cistron-1.6.4-65.s… 713f6f1f7fe4c2987a52b12df6ef2c4a SuSE-7.1 ftp://ftp.suse.com/pub/suse/sparc/update/7.1/n3/radiusd-cistron-1.6.4-65.sp… d444432bd863523992620401311f948b source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.1/zq1/radiusd-cistron-1.6.4-65.s… ff7a7f432a0a32fbed31a6ee680d5118 SuSE-7.0 ftp://ftp.suse.com/pub/suse/sparc/update/7.0/n2/cistron-1.6.3-4.sparc.rpm 69ee7178a0312685a169386180cd5e9e source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.0/zq1/cistron-1.6.3-4.src.rpm 71632b60b9b2bee4df06f940088b0ab6 AXP Alpha Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/axp/update/7.1/n3/radiusd-cistron-1.6.4-69.alph… 323032020d8c82724b12904db456c135 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/7.1/zq1/radiusd-cistron-1.6.4-69.src… 7440831ddb1e394ac6595e9e5bebbff1 SuSE-7.0 ftp://ftp.suse.com/pub/suse/axp/update/7.0/n2/cistron-1.6.3-8.alpha.rpm 4deb36542c3a76a9246618abcd656d96 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/7.0/zq1/cistron-1.6.3-8.src.rpm 77c3cfe8cb64d7c2cd59b81e0e1e26ea SuSE-6.4 ftp://ftp.suse.com/pub/suse/axp/update/6.4/n2/cistron-1.6.2-20.alpha.rpm 0c39bec71f6671c55b46ed627f2830d9 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/6.4/zq1/cistron-1.6.2-20.src.rpm 8783c9b8f519a1623bf6df52a8878ab0 PPC Power PC Platform: SuSE-7.3 ftp://ftp.suse.com/pub/suse/ppc/update/7.3/n3/radiusd-cistron-1.6.4-95.ppc.… a541869da6cfa45822887dc69f7730f8 source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.3/zq1/radiusd-cistron-1.6.4-95.src… da491549cda05ead01d2dd0519f14eeb SuSE-7.1 ftp://ftp.suse.com/pub/suse/ppc/update/7.1/n3/radiusd-cistron-1.6.4-95.ppc.… 998f87b937ec36e55ee0151f82a071fa source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.1/zq1/radiusd-cistron-1.6.4-95.src… ebb96d0b9b5093a5324c90743f7a69a3 SuSE-7.0 ftp://ftp.suse.com/pub/suse/ppc/update/7.0/n2/cistron-1.6.3-85.ppc.rpm 7258462a504e594f07433f342b0870c1 source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.0/zq1/cistron-1.6.3-85.src.rpm d6ebb9cdd5c3538eae2db805f6fda97b SuSE-6.4 ftp://ftp.suse.com/pub/suse/ppc/update/6.4/n2/cistron-1.6.2-21.ppc.rpm 6274908e60a8ff24a3be7c4936b36d90 source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/6.4/zq1/cistron-1.6.2-21.src.rpm aa350c9fedc384c382744b4b2563250c ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - mtr A buffer overflow was found in mtr, which enables an attacker to get access to mtr's raw socket. Fixed RPM packages are available from our ftp servers. Additionally you should remove the setuid bit from mtr and add an appropriate entry in /etc/permissions.local. - webalizer A possible buffer overflow in the webalizer DNS resolv code was found. The bug seems no to be exploitable. The SuSE Security Team fixed this and other possible bugs in the webalizer code. New RPM packages will be available on our FTP servers. - ntop Version < 2.0.99 of ntop could be crashed by feeding ntop's HTTP code with invalid URL's. This bug does not exist in ntop version 2.0.1 which is shipped with SuSE 8.0. - slrnpull Problems with slrnpull have been reported on the bugtraq mailinglist. SuSE does not ship this program setuid and is therefore not vulnerable to the buffer overflow attack against this program. - openssh Niels Provos published a local exploitable bug for OpenSSH. This bug could only be exploited if Kerberos and AFS support was enabled while compiling OpenSSH. The OpenSSH RPM file that comes with SuSE hasn't enabled Kerberos nor AFS, so we are not vulnerable to this attack. The bug will be fixed with the next security update of OpenSSH. ______________________________________________________________________________ 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 uninstalled 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 toplevel 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 annoucements 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 cleartext signature shows proof of the authenticity of the text. SuSE GmbH 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: 2.6.3i Charset: noconv iQEVAwUBPM0xTXey5gA9JdPZAQGrKgf/U+sVMw2IG/AB0fCZLuFHxWeUPf1ivvYN 7HwFYivB2LQgQGpPRT/T9YpdsnRJzCIugyx+sMFDjN6ARGRpeehQR5P+OZPq0xBH ptxcfks4/1u3bx/pRQ5a4KOxqSscYuEL8B66yH4nTb2E5QsmR5ZCxtoA0VtwLFT2 ZGqr3eAY6Uk78V7G/oPszdZtkcPJGMsHg6TEjFiu5ff7pclULWSmj8iQBKcMJbcG sFu3kfhrGYDq0MYMLTXttDDgC7dM9Y4z819ZHDZA2cSZAiBEuCFQ+NweEE4+sY/r QDie2nbRr6ZWTLYz6/kUc5KNyhMiQD+qhkUJg5yhDBnb/BFu7yfahg== =APbN -----END PGP SIGNATURE----- -- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer(a)suse.de - SuSE Security Team ~

1 0

Honeypot Software
by Marko.Muncan＠arxes.de 29 Apr '02

29 Apr '02

Does SuSe 8.0 have a built-in Honeypot Software? And if so, what is it called? Tried to set up dtk yesterday on another Mandrake Box and it didnt work out because of its using xinetd. Any help to this topic would be greatly appreciated! Mit freundlichen Grüßen Marko Muncan __________________________________________ arxes Network Communication Consulting AG Schanzenstraße 36 Gebäude 197 D-51063 Köln Telefon: +49 (0) 221 96486 - 268 Telefax: +49 (0) 221 96486 - WEB: http://www.arxes.de MailTo: Marko.Muncan(a)arxes.de Informieren Sie sich über unsere Veranstaltungen zu den aktuellen IT-Themen unter http://www.arxes.de/de/events/index.html

2 1

User Password Change does not Propagate to IMP Server
by Wilmer Geovanny 28 Apr '02

28 Apr '02

When a User changes his Password by means of his shell prompt, with the passwd command, the user cannot access anymore to his mail box by means of the IMAP server. This is the only server that does not get known of the change. Well, SuSE Linux 7.3 and when the password is changed by the Yast utility, everything works great. It seems that there is some script missing to be running. Thank you in advance for any help. -- =_=_=_=_=_=_=_=_=_=_=_=_=_=_=_= Geovanny Guamán TACteam GmbH Webmaster, http://www.tacteam.de http://www.flyconnect.de Schlesierweg 8 24145 Kiel Telefon 0431-716864 Telefax 0431-7098981 Mobil: +49(160)97836579 HOMO GNOSCETE IMPSUM _=_=_=_=_=_=_=_=_=_=_=_=_=_=_=_= ------------------------------------------------- This mail sent through IMP: http://horde.org/imp/

3 2

User: nobody ?
by Simon Dorfman 28 Apr '02

28 Apr '02

Hello, I found the user: "nobody" running "find" on my machine. My first thought was that someone had hacked in. My second thought was that maybe suse runs some commands on it's own as "nobody." Does anyone know if the latter is true? Thanks, Simon(a)SimonDorfman.com http://SimonDorfman.com

6 5

Disallowing Agents
by Togan Muftuoglu 27 Apr '02

27 Apr '02

Hi, How can I disable a website to be mirrored by Wget? I have tried robots .txt with User-agent :* Disallow: / It stops the robots but not Wget so is there some other way to stop wget users eat my bandwidth? Thanks -- Togan Muftuoglu

2 1

Lisa breaks FW anti-spoofing
by Pep Serrano 27 Apr '02

27 Apr '02

Hello susers, I have the lisa deamon running and get the following logs in my FW: Apr 26 19:15:40 petit kernel: SuSE-FW-DROP-ANTI-SPOOFINGIN=eth0 OUT= MAC= SRC=192.168.0.100 DST=255.255.255.255 LEN=44 TOS=0x00 PREC=0x00 TTL=64 ID=0 DF PROTO=UDP SPT=1028 DPT=7741 LEN=24 How can avoid it? Cheers, Pep Serrano.

2 2

Firewall Rule 14
by alessandro.de.bertoldi 26 Apr '02

26 Apr '02

hi, i would like to access the dbase-server (192.168.1.5) from home (xxx.xxx.xxx.104). i changed the firewall2-rule, so the firewall is now forwarding my request with this ip to the db-machine. the result is, that the firewall has now forwarding ALL web requests (192.168.1.6) to the db machine Rule 14. FW_FORWARD_MASQ="xxx.xxx.xxx.104,192.168.1.5,tcp,80 0/0,192.168.1.6,tcp,80" what is wrong with this rule ? i try also FW_FORWARD_MASQ="xxx.xxx.xxx.104/0,192.168.1.5,tcp,80 0/0,192.168.1.6,tcp,80" thank you

2 1

chkrootkit deletion(s)
by Martin Knipper 26 Apr '02

26 Apr '02

Hi at all, I was running chkrootkit (www.chkrootkit.org) two days ago and everything seemed to be normal output. Except this: [...] Checking `wted'... 2 deletion(s) between Tue Apr 16 18:11:18 2002 and Thu Apr 18 21:43:32 2002 3 deletion(s) between Thu Apr 18 22:30:05 2002 and Mon Dec 23 09:09:48 1935 10 deletion(s) between Sat Apr 20 12:04:47 2002 and Tue Apr 23 17:10:35 2002 4 deletion(s) between Tue Apr 23 23:56:43 2002 and Wed Apr 24 23:54:18 2002 [...] Is there something I need to worry about ? regards ---Martin

2 1

suse firewall and VPN
by Wagner, Uwe 26 Apr '02

26 Apr '02

Hi, I want to use a VPN connection from my windows pc through my suse firewall to another pc in the internet. Is there the need to install freeswan on my firewall or can I just open the needed ports ? (which ports must be opened ?) thanks uwe <<Wagner, Uwe.vcf>>

4 7

proftpd
by Thomas Neukirch 26 Apr '02

26 Apr '02

hi list, can someone please tell me how to configure the proftpd.conf that only one user (with password) can login via ftp and the other users (i.e. ftp, anonymous) are disabled ? thanks --------------------------------------------------------------------------- Thomas Neukirch (Systemadministrator) email: thomas.neukirch(a)dtvtabak.de tel.: 02234-96310-26 fax: 02234-96310-22 www.dtvtabak.de

2 1

RE: [suse-security] SuSE personal Firewall 1.1-4 / ppp*
by Reckhard, Tobias 26 Apr '02

26 Apr '02

> I've been lurking around for a while and followed this > discussion with > interest. I have the problem here that reloading the firewall > rules after > connecting to mu ISP takes so long (about 12-15 seconds), > that for instance > my DNS times out and gives up because the firewall is > dropping the responses > which it should get. Yes, I know that upgrading to a more > powerfull computer > might also fix this delay, but I hate to upgrade the 'ol > Pentium 133 which > handles internet traffic via ISDN, just because reloading the > firewall rules > takes too long, while it is running idle most of the time > (even once the > connection is established and the firewall rules are reloaded). If you have many rules then iptables' and current way of modifying the chains will cause long delays when manipulating chains. The problem a colleague of mine found in the source code and that Rusty et al. are well aware of is that for each and every iptables [-A|-D|-I|-R] operation, the chain in question in memcopied as two halves, separated by the space where the manipulation is taking place. That is applied and then everything is memcopied into kernel memory (or maybe they merely change a pointer, I don't know). The point is that for each and every iptables line in a script, this procedure takes place. iptables-restore doesn't suffer from this drawback, BTW. You'll notice the COMMIT statement at the end of the output of a file created with iptables-save. However, I think you need to have a considerable number of rules for the effect to become as noticeable as you say, even on a P133.. But I haven't checked it out on that kind of a machine yet. >From a security point of view, though, you're safer the way it is than if the box would be open during those 15 seconds. > What puzzles me, is how filtering based on information > received from my ISP > (the local IP) might give additional protection against a > spoofing via the > same ISP. If someone manages to attack the servers at my ISP > and manages to > spoof an address, how can I trust ANYTHING which is coming > from there. In > this case, the local IP which is handed out via DHCP. Oh, I wouldn't trust anything (purportedly) coming from the ISP. You don't have a choice but to accept their DHCP lease, though. There is no alternative other than to get a fixed IP address[1]. > I bluntly changed the SuSEfirewall2 script to allow traffic > with a local > destination for any of the local IPs I might get (a query to > whois gave me > all local addresses I may get from my ISP) even before the > connection is > made. As long as the destination is within this range, this > prevents me from > having to reload the firewall rules when I connect to my ISP. > I don't expect > my ISP to change this range very frequently, so this should > (and does so far) > work most of the time. Am I missing something important here? Define important. But you're probably not risking terribly much more. I believe you could filter based on the exact destination address and not experience dropouts simply by inserting the entire rulebase with the modified IP address in front of the old one, then deleting the 'old' rules. You'd have to be careful not to miss any, since you can't use the flush command. I guess this may not be possible with SuSEFirewall2, but I can't say -- I haven't used it myself yet, up to now I've always rolled my own. Cheers Tobias [1] This general statement if, of course, not entirely true. It is absolutely possible to create 'secure' mechanisms for functionality equivalent to DHCP. But you probably won't find any ISP who will cooperate.

1 0

postfix regexp in body_checks
by Philipp Snizek 25 Apr '02

25 Apr '02

Hi, I hope I hit the right list with my request. I'm trying to set up a filter for postfix to filter malicious stuff like all windows executables. For MIME encoded headers I had no problem, this works fine. But if the header is uuencode, the attachment is only visible in the e-mail's body. I tried a regexp like /.*\.(bat|exe|cmd|vbs|vba)/ REJECT in /etc/postfix/body_checks which should filter all *.bat|and so on. But nothing at all happens. Mails go thru as if there wasn't an obstacle. If there is some postfix & regexp pro on this list, please tell me what I am doing wrong. Thanx, Philipp

9 16

boot option
by Thomas Futschek 25 Apr '02

25 Apr '02

Hi list! Recently I saw if you boot a kernel with a boot option like 'init=/bin/bash' (to example: linux init=/bin/bash) you become root without athentification. Can anybody tell me why it works and how I protect? Thanx! Thomas -- Have A Nice Day -- ________________________________________________________________ Keine verlorenen Lotto-Quittungen, keine vergessenen Gewinne mehr! Beim WEB.DE Lottoservice: http://tippen2.web.de/?x=13

8 8

RE: [suse-security] SuSE personal Firewall 1.1-4 / ppp*
by Reckhard, Tobias 25 Apr '02

25 Apr '02

> > The antispoofing rules, at least, need to be rewritten when the > > IP address changes. > > AFAIK "antispoofing" means to drop packets with source addresses > which come from the wrong interface. Not quite. Spoofed IP packets have false addresses, i.e. source or destination addresses or both. When talking about anti-spoofing, people usually use the terms 'egress filtering' and 'ingress filtering' to mean filtering of outbound and inbound packets respectively. When considered alone, it makes sense to check both source and destination addresses. The source addresses are of higher importance, though. > At least in a common > configuration (internal LANs with static addressing and a > dialup/DSL/cable uplink) I don't see why the antispoofing rules > should change when the local IP address changes. If you wish to use the IP address of local machines (including and sometimes restricted to the gateway) as qualifiers in your packet filtering rules, you need to update those along with the IP address. > And let me repeat, if you don't trust your ISP, you don't know if > you get the correct IP assigned, but if you do, you know that the > ISP router will route the correct packets (destination based). Have you never seen a confused or misconfigured router? What happens when someone breaks into the ISP and changes the configuration of their equipment? Break into an ISP router and configure it to establish GRE tunnels and you've got some very hefty potential problems. It's not about trusting or not trusting the ISP. The problem is that you have practically no influence on their security. OTOH, you have full control over your own systems and you can apply security measures to suit your degree of paranoia. With the ISP's equipment, your options are considerably fewer, very often none. > Well, and since the source addresses are unaffected by your local > IP, nothing changes. Usually you may get just *any* IP assigned, > and by that you can filter with any as local IP. That's possible and swinging the balance between security and ease of use towards the latter by some measure I don't wish to discuss. If you can't or are unwilling to do without the IP address information, you need to update the packet filter configuration whenever that changes. > Since at the last time we had such a thread and nobody had a > situation requiring rule rewriting (not counting very exotic > setups), I still think there is no need for such rewrites in a > clean configuration. As long as everything is properly configured, yes. But security has a concept called 'defense in depth'. If you follow that concept, you will have redundant, overlapping mechanisms. All but one are unnecessary as long as that one left doesn't fail. But what if it does? This, of course, leads to compromise. Those with the need for high security use many layers of defence, those with assets of lower value (or those that don't care or know better) employ fewer layers. In the end it's always a question of cost. Cheers Tobias

3 2

Re: [suse-security] iptables/ipchains and kernel 2.2.19/2.4.x...which isbetter for firewall?
by Bill.Light＠kp.org 25 Apr '02

25 Apr '02

Hi Jeric Just an opinion.... I am right now playing with SuSE 8.0, the default kernel is 2.4.18. For your firewall - I believe iptables is the way to go....but get it from SuSE 7.3 and there is an update to 2.4.16 kernel for 7.3 This 8.0 seems to big and clumsy for a 486. - Bill "jeric" <jeric(a)mmcable.com> 04/24/02 04:40 PM To: <suse-security(a)suse.com> cc: Subject: [suse-security] iptables/ipchains and kernel 2.2.19/2.4.x...which is better for firewall? Hi, Since SuSE 8.0 is coming out, I am toying with the idea of upgrading my firewall/router box. It is currently running 7.0 with kernel 2.2.19 and ipchains. Is the upgrade to the better iptables worth also porting over to the less mature 2.4.x kernel? At this point in those two kernel developments, is there still a security/maturity difference? And if I upgrade to 8.0 will I be able to still install it on an x486 with 64MB RAM, box using the minimal install option? I read that the default install GUI will not run on an old x486, but was not sure about the minimal install option. Also, if upgrading to SuSE 8.0, which kernel does it install by default? Thank you, jeric

5 6

RE: [suse-security] iptables/ipchains and kernel 2.2.19/2.4.x...w hich is better for firewall?
by Reckhard, Tobias 25 Apr '02

25 Apr '02

The following is entirely personal opinion. > Since SuSE 8.0 is coming out, I am toying with the idea > of upgrading my firewall/router box. I prefer not to update distributions, but rather perform fresh installs, if tolerable. I've had a couple of problems when updating in the past, but I've forgotten the specifics. > It is currently running > 7.0 with kernel 2.2.19 and ipchains. Is the upgrade to the > better iptables worth also porting over to the less mature > 2.4.x kernel? It is debatable whether ipchains is *better* than iptables. Actually, you can never claim anything to be better than something else without specifying a metric. You will certainly find quite a number of people of the opinion that ipchains is more secure or even gives more security than iptables. You'll find a considerable number that say the opposite. It's up to you to form your own opinion. > At this point in those two kernel > developments, is there still a security/maturity difference? That depends on your measure. I prefer iptables to ipchains, but I'm not sure I trust it as much, especially the connection tracking code. There have been numerous bugs in the masquerading helpers and coding them isn't always exactly easy. Connection tracking modules are very similar to masquerading modules. I am convinced that there is a wide range of security between the different conntrack and masq modules... As far as the maturity of the kernels go, I haven't had any problems with the 2.4.10 or 2.4.16 kernels supplied by SuSE for the 7.3 distro yet. I did have some strange phenomena with earlier ones, but at least one of those was a Mantel kernel, which are clearly labelled as experimental-grade. I have pretty unspectacular machines, though, and don't use many of the fancy new kernel options. BTW, I know of a problem on a SuSE 7.0 machine with the reiserfs release on it. Seems that postfix relies on the kernel filesystem driver to report a certain error code when checking for maximum message size and some versions of reiserfs supply the wrong code. I don't know if there's an update from SuSE that rectifies the problem. I do know that the current iptables release in SuSE 7.3 has a buggy iptables-save, which creates '--reject-with reject-with' instead of '--reject-with tcp-reset'. I find this a very annoying bug and it rather unfortunate that SuSE haven't released an update yet. However, I have only informed Roman about this problem per email and haven't made any further efforts to get the problem solved -- I expected the iptables in SuSE 8.0 to be absent of this bug and have been waiting for it. But this is a problem I have with SuSE or, more specifically, with their policy of mostly patching the source code of packages they originally used when building a distro and not releasing more current versions of the original packages (i.e. the tarballs) as updates. Security-critical bugs are fixed, but my impression is that functional bugs aren't rectified as quickly, if at all. And you seldom get the features a new release of the tarball package contains. It's probably unreasonable to expect SuSE to provide updates to all software packages in the distro for its entire lifetime. I have a feeling RedHat RPMs are compatible across major version numbers, maybe this would be a beneficial compromise. However, that could also involve disadvantages I haven't though of. > And if I upgrade to 8.0 will I be able to still install it on > an x486 with 64MB RAM, box using the minimal install option? I suppose you should be able to install it. I can't say how well it'll run. I recommend against the use of KDE or Gnome, if X at all. > I read that the default install GUI will not run on an old > x486, but was not sure about the minimal install option. I don't know if it checks the CPU (don't think so), but it won't run on machines with less than 64 MB RAM. So it should attempt to run on your machine. > Also, if upgrading to SuSE 8.0, which kernel does it > install by default? 2.4.18, as someone else has also already said. Cheers Tobias

1 0

SuSEfirewall and licq 1.1.0
by curtain 25 Apr '02

25 Apr '02

hi list, i am using linux 7.1 pro with a 2.2-kernel. i masquerade my internal network with the firewall (ip range 192.168.0.1 to .4); and i use an isdn dialup connection. i thought that the firewall _really_ masquerades my lan; but when i watched myself being online from a friend's box running licq 1.1.0, licq told me - apart from the external ip beginning with 62. - my private ip :( if licq is capable in looking behind that firewall, how can i assure that _real_ hack programs cannot do this ... i suggest that icq delivers all ips that it can gather; but don't other apps also??? how can i tell the firewall not to submit internal ip names - well - is the fw able to do it? -- icq# 67532578; return 0;}

3 2

[suse-security] suse firewall and VPN
by Tobias Korb 25 Apr '02

25 Apr '02

Hi, > > I want to use a VPN connection from my windows pc through my suse firewall > to another pc in the internet. > Is there the need to install freeswan on my firewall No, you dont`t need but perhaps it is better to do so your hole lan can use this vpn connection freeswan is ipsec... do the vpn server in the internet use ipsec??? > or can I just open the needed ports ? (which ports must be opened ?) which vpn do you want to use?? ipsec??? pptp/chap??? there are so many vpn versions with so many difficult ports!! mfg tobi sorry my englisch isn`t so good

1 0

RE: [suse-security] iptables/ipchains and kernel 2.2.19/2.4.x...w hich is better for firewall?
by Peer Stefan 25 Apr '02

25 Apr '02

Hi Jeric, > From: jeric [mailto:jeric@mmcable.com] > > Hi, > Since SuSE 8.0 is coming out, I am toying with the idea > of upgrading my firewall/router box. It is currently running > 7.0 with kernel 2.2.19 and ipchains. Is the upgrade to the > better iptables worth also porting over to the less mature > 2.4.x kernel? At this point in those two kernel > developments, is there still a security/maturity difference? > And if I upgrade to 8.0 will I be able to still install it on > an x486 with 64MB RAM, box using the minimal install option? > I read that the default install GUI will not run on an old > x486, but was not sure about the minimal install option. For what I learned in the past few years ... never install a new distro unless it's really necessary. If you want iptables-support, just install the SuSE 2.4.16-Kernel on your 7.0, install the iptables-rpm from your cd's and toy around with iptables. But as long as your willing to toy around with new problems (every update means new problems ;-), go on and try it. 8.0 sure is a great peace of work, but you will encounter performance-problems when using yast2 ... > Also, if upgrading to SuSE 8.0, which kernel does it > install by default? 8.0 uses 2.4.18 as default. Keep an eye on ftp://ftp.suse.com/pub/people/mantel/next for new kernels :-) > Thank you, > jeric regards, Stefan

1 0

new alternate email address.
by Jason Reed 24 Apr '02

24 Apr '02

Since yahoo is changing their email handling policies, use jasonreed9(a)attbi.com if I don't respond to lupob(a)yahoo.com. Jason

1 0

Sendmail and Hosts.allow
by CJB 24 Apr '02

24 Apr '02

For some reason sendmail won't accept mail when my hosts.deny file contains "ALL:ALL" I've never had this problem before with the many servers that I've set up... I've included pop3:ALL and imap:all in my hosts.allow file and that seems to fix things (before adding those two it would accept mail from the domains listed in hosts.allow that I had given telnet access too)... Any idea on how to get sendmail to accepts incoming mail without giving people pop and imap access to the accounts (I'm forcing webmail, I know, it's bad, but it makes my life easier)? Thanks, Cj B

2 1

Can't understand nessus result
by Konrad Klein 24 Apr '02

24 Apr '02

Hi everybody, today I had a few crazy nessus results. I did a securityscan on my machine and nessus found a security hole in isakmp service. It says The remote IPSEC server seems to have a problem negotiating bogus IKE requests. An attacker may use this flaw to disable your VPN remotely Solution: Contact your vendor for a patch Risk factor: High Protocol UDP Port 500 At the last nessus scan at about the 11th April, no security whole was found. In both cases I updated the nessus db with nessus-update-plugins before i started the scan. My real problem is, that I'm absolutely sure, that no IPSEC server is running on my system. To check this result, I installed SuSE 7.2 in a minimal configuration with absolut no network services running on another computer and also made a nessus scan. Again I get a security hole in isakmp. Then I started an nmap scan wit h the option sU, and nmap didn't find an open udp port. Is it a bug in the nessus attack-script or is there a "hidden" directive in SuSE 7.2 that i didn't find or has someone similiary "problems" and knows a solution? My nessusd version is 1.0.9 Thanks a lot in advance Konrad

1 1

udp and ipchains
by Pedro Marques 24 Apr '02

24 Apr '02

hi i'm using ipchains on a box running SuSE 7.0. the only service I run is Apache so I made a script to block all inconvinient connections. the problem appears when I block all UDP traffic from the external network (internet), it seems to "crash" ipchains, doing "ipchains -L" the rule is: ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 0:65535 there is no problem if I use: ipchains -A input -p udp -j DENY -s 0.0.0.0/0 -i eth0 -d 0.0.0.0/0 1024:1100 what am I doing wrong here? thanks :) Pedro

2 1

Re: [suse-security] Network hangs...
by Michael Appeldorn 24 Apr '02

24 Apr '02

>i manage a remote suse 7.2 server (full patched) with apache/tomcat. >Today it was unreachable (no ping no ssh no http). I called my isp, he >gone to console and told me: > >- memory was ok >- the ip was up (ifconfig) >- the route too >- he wasn't able to ping any external ip (100% packet loss). > >I told him to start/stop network and route and all worked again... >what's happened? >/var/log/messages tells nothing of strange... Could somebody tell me >what i can check to try to understand the reason of this strange >behaviour? Is there a way to enable a more accurate log for the next >time? > >Thanks a lot! I saw it before on some of my fileservers. The only thing i had to do was to disable the ide-dma. hdparm -d0 /dev/hdaX Dont ask me why, seems to be somwhat like timing. (was 7.2 suse too). Another idea is to upgrade the kernel. 2.4.18. runs fine on my production machines and may be they changed your network driver somehow (try diff on network-drivers-c-file) Yours Michael Appeldorn

1 0

RE: [suse-security] Searching a simple secure mail realy program
by Reckhard, Tobias 24 Apr '02

24 Apr '02

> I am searching for a secure and simple mail relay program and > I was wondering > if any of you know of such a tool to be included in the SuSE > distro. The > intention is simple, i just want to be able to queue outgoing > mail or send it > directly from the internal network, so nothing fancy, but it > must be secure > and dependable. I'm not sure if it's simple enough for you, but Postfix is probably worth a recommendation. Tobias PS: Sorry about the ugly quoting.

1 0

Searching a simple secure mail realy program
by Marcel Schot 24 Apr '02

24 Apr '02

Hi all, I am searching for a secure and simple mail relay program and I was wondering if any of you know of such a tool to be included in the SuSE distro. The intention is simple, i just want to be able to queue outgoing mail or send it directly from the internal network, so nothing fancy, but it must be secure and dependable. Of course alternatives that are not included in the distribution are welcome too. Thanks in advance, Marcel

2 1

Network hangs...
by mario libraro 24 Apr '02

24 Apr '02

Hi to all listmates, i manage a remote suse 7.2 server (full patched) with apache/tomcat. Today it was unreachable (no ping no ssh no http). I called my isp, he gone to console and told me: - memory was ok - the ip was up (ifconfig) - the route too - he wasn't able to ping any external ip (100% packet loss). I told him to start/stop network and route and all worked again... what's happened? /var/log/messages tells nothing of strange... Could somebody tell me what i can check to try to understand the reason of this strange behaviour? Is there a way to enable a more accurate log for the next time? Thanks a lot! Mario Libraro

1 0

RE: [suse-security] SuSE personal Firewall 1.1-4 / ppp*
by Reckhard, Tobias 24 Apr '02

24 Apr '02

> > filtering of outbound and inbound packets respectively. > When considered > > alone, it makes sense to check both source and destination > addresses. The > > source addresses are of higher importance, though. > > This makes a difference only, if the received packets may be > handled different depending on the destination. Of course. Packets with valid destination addresses, i.e. those with your gateway or internal machines as destinations pass the check, those with destinations not in your network fail. Note that I'm looking solely at anti-spoofing/sanity check type rules here, of course you typically need more than just these. > I don't think > that common home setups (who work with dynamic IP) have such > differences. Destination RC1918 will be dropped from *ppp* in any > case, Why will packets with destinations in RFC 1918 address space be dropped anyway? I've a feeling you're making assumptions that other rules are in place to take care of that. I'm not. > and if a port is closed or open does not depends on the > actual source. Either you may connect i.e tcp:80, or not, no > matter what the local IP currently is. Umm.. ah, yes, I think I see what you mean. And you are right, of course, that IP packets to invalid IP addresses should disappear at some point within your network, preferrably on the packet filter itself because it either uses reverse path filtering or doesn't have a valid route to the packet's destination. This applies in an entirely general fashion only if that network is properly configured, though. And the cost of performing routing sanity checks by filtering on destination IP addresses is a relatively cheap way to avoid any such dangers. The cost lies in having to modify the rules when local IP addresses change. > > If you wish to use the IP address of local machines (including > > and sometimes restricted to the gateway) as qualifiers in your > > packet filtering rules, you need to update those along with the > > IP address. > > Yes, of course, but this is exactly the point, where I don't see > advantages. It's an additional qualifier and allows you to reduce the amount of trust you need to place in other components, such as the routing code, the reverse path filter, probably some parts of the TCP/IP stack and, if applicable, your internal boxes. Perhaps it's similar to the question whether one should use a general iptables rule permitting anything with states RELATED and ESTABLISHED or employ specific ones that correspond to the individual --state NEW rules you have. The former is perfectly fine as long as you trust the iptables state engine completely. The latter still requires some trust in it, but a lot less, since you're basically just adding state to the stateless rules you'd had with ipchains. You're not replacing your ipchains logic with iptables, but rather adding iptables' state to ipchains. It's more expensive because it creates longer chains, but at least has the potential for higher security. The choice is up to oneself. > > > And let me repeat, if you don't trust your ISP, you don't know if > > > you get the correct IP assigned, but if you do, you know that the > > > ISP router will route the correct packets (destination based). > > > > Have you never seen a confused or misconfigured router? > > Yes, but malformed requests are not working anyway, except if > they are "pretty malformed" when: > > > What happens when someone breaks into the ISP and changes the > > configuration of their equipment? No, that's not the only scenario. A router could well be confused or misconfigured enough to forward RFC 1918 addresses, for example, and in some cases this might not even be confusion or misconfiguration at all. It's foolish to assume that an ISP will perform any form of packet filtering or IP sanity checks for you unless you've got an SLA. > Then you don't trust your ISP. The problem is, how can you detect if and when someone breaks into their equipment. In general that is impossible. So the default stance to take is not to place trust in your ISP. > But in this case, the intruder may > assign any IP it want's to your dyn IP interface. She may make > the ppp assign an RFC1918 address or whatever. If that's what they want to do, yes. If not, why should they? They're not forced to use the attack you deem most likely. They might even not attack you at all. Unless their aim is a short-term all-out attack on you, they'll try to be as inconspicuous as possible. > I think, this > would confuse really a lot of things and may even lead to some > failures, since a dynamic IP filter may drop packets (if the > rules are not dedicated for the external interface, for > instance). This is very likely and therefore not an attack that intelligent attackers would employ. This is all entirely hypothetical anyhow, I don't think it makes sense to discuss hypothetical situations we don't know ebough about. I am stating that there is some potential benefit to being able to use many qualifiers in packet filtering, i.e. to be able to define very finegrained rules. I am *not* saying that there's an actual benefit in any given situation. This depends entirely on the exact situation and the definitions of benefit, risk and cost in that situation. > > Break into an ISP router and configure it to establish GRE > > tunnels and you've got some very hefty potential problems. > > Well, but you should filter unneeded IP protocols (as well as TCP > ports) at all, no matter if their IP is correct. Oh, the GRE tunnel doesn't extend to your equipment, just to your border router. However, it starts out on machines under the attacker's control. It enables him to transport packets to your border that wouldn't have made it there across the Internet. Packets with RFC 1918 destination addresses, for example. > And this > attacker may spoof the correct address always; in many cases > using the correct IP would be much more easy than the wrong one. > So the intruder does not get advantages (no one I'm aware of I > mean). He can spoof as an inside machine, for one. He can also send the firewall packets directed at RFC 1918 hosts on your internal network. And those are just two examples. I don't wish to discuss them or any other specific attacks, I'm just pointing out that attacks are at least theoretically possible and you have options to defend against them. I prefer to be safe from theoretical attacks as well as those that are in widespread use. I am much more seriously worried about attackers with enough prowess to try promising but as yet theoretical attacks than script kiddies, though their sheer number makes them quite a problem, too. > Well, and so an intruder can assign your PPP stack the needed IP > anyway. So why not block any destination IP with non-public > services?! Because that's not the topic here. We're talking about anti-spoofing/routing sanity check rules, not how to prevent access to services. > > That's possible and swinging the balance between security > and ease of use > > towards the latter by some measure I don't wish to discuss. > If you can't or > > are unwilling to do without the IP address information, you > need to update > > the packet filter configuration whenever that changes. > > I think, in this case, you shouldn't think about addressing, > but on packets coming from interface *ppp* or similar. That's an additional qualifier that it makes sense to use. > And based > on such properties a filter decision should be made, and not by > dynamic rewriting, which has disadvantages as short outages. You don't necessarily have any outages, it depends how you implement the script that changes the rules. And if you don't want to filter based on destination IP addresses, be my guest and don't do it. I'm not trying to be a missionary here. I'm just saying that there can be some merit to using that information, I'm not saying it is that way in your case and I'm not saying it always makes sense. I am saying that there may well be situations where it does make sense. > No, don't take me wrong. Of course you're right. But in this > particular case, I don't see an attack szenario which would > become impossible by such a setup. And maybe I don't either. But so what? Is security about defending against known risks only? No, it's not. Sound security attempts to protect against as yet unknown dangers by following principles of sometimes philosophical nature. And defense in depth is one of them. > Another important point is KISS: keep it simple, stupid. Exactly, and it's almost always in contrast to the principle of defense in depth, since the latter involves the introduction of multiple defences, which pretty much always gives a more complicated system. It's in the balance of the principles that's applicable to a specific situation that the secret lies. There are no general answers or at least only very few. > > This, of course, leads to compromise. Those with the need > for high security > > use many layers of defence, those with assets of lower > value (or those that > > don't care or know better) employ fewer layers. In the end > it's always a > > question of cost. > > You assume that "my" setup is more insecure but more cheap. I > think this way is not more insecure, but more easy to > administrate - and by this more secure - AND more cheap :) I don't assume anything. In fact, I am not addressing you at all. I am making the *general statement* that people who need high security (should) employ more layers of defense than those who are satisfied with less security. I am not saying where you fall, I am not even saying where the line between the two is. If you will, use the extremes and assume highest security to involve an infinite number of layers, effectively making communication impossible, and assume low security to mean no layer, i.e. involving no security at all. Everyone falls inbetween somewhere. Tobias

1 0