October 2000 - openSUSE Security - openSUSE Mailing Lists

Re: [suse-security] SuSEfirewall (SuSE 6.4), SMB-Broadcasts
by Wolfram Schlich 19 Oct '00

19 Oct '00

> FW_SERVICE_SAMBA="no" # set to "yes" if this server uses samba as client > # or server. As a server, you still have to set > # FW_SERVICES_{WORLD,DMZ,INT}_TCP="139" > # Everyone may send you udp 137/138 packets if set > # to yes! (samba on the firewall is not a good idea!) Don't have that :( SuSEfirewall 2.1... (firewals-2.1-5) But thanx for your help :) Mit freundlichen Grüssen | Wolfram Schlich ------------------------------------------------------------------ | E-Mail: wolfram(a)schlich.org * ICQ #: 35713642 | Postal: Berghof * 56626 Andernach * Germany | Tel.: +49-(0)2636-941194

1 0

SuSEfirewall (SuSE 6.4), SMB-Broadcasts
by Wolfram Schlich 18 Oct '00

18 Oct '00

Hello List! I think this happens when the machine tries to broadcast: Packet log: input DENY eth0 PROTO=17 192.168.0.10:138 192.168.0.255:138 L=253 S=0x00 I=6937 F=0x0000 T=64 (#5) How can I make SuSEfirewall accepting these packets?! Thanx in advance. Mit freundlichen Grüssen | Wolfram Schlich ------------------------------------------------------------------ | E-Mail: wolfram(a)schlich.org * ICQ #: 35713642 | Postal: Berghof * 56626 Andernach * Germany | Tel.: +49-(0)2636-941194

1 0

ftp-svans
by OKDesign oHG Security Webmaster 18 Oct '00

18 Oct '00

Hi folks, over the last months we learned that lots of idiots outside on the net are systematically looking for ftp-servers allowing anonymous access. I say systematically, because our logs show as many access-tries as IPs are served by our system. If this would happen once or twice, well, nothing to worry about. But this happens nearly once (sometimes twice) in 3 days. Besides the traffic generated by this (and this is traffic we have to pay for) I'm not really amused by it, because maybe they are checking which ftp-server is running and then try to get into the system by using some security-hole(s). These are the facts. Now my question: Is there any way to prevent this ? Maybe by a program that checks the source-IP of accesses and denies any more accesses to the system at all originating from this IP for maybe 30 minutes or something similar. So these people won't get any more responses from the system for some time. Is there any script/program able to do this ? Or is there any other program that prevents those ftpd-scans using any other method ? Any help would be greatly appreciated. Oh, BTW, I'm also looking for some tool which outputs the whole traffic for all IPs within a defined range for some period of time (daily or something). All these IPs are served by the same system (virtual NICs). I already took a look at the programs that came with SuSE 7.0, but couldn't find anything. Any ideas, URLs, or something ? Thanks in advance. --- Stephan

2 1

SuSE Security Announcement: ypbind/ypclient (SuSE-SA:2000:042)
by Roman Drahtmueller 18 Oct '00

18 Oct '00

-----BEGIN PGP SIGNED MESSAGE----- ______________________________________________________________________________ SuSE Security Announcement Package: ypbind/ypclient Announcement-ID: SuSE-SA:2000:042 Date: Wednesday, October 18th, 2000 19:15 MEST Affected SuSE versions: 6.0, 6.1, 6.2, 6.3, 6.4, 7.0 Vulnerability Type: possible remote root compromise Severity (1-10): 8 SuSE default package: yes (starting with SuSE-6.4) Other affected systems: Linux systems using this NIS implementation Content of this advisory: 1) security vulnerability resolved: ypbind/ypclient 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 Security problems have been found in the client code of the NIS (Network Information System, aka yp - yellow pages) subsytem. SuSE distributions before SuSE-6.1 came with the original ypbind program, SuSE-6.2 and later included the ypbind-mt NIS client implementation. ypbind-3.3 (the earlier version) has a format string parsing bug if it is run in debug mode, and (discovered by Olaf Kirch <okir(a)caldera.de>) leaks file descriptors under certain circumstances which can lead to a DoS. In addition, ypbind-3.3 may suffer from buffer overflows. ypbind-mt, the software shipped with SuSE distributions starting with SuSE-6.2, suffers from a single format string parsing bug. Some of these bugs could allow remote attackers to execute arbitrary code as root. During code audit and testing it turned out that the ypbind-3.x software in the SuSE-6.1 distribution and earlier needs a major overhaul to make it work both reliable and secure with respect to errors in the code. Basically, this is what happened when Thorsten Kukuk <kukuk(a)suse.de> wrote ypbind-mt from scratch in 1998. For the same reason, we are currently unable to produce a working security update package which fixes the known and yet unknown (there may be more) problems in the ypclient packages in the SuSE-6.1 distribution and older. The only efficient workaround for the SuSE-6.1 distribution and older against these bugs for an untrusted, hostile environment is to upgrade to a new distribution base (SuSE-7.0 is recommended) and use the ypclient update packages for this distribution. As of today, there is no exploit known to exist in the wild. For SuSE-6.2 and later distributions we provide update packages as listed below. We recommend to download and install these packages on systems that are NIS/yp clients. Please note that the sources for the ypclient package are contained within the ypserv source rpm. Download the update package from locations described below and install the package with the command `rpm -Uhv file.rpm'. The md5sum for each file is in the line below. You can verify the integrity of the rpm files using the command `rpm --checksig --nogpg file.rpm', independently from the md5 signatures below. i386 Intel Platform: SuSE-7.0 ftp://ftp.suse.com/pub/suse/i386/update/7.0/n1/ypclient-3.5-89.i386.rpm 76e4e7f60791db16c5e36fb5dbf60b65 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/7.0/zq1/ypserv-1.3.11-89.src.rpm e2b1dccaec003f54e4ebbdef84d99a10 SuSE-6.4 ftp://ftp.suse.com/pub/suse/i386/update/6.4/n1/ypclient-3.4-95.i386.rpm e485ea27264fb9c4f890cdf7605ffa30 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/6.4/zq1/ypserv-1.3.11-95.src.rpm c61c6df2ba1fef2369406b2dcbcd25f1 SuSE-6.3 ftp://ftp.suse.com/pub/suse/i386/update/6.3/n1/ypclient-3.4-95.i386.rpm c1a10cc0a3f72242b136be921f9ae0c1 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/6.3/zq1/ypserv-1.3.11-95.src.rpm 6f47a880d5e7175dc2b5ff0116d7de4d SuSE-6.2 ftp://ftp.suse.com/pub/suse/i386/update/6.2/n1/ypclient-3.4-95.i386.rpm 9050e63cb9f7fac4997968760292a6f1 source rpm: ftp://ftp.suse.com/pub/suse/i386/update/6.2/zq1/ypserv-1.3.11-95.src.rpm 7ecfaffd8cdb68f73adfd1d6fd27ed39 SuSE-6.1 and older: Please see the problem description above. Sparc Platform: SuSE-7.0 ftp://ftp.suse.com/pub/suse/sparc/update/7.0/n1/ypclient-3.5-89.sparc.rpm 1a38d25c8647f010e2a9879f28de4adf source rpm: ftp://ftp.suse.com/pub/suse/sparc/update/7.0/zq1/ypserv-1.3.11-89.src.rpm 6ba9200e49210f98ca845107b034b981 AXP Alpha Platform: SuSE-6.4 ftp://ftp.suse.com/pub/suse/axp/update/6.4/n1/ypclient-3.4-95.alpha.rpm 6aea95ca27245eb3df72da7596af3321 source rpm: ftp://ftp.suse.com/pub/suse/axp/update/6.4/zq1/ypserv-1.3.11-95.src.rpm a4bf635b9ee4bdefc29b7e6e1cf0cf41 SuSE-6.3 ftp://ftp.suse.com/pub/suse/axp/update/6.3/n1/ypclient-3.4-95.alpha.rpm b68f8690b7dc554ac9098c83f9c633cd source rpm: ftp://ftp.suse.com/pub/suse/axp/update/6.3/zq1/ypserv-1.3.11-95.src.rpm ef0a026d078847d0958118bbbc46b99e PPC Power PC Platform: SuSE-6.4 ftp://ftp.suse.com/pub/suse/ppc/update/6.4/n1/ypclient-3.4-95.ppc.rpm 26080b1443a3daa1de64c876ae36e6f2 source rpm: ftp://ftp.suse.com/pub/suse/ppc/update/6.4/zq1/ypserv-1.3.11-95.src.rpm 4f0904d73c98c8b9737d5ac34b7a4dd5 ______________________________________________________________________________ 2) Pending vulnerabilities in SuSE Distributions and Workarounds: Another security announcement is following this advisory. ______________________________________________________________________________ 3) standard appendix: 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>. =============================================== Regards, Roman Drahtmüller. - - -- - - | Roman Drahtmüller <draht(a)suse.de> // "Caution: Cape does | SuSE GmbH - Security Phone: // not enable user to fly." | Nürnberg, Germany +49-911-740530 // (Batman Costume warning label) | - - ______________________________________________________________________________ The information in this advisory may be distributed or reproduced, provided that the advisory is not modified in any way. 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 2048/3D25D3D9 1999/03/06 SuSE Security Team <security(a)suse.de> - -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.3i 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 L0oixF12Cg== =pIeS - -----END PGP PUBLIC KEY BLOCK----- -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQEVAwUBOe3b5Hey5gA9JdPZAQHOngf9G0Rn/snskVaDJ3uKXuBiR8n0K8gvCFLe 00BXSE0X1X11rKrnumP7oFzOOby0A69R8n/tm4jFrODuxBep7qVkUtd5Br5uk2Vj qMeSe+AcA3BVib1qOiacgz4YnZo96BvUBtDR/XhVxBgq+C7JWu4hxY4tsvyiYqOw w/HN8KKf2W5t90TUbEap26hcjNQGC2dqTqdo3ERKCraKPJc4/omzF23yadlyYKfk 7yL7XGGop6zISP94CNjd0xVfAORsuvcj6Y5MI9RETEk4+W5G6sqqpUDX2FoTtdUB LxFyIu5zRuIbrUi/ZpGTjDMm7k70zli9TsnEtdPCu3asvJInRrTRqA== =kwtV -----END PGP SIGNATURE-----

