September 2001 - openSUSE Security - openSUSE Mailing Lists

Getting hacked?
by Max Lindner 06 Sep '01

06 Sep '01

Hi out there... I've got a big problem... A few folders disappeared from my samba-dir (unfortunately they where the importantest i ever had :( ). Well that's not the real problem. After this I've checked /var/log/messages and got the following: Sep 5 22:18:21 monika sshd[2616]: Did not receive ident string from 62.225.211.70. Sep 5 22:18:23 monika sshd[2623]: Did not receive ident string from 62.225.211.70. Sep 5 22:18:26 monika in.ftpd[2615]: connect from 62.225.211.70 (62.225.211.70) Sep 5 22:18:26 monika in.telnetd[2617]: connect from 62.225.211.70 (62.225.211.70) Sep 5 22:18:26 monika in.fingerd[2618]: connect from 62.225.211.70 (62.225.211.70) Sep 5 22:18:26 monika popper[2619]: connect from 62.225.211.70 (62.225.211.70) Sep 5 22:18:26 monika popper[2619]: error: cannot execute /usr/sbin/popper: No such file or directory Sep 5 22:18:26 monika fingerd[2618]: getpeername: Transport endpoint is not connected Sep 5 22:18:26 monika ftpd[2615]: getpeername (in.ftpd): Transport endpoint is not connected Sep 5 22:18:31 monika in.ftpd[2622]: connect from 62.225.211.70 (62.225.211.70) Sep 5 22:18:33 monika in.telnetd[2624]: connect from 62.225.211.70 (62.225.211.70) Sep 5 22:18:34 monika telnetd[2624]: ttloop: peer died: EOF Sep 5 22:18:36 monika in.fingerd[2625]: connect from 62.225.211.70 (62.225.211.70) Sep 5 22:18:38 monika popper[2626]: connect from 62.225.211.70 (62.225.211.70) Sep 5 22:18:38 monika popper[2626]: error: cannot execute /usr/sbin/popper: No such file or directory When I'm not wrong, this says that someone was very interested about my router. Unfortunately there wasn't any firewall and no good protection (what was I stupid...) How can I see if he got in my system and deleted my folders? Can you say me, what signs indicate that he is already in my router. Is there a way to hide a programm from ps -axl? Thanks for any help! Max --- I'm securing my system now...

7 7

No reply since several days, need HELP!!!
by Stefan_Walther＠gehag-dsk.de 06 Sep '01

06 Sep '01

Hi folks, some days ago I wrote an email to these lists. I have a problem with getting some data through a FreeS/WAN tunnel. The first mail are coming back tells me something about strange routing. There was a fault at my side, because I had a double writing error in the IP's. I correct this in the mail from 1st september. As I wrote my first mail I get so much replies that I cannot solve them at one day, as I found time to do this. Now I cannot understand, why there is no reply anymore. I need HELP!!! A colleague of me wrote a mail yesterday to the suse-security-list. MfG. Stefan Walther stefan_walther(a)gehag-dsk.de dienst.: +4930/89786448 Funk: +49172/3943961

1 0

ssh and harden_suse
by Wagner, Uwe 06 Sep '01

06 Sep '01

Hi, I want to use OpenSSH to connect to a server on which the harden_suse script was installed. If I try 'ssh servername' the connection was refused by the server. The message is : ssh_exchange_identification. If I try to connect with ssh to another server with not installed the harden_suse script, it works. I'm using SuSE 7.1 with the OpenSSH patch. Any idea ? uwe <<Wagner, Uwe.vcf>>

2 1

RE: [suse-security] ssh and harden_suse
by Reckhard, Tobias 06 Sep '01

06 Sep '01

> Once a connection to a remote machine was established 1st time, the > identificantion > will be written to ~/.ssh/known_hosts. If the ID of a remote machine > changes, e.g. > cause someone installs it new, you'll get such messages while connecting. > > Simply remove the part in ~/.ssh/known_hosts that depends on this machine. > Note that this method of operation is less secure than if you have the option "StrictHostKeyChecking yes" set, which disables automatic addition of host keys to the known hosts files and will abort any connection attempt to a host whose key differs from the one in the known hosts files. Without StrictHostKeyChecking, you are prone to the man-in-the-middle attacks that Kurt made such a fuss about around a half a year ago. Cheers Tobias

1 0

security updates
by adm 06 Sep '01

06 Sep '01

I'm not sure if there was an announcement about this before, but do those of us using 6.2 and below no longer receive updated packages for items that are found faulty? -- aron

4 3

RE: [suse-security] ssh and harden_suse
by Appeldorn 06 Sep '01

06 Sep '01

-----Original Message----- From: Appeldorn [mailto:appeldorn@codixx.de] Sent: Thursday, September 06, 2001 9:57 AM To: Wagner, Uwe Subject: RE: [suse-security] ssh and harden_suse >I want to use OpenSSH to connect to a server on which the harden_suse script >was installed. >If I try 'ssh servername' the connection was refused by the server. The >message is : ssh_exchange_identification. >If I try to connect with ssh to another server with not installed the >harden_suse script, it works. Think not the harden script is the point, but your known_hosts file. Once a connection to a remote machine was established 1st time, the identificantion will be written to ~/.ssh/known_hosts. If the ID of a remote machine changes, e.g. cause someone installs it new, you'll get such messages while connecting. Simply remove the part in ~/.ssh/known_hosts that depends on this machine. Michael

1 0

secure-rsync-mirroring
by Daniel Quappe 06 Sep '01

06 Sep '01

hi list, today i wanted to mirror two hosts by using rsync with ssh. unfortunately this are a 6.4 and 7.1 suse-system with different rsync-version (6.4 => rsync-2.3.2-22, 7.1 => rsync-2.4.6-37). after the first mirroring (got a complete list of all relevant files, okay) the next time i executed my script i got the following error: ... receiving file list ... done unexpected EOF in read_timeout i tested some hints (--timeout=1000 etc.) but nothing has lead to success. does anyone out there know the solution? many thanks in advance, daniel -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net

3 2

ssh problem
by Yuri Robbers 05 Sep '01

05 Sep '01

Hi all! I want to use OpenSSH 2.9 as shipped with SuSE 7.2 to transfer data between two servers. Such a setup has recently been discussed in this list, but in my particular situation a previously unmentioned problem arises. I have created DSA keys with ssh-keygen and copied the public keys of each machine to the other. So far, so good. But there is a complication: one of the machines is registered in my ISP's DNS records with two A records (once with a nasty name consisting of parts like the hexadecimal ip address, and once with an easier-to-remember name). So now the problem arises: I normally only use the easy-to-remember hostname: it's the one I named the machine with (not even telling it about the other one) and this is therefore also the one that ssh-keygen uses when generating the keys. Unfortunately ssh, scp and sftp resolve the IP-address to the other hostname, and fail to recognize the relevant key in $HOME/.ssh/authorized_keys2 (regardless of which "direction" I go). I assume there is an easy way to solve this, but I haven't found it. Can someone help me out? Kind regards, Yuri. -------------------------------------------------------------------------- Yuri Robbers phone : +31-71-527-4966 Leiden University fax : +31-71-527-4900 Institute for Theoretical Biology email : robbers(a)rulsfb.leidenuniv.nl Kaiserstraat 63 2311 GP Leiden PGP 5.0 public key available: the Netherlands Check your favourite hkp server. --------------------------------------------------------------------------

1 0

freeswan ???
by Dirk Ertl 05 Sep '01

05 Sep '01

Helo folks, some times ago a friend of my posted here a problem with freeswan what we have. In his first posting he made confound a network address and fixed it in last with petition for help. Is someone know about freeswan problems like this and give us an initial stage for a resulution? Thanks in advance Dirk >Hi folks, >I recognize a problem at my side. You meant "strange routing". Now I see >what you mean. >The IP's of the first GW on eth0 must be 192.168.200.1 and the IP on the >eth1 of the second GW must be 192.168.100.1. >Now I see my fault. The IP's on the boxes where set this way I told to you >in the sentence before. >By the way, I have a look at /var/log/messages and saw the message IPSec >SA established and tcpdump tells me that there are UDP:500-->500 packets >are going through the router (ip-proto-50). >I have an established IPSec-tunnel between 2 boxes. >I'm using SuSE7.1 Kern 2.4.7 and FreeS/WAN 1.91. The FreeS/WAN tells me that the >tunnel is established (last message in /var/log/messages). >My configuration is the following: >1st client-----1st-FreeS/WAN-gateway----ROUTER----2nd-FreeS/WAN-gateway------2nd-client > eth0--------------eth0------eth1----eth1-eth0----eth0--------eth1------eth0 > Virtuelles Internet between eth1 and eth0 ROUTER >Every box is a linux box! >The 1st client has the following config: RedHat7.1, IP: 192.168.200.2 >The 1st FreeS/WAN-gateway config is: SuSE 7.1, kernel 2.4.7, eth0: 192.168.100.1, eth1: 172.16.100.1, IP-forwarding without masquerading >The Router has the following config: SuSE7.1, kernel 2.4.7, eth1: 172.16.100.2, eth0 10.16.100.2, IP-forwarding without masquerading >The 2nd FreeS/WAN-gateway config is: SuSE7.1, kernel 2.4.7, eth0: 10.16.100.1, eth1: 192.168.200.1, IP-forwarding without masquerading >The 2nd client has the following config: Windows2000, eth (seems to be a littlebit stupid): 192.168.100.2 >Every netmask is 255.255.255.0; >If i start ipsec via, ipsec start at the shell, no error (exept the IPv6-bind error) occured. >Before starting IPSec the routes, the the clients can pinging each other are set by hand. FreeS/WAN sets the routes to the ipsec0 interface. >After starting you cannot ping anymore from the 1st client to the 2nd client ans the other way around. Does anybody know a solution for this problem??? >THX -- Dirk Ertl networktechnican fon : +49 179/492 63 59 mailto : dirk(a)ertl-bln.de

1 0

[suse-security] Howto spread around the ext ip adress
by Stefan Knodt 05 Sep '01

05 Sep '01

Hi, since the external adress is assigned via dhcp and changes from time to time. What ist the most secure way to spread around the external ip adress to systems behind the firewall, e.g. in a masqueraded DMZ ? BTW the systems behind the firewall runs various OS. Thanks for your advice Stefan --------------------------- sknodt(a)bluewin.ch ---------------------------

2 1

scp/sftp and chroot (OpenSSH)
by Ulf Stegemann 05 Sep '01

05 Sep '01

The following message is a courtesy copy of an article that has been posted to comp.security.unix,comp.os.linux.security as well. On our servers there exist serveral chroot accounts where users can log in and find themselves caged in their home directory. This works for telnet, ftp and ssh (OpenSSH 2.5.1). However, scp and sftp can't be used with these accounts, they simply hang after authentication. Searching the net I found that that's a known problem and that it could be solved using ssh3 (which is not an option for me) or a chroot-patch for OpenSSH together with statically compiled ssh binaries. The latter one didn't work for me and I'm wondering if anybody has another solution for the problem that a) works with OpenSSH and b) does not require to change /etc/passwd. Ulf -- not a real signature

1 0

SuSE Security Announcement: screen (SuSE-SA:2001:030)
by Roman Drahtmueller 05 Sep '01

05 Sep '01

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: screen Announcement-ID: SuSE-SA:2001:030 Date: Wednesday, September 5 2001 18:00 MEST Affected SuSE versions: (6.0, 6.1, 6.2) 6.3, 6.4, 7.0, 7.1, 7.2 Vulnerability Type: local root compromise Severity (1-10): 5 SuSE default package: yes Other affected systems: some systems with the screen program installed setuid root Content of this advisory: 1) security vulnerability resolved: screen 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 screen is a terminal multiplexer program that allows reattaching to a detached session as well as multi-attached (shared) sessions. The screen package allows a local attacker to obtain root privileges if the /usr/bin/screen command is installed setuid root and if a directory below /tmp/screens/ exists. The screen program needs root permissions from the setuid-root bit for two reasons: multi-attached sessions are only possible with root privileges, and writing terminal allocation information to /var/run/utmp (the who(1) and finger(1) commands). If the screen command is not running with special privileges, all functionality except these two features will continue to work, but the local root compromise will not be possible. In order to provide the features mentioned, the screen package used to be installed setuid-root in SuSE Linux distributions. The update packages that we provide for the supported distributions 6.3, 6.4, 7.0, 7.1 and 7.2 eliminate the error in the source code. In addition to that, the rpm package does not contain the setuid-bit on the screen program any more. If there is any more security-related bug in the screen package or libraries that it is linked against to be found in the future, these errors will not open local security holes any more. Users of the screen package who need the multi-attach feature must enable it again by adding the setuid-bit to the /usr/bin/screen file. Please note that you should reflect the changes to permissions in the files /etc/permissions*. If unsure, use the setting "secure local" for the variable PERMISSION_SECURITY in /etc/rc.config and execute "SuSEconfig" as root. Alternatively, change the settings for the screen program in /etc/permissions* and run "chkstat -set <file>" for each file that you need. Use the command "rpm -qlv screen | grep /usr/bin" to find out which files to add to the permissions file (/usr/bin/screen is a symlink). The authors of screen have released the new version screen-3.9.10 that fixes the multi-attach-error, and some other uncritical bug. Our update packages contain the necessary patches applied to the version as shipped with the original distribution. We thank Christian Hürgemann <Bzrker(a)t-online.de> for reporting this error on Monday, 3 Sep 2001. 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 -Uhv file.rpm" to apply the update. i386 Intel Platform: SuSE-7.2 ftp://ftp.suse.com/pub/suse/i386/update/7.2/ap1/screen-3.9.8-115.i386.rpm e85453f50170ecdabe97dd2b33b51e4a source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/screen-3.9.8-115.src.rpm 74ac0119ec42f7c5ad4405a7f1c00f6a SuSE-7.1 ftp://ftp.suse.com/pub/suse/i386/update/7.1/ap1/screen-3.9.8-115.i386.rpm fb0a3ba99db246c1f08e3814557858ae source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.1/zq1/screen-3.9.8-115.src.rpm 5edb0caa388be9f1ddc2cd4d0a4f3a54 SuSE-7.0 ftp://ftp.suse.com/pub/suse/i386/update/7.0/ap1/screen-3.9.8-115.i386.rpm b7bfa891b49db29093f6ab1830d84838 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.0/zq1/screen-3.9.8-115.src.rpm fb1e3bf070adec10296a59f2d1231c8c SuSE-6.4 ftp://ftp.suse.com/pub/suse/i386/update/6.4/ap1/screen-3.9.8-115.i386.rpm a889c9090b0a64eb57a407ee00444491 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/6.4/zq1/screen-3.9.8-115.src.rpm 29b6e24378153a4f9d2445414253759c SuSE-6.3 ftp://ftp.suse.com/pub/suse/i386/update/6.3/ap1/screen-3.9.8-115.i386.rpm 5a47bdc2407890d9a940c710d4806383 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/6.3/zq1/screen-3.9.8-115.src.rpm f3bace3114cfcb9b1b6e798ea8b93b34 Sparc Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/sparc/update/7.1/ap1/screen-3.9.8-61.sparc.rpm 3bfe4ac28d54ff2cab6582b2d09f3b75 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.1/zq1/screen-3.9.8-61.src.rpm 17da9f63ec2b0d48b3593dacfe341a7b SuSE-7.0 ftp://ftp.suse.com/pub/suse/sparc/update/7.0/ap1/screen-3.9.8-62.sparc.rpm 13037ae193ebd81b92ce1d94d2409421 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.0/zq1/screen-3.9.8-62.src.rpm c542f1c51a701ad5dd06d9f9f3701cfb AXP Alpha Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/axp/update/7.1/ap1/screen-3.9.8-71.alpha.rpm c5239b5ca727a4f7d54589399b62a5c5 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/7.1/zq1/screen-3.9.8-71.src.rpm 4c389bca8641e3c081e992e82bc5065d SuSE-7.0 ftp://ftp.suse.com/pub/suse/axp/update/7.0/ap1/screen-3.9.8-71.alpha.rpm 9f84734233284fc9f7be494c37a4f857 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/7.0/zq1/screen-3.9.8-71.src.rpm 31920bb58b696739100e75ce363ade6d SuSE-6.4 ftp://ftp.suse.com/pub/suse/axp/update/6.4/ap1/screen-3.9.8-71.alpha.rpm a7f64468ecc5be193795ea3a530d3ead source rpm: ftp://ftp.suse.com/pub/suse/axp/update/6.4/zq1/screen-3.9.8-71.src.rpm dae933854ae9a7efd3e80e09641b9963 SuSE-6.3 ftp://ftp.suse.com/pub/suse/axp/update/6.3/ap1/screen-3.9.8-71.alpha.rpm f66d9c18a27cd7915d5134528b47c342 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/6.3/zq1/screen-3.9.8-71.src.rpm 13157d46457be72fd7684ca0cbe6c49b PPC Power PC Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/ppc/update/7.1/ap1/screen-3.9.8-52.ppc.rpm 090e4781fb4949697fb08f755a0ae12d source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.1/zq1/screen-3.9.8-52.src.rpm ce19f08412c6517798690fa7d99ed690 SuSE-7.0 ftp://ftp.suse.com/pub/suse/ppc/update/7.0/ap1/screen-3.9.8-52.ppc.rpm e37b478c4ce85febc13785b4a48c68c0 source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.0/zq1/screen-3.9.8-52.src.rpm 0594837833e05e430c52421745f1abfa SuSE-6.4 ftp://ftp.suse.com/pub/suse/ppc/update/6.4/ap1/screen-3.9.8-52.ppc.rpm 53cb3d0fdf964a4013b6aed326d77c9e source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/6.4/zq1/screen-3.9.8-52.src.rpm 89300f304c709a10975f5906bedd1529 ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - sendmail SuSE Security announcement SuSE-SA:2001:028 (sendmail) offers a sendmail update package for the 7.0-i386 distribution that has a lower version number than the package in the tree for ftp installation on ftp.suse.com. If your update rpm command fails with a complaint that the version installed is newer than the one you wish to be installed, then please use the "--oldpackage" commandline option to rpm: "rpm --oldpackage -Uhv sendmail-*.rpm". We are correcting the problem as soon as possible. The new package will be named sendmail-8.11.0-10.i386.rpm and should appear on the ftp server within the next 11 hours. The *-10 package is technically identical to the *-5 package that is currently available on our ftp server. ______________________________________________________________________________ 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>. The <security(a)suse.com> 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 mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh 1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+ cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7 tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63 Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+ x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0 Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2 saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o L0oixF12CpkBogQ57vSBEQQAk/GN+ftr7+DBlSoixDDpfRnUk+jApGEt8hCnrnjV nPs/9Cr33+CXLQbILOO7Y5oiPbJdHh45t4E0fKyLVzDerCRFB1swz/mNDxT26DLy sdBV5fwNHTPhxa67goAZVrehQPqJEckkIpYriOaYcKpF3n5fQIZMEfMaHEElQhcX ML8AoJVXDkJYh7vI8EUB8ZURNLZMEECNA/sH0MCnb4Q6ZcRyeZ3+1PHP8hP73b6T epRdLZhaylwVF/iu7uIn62ZUL4//NTOCDY7V63qg4iba/fUbOsWtEnGaiE7mQuAl sSWvRspwRA9/g9rdVf3/JdLJrLmKBTheyG+PSJE3W7cAE4ZWafGxIRCwXhmj3TQn Jn2euqylHRubEQP/aL53NZK0kBdvrKgff6O8Of6tqoss8Dkk55I7QVFSp+My1Dn+ mngQKFejTAgtyo/WmR3wPjQ9HoT2lRiYI2lTRYT4uMdHuwVC3b4DqAKmoy375FER wHkrMVyKBJslv8QtbAWw5A1CAUseaHo+91wmYJ4/4p6YUahqbG/tZyhbxfq0KFN1 U0UgUGFja2FnZSBTaWduaW5nIEtleSA8YnVpbGRAc3VzZS5kZT6IXAQTEQIAHAUC Oe70gQUJA8JnAAQLCgMEAxUDAgMWAgECF4AACgkQqE7a6JyACspfLACffAYA+NM8 NBhyRyH+nTX58CNjwLIAoIx9fj52BJe0xY7WbKoXs1+72b2AiEYEEBECAAYFAjpw XlIACgkQnkDjEAAKq6TczgCgi+ddhWb7+FWcfeE6WwPZccqAHowAnjjtRyGwHLQH r5OTFAYTXi2Wv6jNiQEVAwUQOnBgb3ey5gA9JdPZAQE1pwf/QJ+b34lFBNVUJ7fk /xGJJREt7V12iSafaRzGuH8xWvIz1bb+VARxnnt16FDQ1cDNjoEhCEmcW83Vxp6i JXE9PE8wVA/Yue/bon5JS7J69+UiQ2eq2pudfwljp52lYVM53jgPYEz0q/v3091n lZ8CYkAkN9JDS1lV1gEzJ7J0+POngDpU+lDQT2EC6VKaxeWK8pNt6UFDwICRDQxK nlOoiDvTrdWT7QdJZ4sPv8Qotdw9+tKNbWQ2DqdIRxyTdw9xDfAtcj6mXeQr7852 Lwem1gSKVnEYHZ9g1FTJqVOutY8KhpUc9RfOCRv8XuIxrs4KSbfSF0s8qIRCQelx ufg9AbkCDQQ57vSSEAgAhJHQTejMX+Vr6g1pHDEcusJ63fQ2CfFFE5iE9okH9O7U VCiSfb9CV38dmeHdPCEEjDUWquFYEnvj3WICMtH249t1Ymuf4Du3yRKQ9oXdn/qT Jzlrx9qzjiG3mH7ocwHOgUIwCrZoEdBEVE2n0zPVm+hddwjWWTWXw6pxQz+i9dsN 89xexRV5M9O0bNwCLaNWX2GXeLAkqTK/9EuZy6x2yLxi6du9YYUAXkZpqBhCjtiU XpRoFCdglMznbcAyCk9C2wqb2j/D1Z2BeSBaGCSFkR6pRLebnE17LWcu72Iy+r0z +JecbPiyDpDZj4apn7IC81aNFGi7fNITsHODbwwjiwADBgf/YPvVdzkc8OC7ztac EWCanwylKvxCdKzTDA+DfES6WUYShyiVJvZzRy25LJ5WcK20kzOS6Qv1OrIXiz/p dGy1aKtJZrAnFEsofpmOj8VoqyyFgp/yAGQBp12+mXek7SCZRhuqalDfEMRiWEJ6 J5dLkyShyRDWyPbFh0HXE7QTHN+IKKxxQqNQXL6Z3NSxS61p+5n6BseiDUI39xxk KTFwFrkgUIc5Gs2Or2lhaWvGwSfoCmwbsklszZt6xbU+R0SjFqTvjPWx6eHfqbmN C9WMDdTjGrXDDKXFp2aYlokfN6It9vsbVlGNlOwHt/JjGoPMxW6Xqj0FLA7/Vewg CdXW64hMBBgRAgAMBQI57vSSBQkDwmcAAAoJEKhO2uicgArKSyIAmwUHf/vtKQfc mVg4asR7U6XQl0bAAJ4pO22B5U8UH6IYl2LBCXFqw5+5fA== =rVRn - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBO5ZTFHey5gA9JdPZAQHosAf/drLZSUCL8y3JyAd9EfzXg4OctE245mjb HrAn+jgXNDHvL8SzQYFpIzt5hLiJ9WLXc0+Edu3ovKkhzCJOtWIXTu2dvOiRhF99 MO3iaqWF3J+HhGMOEr2sQWsiqVKF5Mdw13SPgiwTX3le9ropXAD8gvZCoG7WjCpb nqIbbVlY2zrxdCuoDVeLrH3FJS1TksUcga/+pdJqaPG1YgdV+UFMFbTnpEITXyNT s9vB553vw9paFf9a4LGwoht3BpwtvnPRTjQlfgApJPvMbFjTGers824cT5xOjpPz pafJ3QG9ZbiD+49yY4wXMsmBNdohGM4CFsmV5Sc8aOXFenA26Kbg4Q== =tYiI -----END PGP SIGNATURE-----