1 0

RE: [suse-security] legal possibilities of attack reaction
by bacano＠esoterica.pt 18 Oct '00

18 Oct '00

Sorry, this is wrong ... > Incidents mailing lists: > 1. Send an e-mail message to LISTSERV(a)SECURITYFOCUS.COM from the > subscribed address with a message body of: UNSUBSCRIBE INCIDENTS This is right ... Send an e-mail message to LISTSERV(a)SECURITYFOCUS.COM with a message body of: SUBSCRIBE INCIDENTS Lastname, Firstname [ ]'s bacano --------------------------------------------- Esta mensagem foi enviada usando o WebPOP II. http://www.via-net-works.pt/email

1 0

RE: [suse-security] legal possibilities of attack reaction
by bacano＠esoterica.pt 18 Oct '00

18 Oct '00

Hi2all A nice paper to start: http://www.enteract.com/~lspitz/ids.html Carnegie Mellon SEI document on responding to intrusions: http://www.securityfocus.com/data/library/sim006.pdf For search documentation on the issue, regarding US laws: www.gao.gov Reports and proceedings, regarding german CERT: http://www.cert.dfn.de/dfn/berichte/ For spending some money, get the step-by-step from SANS: http://www.sans.org/newlook/publications/incident_handling.htm Incidents mailing lists: 1. Send an e-mail message to LISTSERV(a)SECURITYFOCUS.COM from the subscribed address with a message body of: UNSUBSCRIBE INCIDENTS 2. Send an e-mail message to LISTSERV(a)SECURITYFOCUS.COM with a message body of: SUBSCRIBE FOCUS-IH Lastname, Firstname [ ]'s bacano --------------------------------------------- Esta mensagem foi enviada usando o WebPOP II. http://www.via-net-works.pt/email

1 0

Missing: sendmail.rpm
by gerhard.possler＠westernacher.de 18 Oct '00

18 Oct '00

Hi all, i am missing the link to sendmail.rpm in http://www.suse.de/de/support/download/updates/70_i386.html last week it was there..... ;-) on ftp-Server is this file present...... regards gerhard possler ------------------------------------------------------------------------ Gerhard Possler "Wer neue Wege geht, braucht starke Partner." Westernacher AG Am Hubengut 3 76149 Karlsruhe, Germany phone: +49-721/9772-0 fax: +49-721/9772-188 http://www.westernacher.de

1 0

Virus Scanners
by Duane Kehoe 18 Oct '00

18 Oct '00

My company is going to be moving our email services in house in the near future and we are probably going with the SuSE IMAP server does anyone have a suggestion about a server level virus scanner, since most of our clients are unfortunately windows this is a highly significant issue. We are looking for a scanner with capabilities to include detection, cleaning, and if unable to clean removal of infected files, attachments, or entire emails. Thanks in advance for any suggestions or advice. -- ________________________________________________________ Duane Kehoe Phone # 414.908.1814 MIS Department Fax # 414.908.1814 Weyco Group, Inc. Email: dkehoe(a)weycogroup.com

2 1

OTP for linux
by Norbert Preining 18 Oct '00

18 Oct '00

Hi there! Please can someone tell me what the best system/package is for getting otp working on a linux system with pam. I want to make connection only working via ssh or otp. Thanks a lot. Best wishes Norbert Preining -- ciao norb +-------------------------------------------------------------------+ | Norbert Preining http://www.logic.at/people/preining | | University of Technology Vienna, Austria preining(a)logic.at | | DSA: 0x09C5B094 (RSA: 0xCF1FA165) mail subject: get [DSA|RSA]-key | +-------------------------------------------------------------------+

1 0

RE: [suse-security] How FW-Router w/o masquerading ?
by Reckhard, Tobias 18 Oct '00

18 Oct '00