1 0

Re: [suse-security] firewall2 and SPOOFIN
by James Bliss 05 Sep '01

05 Sep '01

I believe the problem is in your FW_MASQ_NETS setting. Ping is an ICMP protocol. Why don't you try to open this up completely (internalnet/8-16-or24 - whichever appropriately applies. then test to seen what happens. then you can start restricting this more and more to tighten the controls as needed. Jim 09/05/01 10:57:34 AM, "Anthony Hogbin" <anthony.hogbin(a)btinternet.com> wrote: >Hello > >I am running repeatedly into a brick wall here over SuSEfirewall2 > >Three NIC's - a real IP DMZ, a masqueraded LAN on 192, and a DSL router >which is my DFG and name server. > >I can do most stuff I hoped it would do when I sat down and figured out what >I needed - like web, mail, imap, ssh, MSN IM blah blah. BUT I CANNOT PING. > >No where on the network can ping at all. > >Masqueraded clients can resolve but then nothing. > >This is what I get in the /var/log/firewall (where 14 is the router - and >the 192 address is the test client): > >Sep 5 15:40:40 prometheus kernel: SuSE-FW-DROP-ANTI-SPOOFIN=eth0 OUT= >MAC=00:01:02:24:8b:9a:00:20:6f:09:7c:b5:08:00 SRC=217.34.212.14 >DST=217.34.212.2 LEN=315 TOS=0x00 PREC=0x00 TTL=60 ID=42849 PROTO=UDP SPT=53 >DPT=1027 LEN=295 > >....this is just one example of many SPOOF issues - but the one that I think >points the strongest towards my current issues. > >With a bit of luck the act of asking for help will bring some >enlightenment?! > >---- > >For your entertainment (take it easy on me!) is the setup > ># 2.) >FW_DEV_EXT="eth0" > ># 3.) >FW_DEV_INT="eth2" > ># 4.) >FW_DEV_DMZ="eth1" > ># 5.) >FW_ROUTE="yes" > ># 6.) >FW_MASQUERADE="yes" >FW_MASQ_DEV="$FW_DEV_EXT" >FW_MASQ_NETS="$INT_LAN_RANGE,0/0,tcp,20 $INT_LAN_RANGE,0/0,tcp,21 >$INT_LAN_RANGE,0/0,tcp,22 $INT_LAN_RANGE,0/0,tcp,23 >$INT_LAN_RANGE,0/0,tcp,25 $INT_LAN_RANGE,0/0,tcp,37 >$INT_LAN_RANGE,0/0,udp,37 $INT_LAN_RANGE,0/0,udp,43 >$INT_LAN_RANGE,0/0,udp,53 $INT_LAN_RANGE,0/0,tcp,53 >$INT_LAN_RANGE,0/0,tcp,80 $INT_LAN_RANGE,0/0,tcp,110 >$INT_LAN_RANGE,0/0,tcp,113 $INT_LAN_RANGE,0/0,tcp,123 >$INT_LAN_RANGE,0/0,udp,123 $INT_LAN_RANGE,0/0,tcp,143 >$INT_LAN_RANGE,0/0,tcp,443 $INT_LAN_RANGE,0/0,tcp,554 >$INT_LAN_RANGE,0/0,tcp,993 $INT_LAN_RANGE,0/0,tcp,1863 >$INT_LAN_RANGE,0/0,tcp,2401 $INT_LAN_RANGE,0/0,tcp,5800 >$INT_LAN_RANGE,0/0,tcp,5900 $INT_LAN_RANGE,0/0,tcp,6800:6900 >$INT_LAN_RANGE,0/0,udp,6800:6900 $INT_LAN_RANGE,0/0,tcp,6901 >$INT_LAN_RANGE,0/0,udp,6901 $INT_LAN_RANGE,0/0,tcp,6970:7170 >$INT_LAN_RANGE,0/0,tcp,7070" > ># 7.) >FW_PROTECT_FROM_INTERNAL="yes" > ># 8.) >FW_AUTOPROTECT_SERVICES="yes" > ># 9.) >FW_SERVICES_EXT_TCP="" >FW_SERVICES_EXT_UDP="" # Common: domain >FW_SERVICES_EXT_IP="" >FW_SERVICES_DMZ_TCP="53 3128" >FW_SERVICES_DMZ_UDP="53" >FW_SERVICES_DMZ_IP="" >FW_SERVICES_INT_TCP="23 53 3128" >FW_SERVICES_INT_UDP="53" >FW_SERVICES_INT_IP="" > ># 10.) >FW_TRUSTED_NETS="$EXT_ZFT_GATE,tcp,22" > ># 11.) >FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" >FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" > ># 12.) >FW_SERVICE_AUTODETECT="yes" # Autodetect the services below when starting >FW_SERVICE_DNS="yes" >FW_SERVICE_DHCLIENT="no" >FW_SERVICE_DHCPD="no" >FW_SERVICE_SQUID="yes" >FW_SERVICE_SAMBA="no" > ># 13.) >FW_FORWARD="$INT_LAN_RANGE,$DMZ_IP_RANGE 0/0,$DMZ_EXCHANGE,tcp,25 >0/0,$DMZ_EXCHANGE,tcp,80 0/0,$DMZ_EXCHANGE,tcp,135 0/0,$DMZ_EXCHANGE,tcp,443 >0/0,$DMZ_BACKUP,tcp,21 0/0,$DMZ_BACKUP,tcp,20" > ># 14.) >FW_FORWARD_MASQ="" # Beware to use this! > ># 15.) >FW_REDIRECT="" > ># 16.) >FW_LOG_DROP_CRIT="yes" >FW_LOG_DROP_ALL="yes" >FW_LOG_ACCEPT_CRIT="no" >FW_LOG_ACCEPT_ALL="no" >FW_LOG="--log-level warning --log-tcp-options --log-ip-option --log-prefix >SuSE-FW" > ># 17.) >FW_KERNEL_SECURITY="yes" > ># 18.) >FW_STOP_KEEP_ROUTING_STATE="yes" > ># 19.) >FW_ALLOW_PING_FW="no" >FW_ALLOW_PING_DMZ="no" >FW_ALLOW_PING_EXT="yes" > > > >-- >To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com >For additional commands, e-mail: suse-security-help(a)suse.com > >

1 0

Re: [suse-security] Kernel
by Hendrik Brandenburger 05 Sep '01

05 Sep '01

Am Mit, 05 Sep 2001 schrieb Eduard Meiler: > > Hallo , can anybody tell me what all of this mean ?? > > > > Sep 5 00:06:35 wall kernel: eth0: Transmit error, Tx status register 82. >Hi, >just one question. Do you have a ethernetcard with the Realtek9029-Chip in ^^ Sorry, I mean 8029. Greetings Hendrik --

1 0