Hi again > Hi. Before all, I'd like to thank Steffen and Tobias for their > answers. > Don't mention it. > Effectively, NAT ("generic" NAT ;)) isn't a security device, but it's > quite clear that NAT by itself provices some kind of security. Not the > security many people want, but a bit at least. > A little bit, I wouldn't overestimate it. IMHO, people are highly susceptible to a false sense of security in the scenario you describe. > Suppose the following intranet: > > ISDN Router > | > Switch > | | | > A B C ... > > This network is connected to the ISP (/Internet) via ISDN. The router > receives a (dinamic) real IP whenever it re-connect to ISP account. > The intranet objetive is providing Internet connectivity to the > employers in a firm / etc.. :) I mean, no services are provided to the > Internet community from the intranet (no daemons at border gateway). Finally, the ISDN router is performing PAT. What border gateway? You're connecting the internal network to the Internet with a PAT router, that's it. Purely network level stuff, no application layer gateways involved. > A, B, C are machines belonging the intranet (therefore they have > private range IP's). They are workstations, used to access the > Internet. > > 1) Let's think about how to attack it. Supposing an attacker has got > our (real) IP (one of the ISDN router; the other one is private). How > could the hacker attack machine A (the same applies for B, C...)? > For a start, he could attack the router itself. Most of them offer administrative functions to the network, such as Telnet, HTTP or SNMP access. Most also probably have default passwords on these services, so it could be simple to just login to the box. A fair number of routers also provide other services, such as echo, finger, timestamp, etc.. Most of these can be abused in some form or other, if not to cause harm to the router's owner then to third parties (for example, you could spoof your IP address to the broadcast address of a victim network, send echo packets to the router and the victim network will be hit with all of the replies). You can play tricks with routing protocols, if the router is performing dynamic routing. There are many ways to compromise routers. You can also, of course, hijack active sessions, PAT shouldn't make this any more difficult by itself (though sequence numbers could pose a problem). UDP transactions are also a prime target, since PAT needs to make pretty broad assumptions concerning UDP, as the protocol is connectionless, yet PAT requires connections to work. So what PAT implementations normally do is that they establish a reverse translation rule for any UDP packets leaving the internal network that stays in place for a certain amount of time. You can push basically any UDP content through this virtual connection (provided you spoof the source IP address) and most probably each and every packet you send through will reset the timeout counter to zero. Then there's attacks using protocols that don't let themselves be PATed easily, such as FTP, Quake, Battle.Net, IRC, CuSeeMe, H.323, etc... Most PATs have special code to be able to handle these protocols. However, since they work at the network level, they typically don't posess the same level of knowledge as the real applications. And more often than not, these modules are concerned with getting the protocol to work at all, not to secure it. Don't count on them to enhance security, rather I'd expect them to actually reduce it. Wahey! Ain't PAT a great security device? ;-) > At > first approach, let's suppose workstations users are > well-security-educated people, I mean, people who doesn't run > executables without checking them for virus, etc (so the chance a > trojan attempt was successful is zero) (yes, hard to believe :)). > Um, yeah, let me know when you're back in the real world. I work for a security consulting firm and one of our most successful means of analysing networks when we pretend-play 'hackers' is a malicious script that we send to employees of the customer company. That and other social attacks work real great. Humans are so much easier to take advantage of than machines.. > 2) Let's suppose I want to install a packet filter (for example, a > linux box router with ipchains).Let's name "fw" to this new machine. > I'd put it between the router and the switch (right?) and both ports > would have private IP's. > OK. Oh, the placement is correct, yes. > - 2.1) Which type of rules would you put for defeating attacks *from* > the Internet? (taking into account that NAT itself stops "basically" > many of these attacks). This is something I haven't got clear at all. > First of all, deny or reject everything. Then open up what you need. That's the secure approach. > - 2.2) Which type of rules would you put concerning the internal side? > This depends entirely on your situation. Many people like to be restrictive about what gets into their network, yet liberal about what goes out. Security people are careful about both. > I'll also appreciate any new ideas, reference to a good fw paper > *based on this scenario*, etc. > Actually, your scenario is very common, however, I don't know of any document that gives you details exactly on how to do it right. And IMHO there can't be *one* paper about it, as there are too many variables in the mix. IMHO, you should get good overall knowledge on the subject -- after all, your setup is merely one variation of the general thing. You shouldn't, again IMHO, be trying to learn how to deal with your situation only, but rather how things work and are done generally and then apply that to your situation. This way, if your setup should change, which it probably will in the not too distant future, you'll be able to handle it. Otherwise, you'd have to start from scratch. Oh, all of the views in this email are mine and don't reflect anything about my employer. Regards -- Tobias Reckhard secunet Security Networks AG Tel : +49(6196)95888-42 Mergenthalerallee 77 Fax : +49(6196)95888-88 D-65760 Eschborn E-Mail: reckhard(a)secunet.de

1 0