SuSE Firewall 2 - Masq , IRC
by Michael Brandejsky 05 Sep '01

05 Sep '01

Dear List, i have Suse 7.2 Pro and the SuSE Firewall2 , ftp, www masquerade works fine but i have a problem to tranfer DCC Files in IRC , time ago there are some IRC Masq Modules, but they are not compatible to the 2.4.x Kernel. So , what should I do to use DCC Sends. I don't want to install an old kernel. greetings

2 1

Kernel
by Eduard Meiler 05 Sep '01

05 Sep '01

Hallo , can anybody tell me what all of this mean ?? Sep 5 00:06:35 wall kernel: eth0: Transmit error, Tx status register 82. Sep 5 00:06:35 wall kernel: Flags; bus-master 1, dirty 17668(4) current 17668(4) Sep 5 00:06:35 wall kernel: Transmit list 00000000 vs. c74f2300. Sep 5 00:06:35 wall kernel: 0: @c74f2200 length 80000586 status 00010586 Sep 5 00:06:35 wall kernel: 1: @c74f2240 length 80000586 status 00010586 Sep 5 00:06:35 wall kernel: 2: @c74f2280 length 80000586 status 00010586 Sep 5 00:06:35 wall kernel: 3: @c74f22c0 length 80000586 status 80010586 Sep 5 00:06:35 wall kernel: 4: @c74f2300 length 80000056 status 00010056 Sep 5 00:06:35 wall kernel: 5: @c74f2340 length 80000056 status 00010056 Sep 5 00:06:35 wall kernel: 6: @c74f2380 length 8000002a status 0001002a Sep 5 00:06:35 wall kernel: 7: @c74f23c0 length 8000003e status 0001003e Sep 5 00:06:35 wall kernel: 8: @c74f2400 length 8000004a status 0001004a Sep 5 00:06:35 wall kernel: 9: @c74f2440 length 80000055 status 00010055 Sep 5 00:06:35 wall kernel: 10: @c74f2480 length 80000063 status 00010063 Sep 5 00:06:35 wall kernel: 11: @c74f24c0 length 80000036 status 00010036 Sep 5 00:06:35 wall kernel: 12: @c74f2500 length 80000057 status 00010057 Sep 5 00:06:35 wall kernel: 13: @c74f2540 length 80000071 status 00010071 Sep 5 00:06:35 wall kernel: 14: @c74f2580 length 80000042 status 00010042 Sep 5 00:06:35 wall kernel: 15: @c74f25c0 length 80000047 status 00010047 Sep 5 00:15:17 wall su: (to nobody) root on none Sep 5 00:15:17 wall PAM-unix2[4185]: session started for user nobody, service su Sep 5 00:17:04 wall PAM-unix2[4185]: session finished for user nobody, service su Mit freundlichen Grüßen Eduard Meiler ___________________________

6 5

RE: [SLE] SuSEfirewall2 questions ?
by Eric Romang 05 Sep '01

05 Sep '01

Hello, Thanxs for your answer. I have uninstall SuSEfirewall1 and personnal suse firewall in the method you give. Thxs ;) I wan't to know how to make an upgrade of SuSEFirewall2 there is a new version on http://www.suse.de/~marc Yes I use SSH to log remotely ;) For DHCPD, my ps -aux give me this : root 611 0.0 0.2 1364 636 ? S 13:13 0:00 /sbin/syslogd -a /var/lib/dhcp/var/run/dhcpd.pid Why DHCPD has an process with syslog ?? I don't have lunch DHCPD on startup... I don't wan't dhcpd... In my rc.concfig START_DHCPD is set to no... but they are some pid ... But I don't understand why my server freeze whitout reason... Regards > -----Original Message----- > From: Jaakko Tamminen [mailto:jtamminen@satabaana.net] > Sent: 05 September 2001 12:58 > To: Eric Romang > Subject: Re: [SLE] SuSEfirewall2 questions ? > > > Hi > > Disable personal-firewall, that blocks all outside connection attempts, > and that seems to be the case for You. > > To remove the "old" susefirewall, do it with yast->install/remove > packages, or you can try someting like "rpm -e SuSEfirewall". The name > must be correct, but I believe it might be that one. > > Actually there is no need to remove the "old" firewall, just don't > enable it. In my server I have both installed the same time, and the > only annoying thing is that there is both entrys in configuration file, > but it does not really matter. > > I hope You are using ssh to log remotely...? > > About dhcp.. I did not really understand Your question.. Do you need > DHCP-client to get Your IP for the server? If so, You need to enable > that (start dhcp), and also in firewall configuration section you need > to set "dhcp client" to YES. > > Hope this helps > > Jaska. > > > > > > > Hello, > > > > I have install SuSEfirewall2 on my serveur with two ethernet card. > > One for the private network, the other to the internet. > > > > I have some crash from the server I can't explain. > > The server freeze and i don't have the hand on it... no more root > > login possible > > and the tty are froozen... > > > > I have no error messages in my message log file, and also in my > > firewall message. > > > > But I have this line in my message log and warm message. > > > > My message log messages : > > > > Sep 6 12:04:36 lithium SuSEfirewall2: Firewall rules successfully > > set from /etc/rc.config.d/firewall2.rc.config > > Sep 6 12:04:36 lithium /sbin/SuSEpersonal-firewall: > > SuSEpersonal-firewall: Loading of module ipchains was not successful. > > Sep 6 12:04:36 lithium /sbin/SuSEpersonal-firewall: Aborting. No > > action taken. > > > > My warm log messages : > > > > Sep 6 12:04:35 lithium kernel: ip_tables: (c)2000 Netfilter core > > team Sep 6 12:04:35 lithium kernel: ip_conntrack (2047 buckets, > > 16376 max) Sep 6 12:04:36 lithium /sbin/SuSEpersonal-firewall: > > SuSEpersonal-firewall: Loading of module ipchains was not successful. > > Sep 6 12:04:36 lithium /sbin/SuSEpersonal-firewall: Aborting. No > > action taken. > > > > I have also, my sylogd how run dhcp, but i don't have start the dhcpd > > on startup... > > I can see a line in process... > > > > Somebody can explain me why my server freeze ?? > > > > And another question, I wan't to upgrade my SuSEfirewall2. > > What are the step to remove the old one ? > > > > Thanxs. > > Regards > > > > Eric Romang - System Administrator > > eric.romang(a)synapse.lu > > --------------------------------------------------------------------- > >------- --------- > > Site : http://www.synapse.lu > > Synapse Internet Services > > 49, Bd. G-D. Charlotte, L-1331 Luxembourg > > Tel : +352 / 44 79 44 77 > > Fax : +352 / 44 79 44 79 > > GSM : +352 / 021 7000 35 > > --------------------------------------------------------------------- > >------- --------- > > ---------------------------------------- > Content-Type: text/html; charset="iso-8859-1"; name="Liite: 1" > Content-Transfer-Encoding: quoted-printable > Content-Description: > ---------------------------------------- >

2 2

Firewall-SUSE 7.0
by Juergen Foag 05 Sep '01

05 Sep '01

Hello, on SUSE-LINUX 7.0, kernel 2.2.16, I've installed the firewall in the sense of a packet-filter (no proxies, no DMZ, no masquerading). From an firewall-external host (192.168.0.3), I tried to establish a connection (ssh, ping or http with our internal webserver (xx.yy.zz.15)) but have failures. The network topology is: external firewall firewall internal argos eth1 eth0 webserver 192.168.0.3 192.168.0.2 xx.yy.zz.42 xx.yy.zz.15 In the case of trying to connect from the external web client our Webserver http://xx.yy.zz.15, the var/log/firewall-file on the firewall host notices: kernel: Packet log: forward ACCEPT eth0 PROTO=6 192.168.0.3:36341 xx.yy.zz.15:80 With ethereal, I've logged on the internal interface (eth0) of the dual-homed firewall-host the message: Source Destination Protocol Info argosxx.yy.zz.42 xx.yy.zz.15 TCP Source Port 36345 > Dest. Port http (80) So I conclude, that my web request toward my webserver is handled correctly. But with ethereal on the webserver interface, I cannot receive the request message (going to port 80 http). After the web client request was timed out, the message on the web client host (argos) sends "unable to connect to server". The firewall.rc.config file looks like: # 2.) FW_DEV_WORLD="eth1" FW_DEV_WORLD_eth1="192.168.0.2 255.255.255.0" # 3.) FW_DEV_INT="eth0" FW_DEV_INT_eth0="xx.yy.zz.42 255.255.255.0" # 4.) FW_DEV_DMZ="" # 5.) FW_ROUTE="yes" # 6.) FW_MASQUERADE="no" FW_MASQ_NETS="" FW_MASQ_DEV="$FW_DEV_WORLD" # e.g. "ippp0" or "$FW_DEV_WORLD" # 7.) FW_PROTECT_FROM_INTERNAL="no" # -> NIS ypbind # 8.) FW_AUTOPROTECT_GLOBAL_SERVICES="no" # "yes" is a good choice # 9.) FW_SERVICES_EXTERNAL_TCP="0:65535" # for trial FW_SERVICES_EXTERNAL_UDP="0:65535" # for trial FW_SERVICES_INTERNAL_TCP="0:65535" # for trial FW_SERVICES_INTERNAL_UDP="0:65535" # for trial # 10.) FW_TRUSTED_NETS="192.168.0.0 xx.yy.zz.0/24" FW_SERVICES_TRUSTED_TCP="ssh 8 80 443" # Common: ssh FW_SERVICES_TRUSTED_UDP="8" # Common: syslog time ntp # 11.) FW_ALLOW_INCOMING_HIGHPORTS_TCP="yes" # Common: "ftp-data" (sadly!) FW_ALLOW_INCOMING_HIGHPORTS_UDP="yes" # Common: "dns" # 12.) FW_SERVICE_DNS="no" FW_SERVICE_DHCLIENT="no" FW_SERVICE_DHCPD="no" FW_SERVICE_SAMBA="no" # 13.) FW_FORWARD_TCP="" # Beware to use this! FW_FORWARD_TCP="192.168.0.3/24,xx.yy.zz.15,80 192.168.0.3/24,xx.yy.zz.4,22" FW_FORWARD_UDP="" # Beware to use this! # 14.) FW_FORWARD_MASQ_TCP="" # Beware to use this! FW_FORWARD_MASQ_UDP="" # Beware to use this! # 15.) FW_REDIRECT_TCP="" FW_REDIRECT_UDP="" # 16.) FW_LOG_DENY_CRIT="yes" FW_LOG_DENY_ALL="yes" FW_LOG_ACCEPT_CRIT="yes" FW_LOG_ACCEPT_ALL="no" # normally no # 17.) FW_KERNEL_SECURITY="no" # 18.) FW_STOP_KEEP_ROUTING_STATE="no" # 19.) FW_ALLOW_PING_FW="yes" FW_ALLOW_PING_DMZ="no" # 20.) FW_ALLOW_FW_TRACEROUTE="no" # 21.) FW_ALLOW_FW_SOURCEQUENCH="yes" # 22.) FW_MASQ_MODULES="autofw cuseeme ftp irc mfw portfw quake raudio user vdolive" So, if anyone has a solution to get a connection established, let me know it. Thanks Jürgen Foag -- _____________________________________________________________________ Telefon: +49 (0) 89 / 289 - 25290 Fax: +49 (0) 89 / 289 - 28323 Technische Universität München - Lehrstuhl f. Integrierte Schaltungen Arcisstrasse 21 - 80290 München - Deutschland / Germany E-Mail: Juergen.Foag(a)ei.tum.de Homepage: http://www.lis.e-technik.tu-muenchen.de/people/jf.html _____________________________________________________________________ If everything you try works, you are not trying hard enough ! (Gordon Moore) _____________________________________________________________________

1 0

Re : SuSEfirewall2 questions ?
by Eric Romang 05 Sep '01

05 Sep '01

Hello, Thanxs for your answer. I have uninstall SuSEfirewall1 and personnal suse firewall in the method you give. Thxs ;) I wan't to know how to make an upgrade of SuSEFirewall2 there is a new version on http://www.suse.de/~marc Yes I use SSH to log remotely ;) For DHCPD, my ps -aux give me this : root 611 0.0 0.2 1364 636 ? S 13:13 0:00 /sbin/syslogd -a /var/lib/dhcp/var/run/dhcpd.pid Why DHCPD has an process with syslog ?? I don't have lunch DHCPD on startup... I don't wan't dhcpd... In my rc.concfig START_DHCPD is set to no... but they are some pid ... But I don't understand why my server freeze whitout reason... Regards > > > -----Original Message----- > > From: Jaakko Tamminen [mailto:jtamminen@satabaana.net] > > Sent: 05 September 2001 12:58 > > To: Eric Romang > > Subject: Re: [SLE] SuSEfirewall2 questions ? > > > > > > Hi > > > > Disable personal-firewall, that blocks all outside connection attempts, > > and that seems to be the case for You. > > > > To remove the "old" susefirewall, do it with yast->install/remove > > packages, or you can try someting like "rpm -e SuSEfirewall". The name > > must be correct, but I believe it might be that one. > > > > Actually there is no need to remove the "old" firewall, just don't > > enable it. In my server I have both installed the same time, and the > > only annoying thing is that there is both entrys in configuration file, > > but it does not really matter. > > > > I hope You are using ssh to log remotely...? > > > > About dhcp.. I did not really understand Your question.. Do you need > > DHCP-client to get Your IP for the server? If so, You need to enable > > that (start dhcp), and also in firewall configuration section you need > > to set "dhcp client" to YES. > > > > Hope this helps > > > > Jaska. > > > > > > > > > > > > > Hello, > > > > > > I have install SuSEfirewall2 on my serveur with two ethernet card. > > > One for the private network, the other to the internet. > > > > > > I have some crash from the server I can't explain. > > > The server freeze and i don't have the hand on it... no more root > > > login possible > > > and the tty are froozen... > > > > > > I have no error messages in my message log file, and also in my > > > firewall message. > > > > > > But I have this line in my message log and warm message. > > > > > > My message log messages : > > > > > > Sep 6 12:04:36 lithium SuSEfirewall2: Firewall rules successfully > > > set from /etc/rc.config.d/firewall2.rc.config > > > Sep 6 12:04:36 lithium /sbin/SuSEpersonal-firewall: > > > SuSEpersonal-firewall: Loading of module ipchains was not successful. > > > Sep 6 12:04:36 lithium /sbin/SuSEpersonal-firewall: Aborting. No > > > action taken. > > > > > > My warm log messages : > > > > > > Sep 6 12:04:35 lithium kernel: ip_tables: (c)2000 Netfilter core > > > team Sep 6 12:04:35 lithium kernel: ip_conntrack (2047 buckets, > > > 16376 max) Sep 6 12:04:36 lithium /sbin/SuSEpersonal-firewall: > > > SuSEpersonal-firewall: Loading of module ipchains was not successful. > > > Sep 6 12:04:36 lithium /sbin/SuSEpersonal-firewall: Aborting. No > > > action taken. > > > > > > I have also, my sylogd how run dhcp, but i don't have start the dhcpd > > > on startup... > > > I can see a line in process... > > > > > > Somebody can explain me why my server freeze ?? > > > > > > And another question, I wan't to upgrade my SuSEfirewall2. > > > What are the step to remove the old one ? > > > > > > Thanxs. > > > Regards > > > > > > Eric Romang - System Administrator > > > eric.romang(a)synapse.lu > > > --------------------------------------------------------------------- > > >------- --------- > > > Site : http://www.synapse.lu > > > Synapse Internet Services > > > 49, Bd. G-D. Charlotte, L-1331 Luxembourg > > > Tel : +352 / 44 79 44 77 > > > Fax : +352 / 44 79 44 79 > > > GSM : +352 / 021 7000 35 > > > --------------------------------------------------------------------- > > >------- --------- > > > > ---------------------------------------- > > Content-Type: text/html; charset="iso-8859-1"; name="Liite: 1" > > Content-Transfer-Encoding: quoted-printable > > Content-Description: > > ---------------------------------------- > > > > > -- > To unsubscribe send e-mail to suse-linux-e-unsubscribe(a)suse.com > For additional commands send e-mail to suse-linux-e-help(a)suse.com > > Also check the FAQ at http://www.suse.com/support/faq and the > archives at http://lists.suse.com >

2 1

Re: [suse-security] ssh-incompatibility ?
by Daniel Quappe 05 Sep '01

05 Sep '01

hi folks, many thanks to all hints! i decided to upgrade to openssh version 2 and that works...;-) best regards, daniel -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net

1 0

ssh-incompatibility ?
by Daniel Quappe 05 Sep '01

05 Sep '01

hi list, today i've got a problem: maybe someone out there already knows... i connected two hosts by dialin and wanted to use ssh for communication. this was the error-output (ssh -v): SSH Version 1.2.27 [i386-suse-linux], protocol version 1.5. Standard version. Does not use RSAREF. dbs: Reading configuration data /etc/ssh_config dbs: ssh_connect: getuid 0 geteuid 0 anon 0 dbs: Allocated local port 1022. dbs: Connecting to 192.168.23.115 port 22. dbs: Connection established. dbs: Remote protocol version 2.0, remote software version OpenSSH_2.3.0p1 dbs: Waiting for server public key. Local: Bad packet length 1349676916. 192.168.23.115 is the dialin-server and 192.168.23.116 the client-machine. does anyone know this problem (and a solution..;-) ? best regards, daniel -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net

3 2

SuSEfirewall2 questions ?
by Eric Romang 05 Sep '01

05 Sep '01

Hello, I have install SuSEfirewall2 on my serveur with two ethernet card. One for the private network, the other to the internet. I have some crash from the server I can't explain. The server freeze and i don't have the hand on it... no more root login possible and the tty are froozen... I have no error messages in my message log file, and also in my firewall message. But I have this line in my message log and warm message. My message log messages : Sep 6 12:04:36 lithium SuSEfirewall2: Firewall rules successfully set from /etc/rc.config.d/firewall2.rc.config Sep 6 12:04:36 lithium /sbin/SuSEpersonal-firewall: SuSEpersonal-firewall: Loading of module ipchains was not successful. Sep 6 12:04:36 lithium /sbin/SuSEpersonal-firewall: Aborting. No action taken. My warm log messages : Sep 6 12:04:35 lithium kernel: ip_tables: (c)2000 Netfilter core team Sep 6 12:04:35 lithium kernel: ip_conntrack (2047 buckets, 16376 max) Sep 6 12:04:36 lithium /sbin/SuSEpersonal-firewall: SuSEpersonal-firewall: Loading of module ipchains was not successful. Sep 6 12:04:36 lithium /sbin/SuSEpersonal-firewall: Aborting. No action taken. I have also, my sylogd how run dhcp, but i don't have start the dhcpd on startup... I can see a line in process... Somebody can explain me why my server freeze ?? And another question, I wan't to upgrade my SuSEfirewall2. What are the step to remove the old one ? Thanxs. Regards Eric Romang - System Administrator eric.romang(a)synapse.lu ---------------------------------------------------------------------------- --------- Site : http://www.synapse.lu Synapse Internet Services 49, Bd. G-D. Charlotte, L-1331 Luxembourg Tel : +352 / 44 79 44 77 Fax : +352 / 44 79 44 79 GSM : +352 / 021 7000 35 ---------------------------------------------------------------------------- ---------

2 1

[suse-security] problem with firewall and X-forwarding
by kohli＠dplanet.ch 05 Sep '01

05 Sep '01

Hi again. I already asked that question once, but then I didn't get any helpful answers... Following problem: I'm in the intranet at my office, and want to work on a remote server. Let's call him jasper. So, I'm on jasper an make a "xspread". Now I get the following answer: xspread: Can't open display client84.xxxx.xx:0 It doesn't matter whether I use ssh or rlogin or rsh to log in to jasper, it simply doesn't work. My firewall log says: Sep 5 11:17:55 memphis kernel: Packet log: rulchain REJECT eth0 PROTO=6 xxx.xx.xxx.xx:60972 xxx.xx.xxx.xx:6000 L=44 S=0x00 I=5353 F=0x4000 T=255 SYN (#5) Sep 5 11:17:56 memphis kernel: Packet log: rulchain REJECT eth0 PROTO=6 xxx.xx.xxx.xx:60974 xxx.xx.xxx.xx:6000 L=44 S=0x00 I=5354 F=0x4000 T=255 SYN (#5) Sep 5 11:17:57 memphis kernel: Packet log: rulchain REJECT eth0 PROTO=6 1xxx.xx.xxx.xx:60975 xxx.xx.xxx.xx:6000 L=44 S=0x00 I=5355 F=0x4000 T=255 SYN (#5) Sep 5 11:17:58 memphis kernel: Packet log: rulchain REJECT eth0 PROTO=6 1xxx.xx.xxx.xx:60976 xxx.xx.xxx.xx:6000 L=44 S=0x00 I=5356 F=0x4000 T=255 SYN (#5) Sep 5 11:17:59 memphis kernel: Packet log: rulchain REJECT eth0 PROTO=6 xxx.xx.xxx.xx:60977 xxx.xx.xxx.xx:6000 L=44 S=0x00 I=5357 F=0x4000 T=255 SYN (#5) Now, how can I solve that problem? Also, I wonder why the outgoing port on jasper is steadily inceasing by one, with each attempt to connect...? Any help appreciated! TIA markus

2 1

SuSEfirewall2 and ICMP
by Peter Menzel 04 Sep '01

04 Sep '01

Hello, I successfully installed SuSEfirewall2 and configured it to my needs. The firewall box is set up with two external interfaces (ippp0 and eth1). eth1 is normally connected to an ELSA DSL router and in case DSL will not work I want to switch back to ISDN. So far I've set up ISDN and that stuff, the box is doing everything fine. Clients can do http, https, ftp, mail and so on. Portscans run from the internet report all ports as stealth and the firewall cannot be pinged from the internet. But when it comes to a ping from the internal network to the internet, nothing works. I've tried all the FW_ALLOW_PING_[FW|DMZ|EXT] settings, with no results. Interesting: when I set FW_FORWARD_PING_DMZ="yes" I am able to ping the internet from the firewall, but not from the clients. More interesting: I have not configured a DMZ (yet). What I would like to do is to ping the internet from the clients and get the echo-reply back. echo-requests from the internet have to be dropped at the firewall. Has anyone experienced these problems? Any help would be appreciated. Thanks in advance, Peter peter.menzel(a)com-gmbh.de

1 0

ssh question
by Sven Michels 04 Sep '01

04 Sep '01

Hi there, i've a problem with openssh behind a 2.4.x firewall. If i try to connect to the outside, i got no response until setting the -P flag. with -P it works fine. So it seems to be a problem with the nonprivat port. is there a firewall missconfiguration or something i missed? with 2.2.19 all works fine (without -P). Regards, Sven -- intraDAT AG http://www.intradat.com Wilhelm-Leuschner-Strasse 7 Tel: +49 69-25629-0 D - 60329 Frankfurt am Main Fax: +49 69-25629-256

3 5

AW: [suse-security] ucd-snmpd default configuration
by Reckhard, Tobias 04 Sep '01

04 Sep '01

> > SNMP is not only read but write typically. > > In it's default configuration, really? > I'd suppose so as well. It depends on the configuration of the SNMP server. > > easier to sniff (cleartext). > > I thought it's possible to set up SNMP using some encryption by > itself, but a quick search didn't found a useful HOWTO neither > about SNMP nor encryption nor security... Except "disable if not > needed"... > AFAIK, SNMPv3 will support encryption and a decent authentication scheme, but most SNMP implementations out there are still v1 or v2. Actually, I think that the SNMPv3 standard hasn't even been passed yet. > Yep, of course the firewalls restrict it to just one machine, but > I would like to make sure that the snmpd will not allow bad > things under any cirumstances. Firewalling is quite clear, like > always :) > Well, you can never be 100% sure.. (responding to your phrase. "..under *any* circumstances...". And whether things are good or bad depends a lot on the context they happen in. > > and maybe using ssh port forwarding or ipsec to encrypt it. > > IPSec with each machine is to expensive and won't help, since it > the monitor gets compromised IPSec can be used by unauthorized > software - same for SSH, so I don't see a big improvement. > Why do you consider IPSec too expensive? As it is, you don't need to do IPSec with all hosts, you can configure it on a host by host basis. In fact, you need to, unless you've got DNSSEC set up, as you need a host-specific authentication entity for each host. Still, it's not much more work than SSH, IMHO. As far as the security offered by IPSec is concerned, IPSec gives you real authentication of the source of IP packets. SNMP uses UDP, which makes the combination of easy source address spoofing and access to configuration commands (SNMP RW) a very risky thing. IPSec can prevent spoofing and keep sniffers from reading your SNMP data as well. Tobias

2 3

Re: [suse-security] SuSE-FW-DROP-ANTI-SPOOFING
by Burghard W.V. Britzke 04 Sep '01

04 Sep '01

The SuSEfirewall2 v1.6 is quite good! I found the thing. My internal net is 192.175.233.0/24 my external net is 192.175.233.0/30 (a two bit subnet with only the router and my firewall in it). There are rules to prevent boxes from extenal to be routed to internal if they have an internal address. Unfortunally 192.175.233.0/24 (my internal net) includes 192.175.233.0/30 (my extenal net). So my router cannot communicate with internal boxes. This is not as bad as it seems to because all packets which are forwarded from outside are not rejected by the ANTI-SPOOF rule (but it is most likely that they are rejected by other rules ;-)) For configuration purposes I simply delete the two DROP rules and the two LOG rules from input_ext chain (and may be from forward_ext chain if I want forwarding to my router). Steffen Schoch and Martin Haas antworteten (answered) > ... > > "Burghard W.V. Britzke" wrote: > > > > hello, > > I have problems to contact my firewall from outside. Our uunet router is capable to contact our firewall and some of the services provided > > internally from outside. but when I plug a local pc with the same IP address to the FW_DEV_EXT network and try to connect to smtp (for > > example) I get > > SuSE-FW-DROP-ANTI-SPOOF IN=eth0 OUT= MAC=... SRC=<router> DST=<firewall> LEN=48 TOS=0x0 > > 0 PREC=0x00 TTL=128 ID=546 DF PROTO=TCP SPT=1043 DPT=25 WINDOW=16384 RES=0x00 SY > > N URGP=0 OPT (020405B401010402) > > > > again: the uunet router is capable to send mails via smtp port and I do not get the above error message. Why do I get those messages?

1 0

Ftp from DMZ with SuSEfirewall2 v1.7
by wbrune 04 Sep '01

04 Sep '01

Hello, I've setup an Firewall with SuSEfirweall2 v1.7. It has got 3 Interfaces. EXT, DMZ and INT. In the DMZ is a Server running Squid and Sendmail=20 My Problem is, the Server in the DMZ can't do Ftp. I allowed outgoing ftp in FW_FORWARD. Works fine. But if the Server outside starts to send Data from Port 20 the Firewall drops the Packets=20 (SuSE-FW-DROP-DEFAULTIN=3D... spt=3D20 dpt=3Dxxxxx) Ftp from the Firewall itself works fine.=20 I tried to set ftp-data in FW_ALLOW_INCOMING_HIGHPORTS. Didn't work.=20 I tried a Rule for ftp-data in any Direction in FW_FORWARD.=20 Didn't work. Can anyone help? -- Mit freundlichem Gruss Willi Brune

1 0

SuSE-FW-DROP-ANTI-SPOOFING
by Burghard W.V. Britzke 04 Sep '01

04 Sep '01

hello, I have problems to contact my firewall from outside. Our uunet router is capable to contact our firewall and some of the services provided internally from outside. but when I plug a local pc with the same IP address to the FW_DEV_EXT network and try to connect to smtp (for example) I get SuSE-FW-DROP-ANTI-SPOOF IN=eth0 OUT= MAC=... SRC=<router> DST=<firewall> LEN=48 TOS=0x0 0 PREC=0x00 TTL=128 ID=546 DF PROTO=TCP SPT=1043 DPT=25 WINDOW=16384 RES=0x00 SY N URGP=0 OPT (020405B401010402) again: the uunet router is capable to send mails via smtp port and I do not get the above error message. Why do I get those messages?

2 1

compartment and the --cap option
by Andreas Amann 03 Sep '01

03 Sep '01

Hello everybody! I am currently trying to bring several daemons on my system into a chroot jail using Marc Heuse's 'compartment' tool. So far all works quite well but the fine tuning is still to be done. I am wondering what kind of security enhancements can be done by using compartments '--cap' option. Since the documentation of this feature is not very exhaustive i am still looking for some missing link to understand this correctly. Maybe someone here could help me with that. If I understand that correctly, capabilities are a partitioning of root's privileges and using the --cap option i can influence the privileges of a newly started process no matter whether it will run as root or not. So, for example, the command 'compartment --chroot /some/dir --cap none --verbose /daemon/with_uid0/port_below_1024' should fail miserably because the daemon won't be able to bind to it's port. But exactly this works and i am wondering why (compartment tells me that it successfully set caps to 0x0). I am using SuSE 7.2 with a (stock) Kernel 2.4.9 (but it also happens with a SuSE 2.2.19). /proc/sys/kernel/cap_bound says -257, say everything except CAP_SETPCAP. So thinking about that and the stuff i've read in the 'capfaq' from http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq… i have the following questions: - Is it true that --cap only works with CAP_INIT_EFF_SET and CAP_INIT_INH_SET set to -1 in <linux/capability.h> in order to get the CAP_SETPCAP privilege? - If so, doesn't it give even more problems when granting the CAP_SETPCAP right to init? I think this would mean that every process started by init will have it. - If not, do i totally missunderstand something and everything is working well except me? Thanks in advance to everyone who will be so friendly to help me with that! With kind regards Andreas Amann <mailto:andreas.amann@epost.de>

2 4

SuSE Security Announcement: nkitb/nkitserv/telnetd
by Sebastian Krahmer 03 Sep '01

03 Sep '01

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: nkitb/nkitserv/telnetd Announcement-ID: SuSE-SA:2001:029 Date: Mon Sep 3 12:55:58 MEST 2001 Affected SuSE versions: [6.1, 6.2,] 6.3, 6.4, 7.0, 7.1, 7.2 Vulnerability Type: remote code execution Severity (1-10): 8 SuSE default package: yes Other affected systems: All UN*X Systems shipping BSD derived telnetd Content of this advisory: 1) security vulnerability resolved: Buffer overflow in in.telnetd 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 telnet server which is shipped with SuSE distributions contains a remotely exploitable buffer-overflow within its telnet option negotiation code. This bug is wide-spread on UN*X systems and affects almost all implementations of telnet daemons available. SuSE 7.2 distribution ships the telnet-server package which contains the vulnerable telnet daemon. This package has been fixed. The SuSE Linux distributions 6.3 and 6.4 contain versions and implementations of the telnet-daemon that are vulnerable, but the complexity of the code requires a full source code audit of the software. In order not to further delay the release of the packages for the SuSE Linux 7.x distributions, we recommend to disable the telnet daemon on the 6.x distributions. This can be done by commenting out the line in /etc/inetd.conf that starts with "telnet", and then reloading the inetd configuration using the command "killall -1 inetd". Another option is to not start the inetd in the first place if you do not need any of the services provided by the inetd daemon. Disabling inetd permanently involves killing the running inetd process ("killall -TERM inetd") and setting the variable START_INETD in /etc/rc.config to "no" (as opposed to "yes"). Disabling the telnet service is the preliminary solution/workaround against the problems with the telnetd daemon. We hope to be able to provide a better solution. The SuSE Linux distributions 7.0, 7.1 and 7.2 have similar implementations of in.telnetd, and for all of these distributions there are update packages available. Please note that the package that contains the /usr/sbin/in.telnetd program (the server program) has changed over the different releases of the SuSE Linux distribution. In the 7.0 and 7.1 distributions the package is called "nkitserv". The 7.2 distribution lists the telnet server in the package "telnet-server". Please download the packages and verify them as described in section 3. After successfull authentication you can update your packages with the command `rpm -Uhv file.rpm'. Further action should not be necessary to activate the update since the in.telnetd daemon is started from a new by inetd upon every accepted connection from the network. Regardless of the availiability of fixed packages of the telnet-daemon, SuSE Security strongly recommend to disable the telnet service if you do not use it. In addition to that, only cryptographically protected protocols such as secure shell (ssh, package openssh) can be an efficient countermeasure against sniffing and spoofing type attacks. Due to significantly more comfort (such as X11-forwarding, multiple authentication methods, ...), the transition to ssh should be worth the effort in any case. i386 Intel Platform: SuSE-7.2 ftp://ftp.suse.com/pub/suse/i386/update/7.2/n1/telnet-server-1.0-69.i386.rpm 0adc05af9762bd4c63eee464ca3131d1 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.2/zq1/telnet-1.0-69.src.rpm fe313553d1a6f022c7eb2f87ccd6772f SuSE-7.1 ftp://ftp.suse.com/pub/suse/i386/update/7.1/n1/nkitserv-2001.8.14-0.i386.rpm e0636eec04ccf2129b0e2ea0ee40c231 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.1/zq1/nkitb-2001.8.14-0.src.rpm 57760fcd8e064e89591203f7ba9adefc SuSE-7.0 ftp://ftp.suse.com/pub/suse/i386/update/7.0/n1/nkitserv-2001.8.16-0.i386.rpm e8a859d5a648a572fc08628247c1e2d6 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.0/zq1/nkitb-2001.8.16-0.src.rpm 33d4abc52926ac957f21b8c8aae7adce Sparc Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/sparc/update/7.1/n1/nkitserv-2001.8.14-0.sparc.… 3ef64d1cae35be51c9eff9bebcf4cf79 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.1/zq1/nkitb-2001.8.14-0.src.rpm 4cb76a16bd2f53c37a7cee728ea21c81 SuSE-7.0 ftp://ftp.suse.com/pub/suse/sparc/update/7.0/n1/nkitserv-2001.8.16-0.sparc.… f4901a4a271657d0379aff114d30b912 source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.0/zq1/nkitb-2001.8.16-0.src.rpm ad909d8e3d2d0a617a5a9f6e3d7cd74d AXP Alpha Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/axp/update/7.1/n1/nkitserv-2001.8.14-0.alpha.rpm efad3412a8d333947bcf74695c023ea8 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/7.1/zq1/nkitb-2001.8.14-0.src.rpm 94d0dba0396e41b4afbd3ef61c4fd8aa SuSE-7.0 ftp://ftp.suse.com/pub/suse/axp/update/7.0/n1/nkitserv-2001.8.16-0.alpha.rpm 934525486e72a5cc98736f4cb1217f93 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/7.0/zq1/nkitb-2001.8.16-0.src.rpm a6623ff6d9439dea40f24ff35acefe99 Power PC Platform: SuSE-7.1 ftp://ftp.suse.com/pub/suse/ppc/update/7.1/n1/nkitserv-2001.8.14-0.ppc.rpm 4da51d1a38095e81ee389094b0f21160 source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.1/zq1/nkitb-2001.8.14-0.src.rpm 499b282f614835fe7a7b1a9ab039c56d SuSE-7.0 ftp://ftp.suse.com/pub/suse/ppc/update/7.0/n1/nkitserv-2001.8.16-0.ppc.rpm 262f3fc3653042976c8cc36a2cd7e44d source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/7.0/zq1/nkitb-2001.8.16-0.src.rpm 7cba8393bb8a71cf4d39fb480a71b42e ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: - w3m The w3m browser contains a buffer-overflow which allows remote-attackers to execute arbitrary code or to crash the w3m web-client when viewing special crafted sites. Please update to the newest w3m packages available on the ftp-server. - dip The dip program is executable as setuid root program for users in the "dialout" group, a privilege that has been issued by the administrator for a trusted user group. This bug will be corrected in future releases of the SuSE Linux distribution. ______________________________________________________________________________ 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>. The <security(a)suse.com> 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 mQENAzbhLQQAAAEIAKAkXHe0lWRBXLpn38hMHy03F0I4Sszmoc8aaKJrhfhyMlOA BqvklPLE2f9UrI4Xc860gH79ZREwAgPt0pi6+SleNFLNcNFAuuHMLQOOsaMFatbz JR9i4m/lf6q929YROu5zB48rBAlcfTm+IBbijaEdnqpwGib45wE/Cfy6FAttBHQh 1Kp+r/jPbf1mYAvljUfHKuvbg8t2EIQz/5yGp+n5trn9pElfQO2cRBq8LFpf1l+U P7EKjFmlOq+Gs/fF98/dP3DfniSd78LQPq5vp8RL8nr/o2i7jkAQ33m4f1wOBWd+ cZovrKXYlXiR+Bf7m2hpZo+/sAzhd7LmAD0l09kABRG0JVN1U0UgU2VjdXJpdHkg VGVhbSA8c2VjdXJpdHlAc3VzZS5kZT6JARUDBRA24S1H5Fiyh7HKPEUBAVcOB/9b yHYji1/+4Xc2GhvXK0FSJN0MGgeXgW47yxDL7gmR4mNgjlIOUHZj0PEpVjWepOJ7 tQS3L9oP6cpj1Fj/XxuLbkp5VCQ61hpt54coQAvYrnT9rtWEGN+xmwejT1WmYmDJ xG+EGBXKr+XP69oIUl1E2JO3rXeklulgjqRKos4cdXKgyjWZ7CP9V9daRXDtje63 Om8gwSdU/nCvhdRIWp/Vwbf7Ia8iZr9OJ5YuQl0DBG4qmGDDrvImgPAFkYFzwlqo choXFQ9y0YVCV41DnR+GYhwl2qBd81T8aXhihEGPIgaw3g8gd8B5o6mPVgl+nJqI BkEYGBusiag2pS6qwznZiQEVAwUQNuEtBHey5gA9JdPZAQFtOAf+KVh939b0J94u v/kpg4xs1LthlhquhbHcKNoVTNspugiC3qMPyvSX4XcBr2PC0cVkS4Z9PY9iCfT+ x9WM96g39dAF+le2CCx7XISk9XXJ4ApEy5g4AuK7NYgAJd39PPbERgWnxjxir9g0 Ix30dS30bW39D+3NPU5Ho9TD/B7UDFvYT5AWHl3MGwo3a1RhTs6sfgL7yQ3U+mvq MkTExZb5mfN1FeaYKMopoI4VpzNVeGxQWIz67VjJHVyUlF20ekOz4kWVgsxkc8G2 saqZd6yv2EwqYTi8BDAduweP33KrQc4KDDommQNDOXxaKOeCoESIdM4p7Esdjq1o L0oixF12CohGBBARAgAGBQI7HmHDAAoJEJ5A4xAACqukTlQAoI4QzP9yjPohY7OU F7J3eKBTzp25AJ42BmtSd3pvm5ldmognWF3Trhp+GZkBogQ57vSBEQQAk/GN+ftr 7+DBlSoixDDpfRnUk+jApGEt8hCnrnjVnPs/9Cr33+CXLQbILOO7Y5oiPbJdHh45 t4E0fKyLVzDerCRFB1swz/mNDxT26DLysdBV5fwNHTPhxa67goAZVrehQPqJEckk IpYriOaYcKpF3n5fQIZMEfMaHEElQhcXML8AoJVXDkJYh7vI8EUB8ZURNLZMEECN A/sH0MCnb4Q6ZcRyeZ3+1PHP8hP73b6TepRdLZhaylwVF/iu7uIn62ZUL4//NTOC DY7V63qg4iba/fUbOsWtEnGaiE7mQuAlsSWvRspwRA9/g9rdVf3/JdLJrLmKBThe yG+PSJE3W7cAE4ZWafGxIRCwXhmj3TQnJn2euqylHRubEQP/aL53NZK0kBdvrKgf f6O8Of6tqoss8Dkk55I7QVFSp+My1Dn+mngQKFejTAgtyo/WmR3wPjQ9HoT2lRiY I2lTRYT4uMdHuwVC3b4DqAKmoy375FERwHkrMVyKBJslv8QtbAWw5A1CAUseaHo+ 91wmYJ4/4p6YUahqbG/tZyhbxfq0KFN1U0UgUGFja2FnZSBTaWduaW5nIEtleSA8 YnVpbGRAc3VzZS5kZT6IXAQTEQIAHAUCOe70gQUJA8JnAAQLCgMEAxUDAgMWAgEC F4AACgkQqE7a6JyACspfLACffAYA+NM8NBhyRyH+nTX58CNjwLIAoIx9fj52BJe0 xY7WbKoXs1+72b2AiEYEEBECAAYFAjpwXlIACgkQnkDjEAAKq6TczgCgi+ddhWb7 +FWcfeE6WwPZccqAHowAnjjtRyGwHLQHr5OTFAYTXi2Wv6jNiQEVAwUQOnBgb3ey 5gA9JdPZAQE1pwf/QJ+b34lFBNVUJ7fk/xGJJREt7V12iSafaRzGuH8xWvIz1bb+ VARxnnt16FDQ1cDNjoEhCEmcW83Vxp6iJXE9PE8wVA/Yue/bon5JS7J69+UiQ2eq 2pudfwljp52lYVM53jgPYEz0q/v3091nlZ8CYkAkN9JDS1lV1gEzJ7J0+POngDpU +lDQT2EC6VKaxeWK8pNt6UFDwICRDQxKnlOoiDvTrdWT7QdJZ4sPv8Qotdw9+tKN bWQ2DqdIRxyTdw9xDfAtcj6mXeQr7852Lwem1gSKVnEYHZ9g1FTJqVOutY8KhpUc 9RfOCRv8XuIxrs4KSbfSF0s8qIRCQelxufg9AbkCDQQ57vSSEAgAhJHQTejMX+Vr 6g1pHDEcusJ63fQ2CfFFE5iE9okH9O7UVCiSfb9CV38dmeHdPCEEjDUWquFYEnvj 3WICMtH249t1Ymuf4Du3yRKQ9oXdn/qTJzlrx9qzjiG3mH7ocwHOgUIwCrZoEdBE VE2n0zPVm+hddwjWWTWXw6pxQz+i9dsN89xexRV5M9O0bNwCLaNWX2GXeLAkqTK/ 9EuZy6x2yLxi6du9YYUAXkZpqBhCjtiUXpRoFCdglMznbcAyCk9C2wqb2j/D1Z2B eSBaGCSFkR6pRLebnE17LWcu72Iy+r0z+JecbPiyDpDZj4apn7IC81aNFGi7fNIT sHODbwwjiwADBgf/YPvVdzkc8OC7ztacEWCanwylKvxCdKzTDA+DfES6WUYShyiV JvZzRy25LJ5WcK20kzOS6Qv1OrIXiz/pdGy1aKtJZrAnFEsofpmOj8VoqyyFgp/y AGQBp12+mXek7SCZRhuqalDfEMRiWEJ6J5dLkyShyRDWyPbFh0HXE7QTHN+IKKxx QqNQXL6Z3NSxS61p+5n6BseiDUI39xxkKTFwFrkgUIc5Gs2Or2lhaWvGwSfoCmwb sklszZt6xbU+R0SjFqTvjPWx6eHfqbmNC9WMDdTjGrXDDKXFp2aYlokfN6It9vsb VlGNlOwHt/JjGoPMxW6Xqj0FLA7/VewgCdXW64hMBBgRAgAMBQI57vSSBQkDwmcA AAoJEKhO2uicgArKSyIAmwUHf/vtKQfcmVg4asR7U6XQl0bAAJ4pO22B5U8UH6IY l2LBCXFqw5+5fA== =Jnnf - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBO5N83Xey5gA9JdPZAQGL3wf/Y9JWafwyYG1XUd5Li95aLdQ4zGDn2DbO o4iJonbvJd5ASsm0bkLIYCfoylkQh/Tc1VxXberIwUSf3NnJ/65kU+Lzn4jvTpMB PZm2QnK9VXukXbvibgamrbiDfSlySfoPD/jJWzTUnugJwZhLDIx3ZL0T9pHvUWOz i4VoK2o70z0dzKKb1YGRZQIaBCZHLm17yWMavEXewHCFJNMYfGT7s/ZajA7FFMXS gFzm7cE+RnykKeMG2Vf53/igoDFrHCiPr8wXEbJu5mbANH9MmGKIpQYdROwKodyk gAFUjXko2fdtkG5HFhlQWXvrHH/ZmZXzWWbp5g5DQ+Uqr3jW6t328A== =AmuR -----END PGP SIGNATURE----- -- ~ ~ perl self.pl ~ $_='print"\$_=\47$_\47;eval"';eval ~ krahmer(a)suse.de - SuSE Security Team ~

1 0

Re: [suse-security] ssh-incompatibility ?
by michael.ryan＠storm.ie 03 Sep '01

03 Sep '01

Install the OpenSSH rpm on the client and use it to connect to the server (afaik the SSH and OpenSSH versions are not compatible) Regards, Michael

1 0

personal firewall and netdate
by Brian Galbraith 03 Sep '01

03 Sep '01

Hi folks I don't know a lot about firewalls so please be gentle! I run the personal fire wall which meets my requirements admirably. However if I wish to set my system clock using netdate.....currently I turn the fire wall off ...log in....set the time...log off, switch on the firewall,and redial. Is there any way to change the personal fire wall to allow connection to the ntp server....and if so....what values do I change? TIA Brian -- Brian Galbraith | GnuPG 1.0.6 | SuSE Linux 7.2-2.4.9 PGP Key 0x8232434C http://www.culcreuch.org.uk ICQ# 110426381 Yahoo Messenger ID: bagalbraith

2 1

AW: [suse-security] automatic backups over ssh/scp
by My PC, Payreder Roman 03 Sep '01

03 Sep '01

Hi, Perhaps you could have a look at: http://freshmeat.net/projects/rsync-backup/ br, Roman * teo(a)gecadsoftware.com wrote on Sat, Sep 01, 2001 at 18:43 +0300: > > The permissions are important, too, imagine a world-writeable > > ~/.ssh or a not world-readble ~/public_html. > > but this is easily achived with --archive option. > as I understand it, the issue is when restoring from backups, > and given that that's a root task, I see no problems with it. Yep, that's it. root task on both sides! > when you backup with rsync, use -a to preserve ownership and > rights, recreate links BTW, I get often errors when rsync tries to create symlinks: file already exists... oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel. -- To unsubscribe, e-mail: suse-security-unsubscribe(a)suse.com For additional commands, e-mail: suse-security-help(a)suse.com

1 0

AW: [suse-security] rsync and automatics backups over ssh
by Reckhard, Tobias 03 Sep '01

03 Sep '01

> i am thinking for using rsync over ssh. > but i have a problem, the sys ask me for writting the ssh password. > there is any method using rsync and ssh for sending the password whitout > writte it? my plan is to use rsync over ssh in a cron. > I use public key authentication with a null passphrase for the private key on the client machine. Tobias

1 0

AW: [suse-security] ucd-snmpd default configuration
by Reckhard, Tobias 03 Sep '01

03 Sep '01

> SNMP is not only read but write typically. Community strings are often > easy > to guess, easier to sniff (cleartext). I suggest _heavilly_ firewalling > snmp > and maybe using ssh port forwarding or ipsec to encrypt it. > SSH won't help, as it can only perform port forwarding of TCP ports, AFAIK, while SNMP uses UDP only. I suggest a physically separate LAN or IPSec for SNMP (and syslog, BTW). And you should configure your SNMP server as tightly as possible. Make snmpwalk show only what it needs to. Cheers Tobias

1 0

ucd-snmpd default configuration
by Steffen Dettmer 02 Sep '01

02 Sep '01

Hi, I played around with MRTG which worked out-of-the-box. I just started rcsnmpd on the hosts and adjusted the firewalls to allow UDP:161 for the "monitor" host. Now the hosts run snmpd without configuration (at least it looks that there is no configuration file). I just started snmpd. Now I want to hear some statement about the risks. Since SNMP is very powerful, I fear that I opened some security leaks. OK, the firewalls are restrictive but I could sleep better if I could be sure that the default config garantes "read-only" accesses only. Second, snmpwalk reports really much things, but for MRTG I need the interface stats only. I looked for some example configuration files but they are complex to understand. Any sugesstions? Since I run SNMP now, I think about useing the check_snmp plugin with netsaint. I could imagine to check via snmp if i.e. the process "ypbind" is still running and so on. Is this secure? Or should I better not doing this? I would be glad if I could find anyone who uses check_snmp for more that checking snmpd itself. We could discuss this is little, but maybe this list is OT for that particular issue. I'm looking forward to any statements, thank you. oki, Steffen -- Dieses Schreiben wurde maschinell erstellt, es trägt daher weder Unterschrift noch Siegel.

2 2

once again FreeS/WAN tunnel established, no data transferred
by Stefan_Walther＠gehag-dsk.de 01 Sep '01

01 Sep '01

Hi folks, I recognize a problem at my side. You meant "strange routing". Now I see what you mean. The IP's of the first GW on eth0 must be 192.168.200.1 and the IP on the eth1 of the second GW must be 192.168.100.1. Now I see my fault. The IP's on the boxes where set this way I told to you in the sentence before. By the way, I have a look at /var/log/messages and saw the message IPSec SA established and tcpdump tells me that there are UDP:500-->500 packets are going through the router (ip-proto-50). MfG. Stefan Walther stefan_walther(a)gehag-dsk.de dienst.: +4930/89786448 Funk: +49172/3943961 ----- Forwarded by Stefan Walther/GEHAG DSK GmbH on 01.09.2001 16:41 ----- >hi folks, >I have the following problem. I have an established IPSec-tunnel between 2 boxes. >I'm using SuSE7.1 and FreeS/WAN 1.91. The FreeS/WAN tells me that the tunnel is established (last message in /var/log/messages). >My configuration is the following: >1st client-----1st-FreeS/WAN-gateway----ROUTER----2nd-FreeS/WAN-gateway------2nd-client > eth0--------------eth0------eth1----eth1-eth0----eth0--------eth1------eth0 >!Every box is a linux box! >The 1st client has the following config: RedHat7.1, IP: 192.168.200.2 >The 1st FreeS/WAN-gateway config is: SuSE 7.1, kernel 2.4.7, eth0: 192.168.100.1, eth1: 172.16.100.1, IP-forwarding without masquerading >The Router has the following config: SuSE7.1, kernel 2.4.7, eth1: 172.16.100.2, eth0 10.16.100.2, IP-forwarding without masquerading >The 2nd FreeS/WAN-gateway config is: SuSE7.1, kernel 2.4.7, eth0: 10.16.100.1, eth1: 192.168.200.1, IP-forwarding without masquerading >The 2nd client has the following config: Windows2000, eth (seems to be a littlebit stupid): 192.168.100.2 >Every netmask is 255.255.255.0; >If i start ipsec via, ipsec start at the shell, no error (exept the IPv6-bind error) occured. >Before starting IPSec the routes, the the clients can pinging each other are set by hand. FreeS/WAN sets the routes to the ipsec0 interface. >After starting you cannot ping anymore from the 1st client to the 2nd client ans the other way around. Does anybody know a solution for this problem??? >THX MfG. Stefan Walther stefan_walther(a)gehag-dsk.de dienst.: +4930/89786448 Funk: +49172/3943961

1 0