Re: ipmasq + port filtering recipe?
On Fri, Mar 15, 2002 at 05:11:37PM -0500, Luke Scharf wrote: I've apt-get install'd the ipmasq package and the IPMasq functionality works great. What I'd like to do now is to use ipchains to do the following: 1. On the external interface, I would like to only accept traffic from port 22 and port 80. Here's what I did for DNS(ISP and Root Servers in Binds hints), NTP, iand SSH; (SSH only uses protocol 2, and pubkeyauthentication) Copy I90external.def to I90external.rul Add these lines; $IPCHAINS -A input -j ACCEPT -i $i -s 194.168.4.100 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 194.168.4.100 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 194.168.8.100 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 194.168.8.100 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 128.8.10.90 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 128.8.10.90 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 198.41.0.4 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 198.41.0.4 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 128.63.2.53 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 128.63.2.53 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 192.33.4.12 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 192.33.4.12 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 192.112.36.4 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 192.112.36.4 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 192.5.5.241 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 192.5.5.241 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 128.9.0.107 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 128.9.0.107 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 198.41.0.10 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 198.41.0.10 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 193.0.14.129 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 193.0.14.129 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 198.32.64.12 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 198.32.64.12 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 202.12.27.33 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 202.12.27.33 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 192.36.148.17 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 192.36.148.17 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 192.203.230.10 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 192.203.230.10 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 158.43.128.33 123 -d $IPOFIF/32 123 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 194.168.4.76 123 -d $IPOFIF/32 123 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 80.0.159.1123 -d $IPOFIF/32 123 -p udp $IPCHAINS -A input -j ACCEPT -i $i -d $IPOFIF/32 22 -p tcp -l $IPCHAINS -A input -j ACCEPT -i $i -d $IPOFIF/32 22 -p udp -l $IPCHAINS -A input -j ACCEPT -i $i --destination-port 1025: -p tcp $IPCHAINS -A input -j ACCEPT -i $i --destination-port 1025: -p udp $IPCHAINS -A input -j DENY -i $i -d $IPOFIF/32 1:1024 -p tcp -l $IPCHAINS -A input -j DENY -i $i -d $IPOFIF/32 1:1024 -p udp -l 2. The internal interface should be wide open - the internal network we trust the users who are physically in the room not to be malicious. This is the default behavior of IPMasq. HTH, Simon -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: wierd connection attempt
Josh Frick, 2002-Mar-16 00:21 -0500: Yes, I most definitely was confused. Thank you for the clarification. I'm not familiar with the RFCs. My question, however, remains: aren't network addresses in that range supposed to be prevented from crossing (i.e. being routed) the internet? If they are, then it's possible this traffic is local, is it not? I believe my DSL ISP assigns a private class IP address before connection. Would this then indicate that the connection attempt was made by another customer of the person's ISP? I have a cable modem and that little bugger sends out constant broadcasts from 192.168.100.1, which is itself. It turns out that the modem has a built in DHCP server. I set a filter on my firewall to drop it all silently. Perhaps you DSL modem as the same. I tested this by disconnecting the modem from the public side and plugging my laptop directly into it and running my dhcp client. I got an address on that subnet and the gateway address was set to 192.168.100.1. jc -- Jeff CoppockSystems Engineer Diggin' Debian Admin and User -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Purpose of this list
On Sat, Mar 16, 2002 at 11:43:41PM +0530, Sandip Bhattacharya wrote: Pardon my ignorance, but I was under the impression that this list is only about official Security Announcements for Debian(DSA), and not a general discussion on security. Am I on the wrong list or did I read the list description incorrectly ? You probably want [EMAIL PROTECTED] rather than debian-security. -- You grabbed my hand and we fell into it, like a daydream - or a fever. msg06006/pgp0.pgp Description: PGP signature
Re: Purpose of this list
On Sat, Mar 16, 2002 at 11:43:41PM +0530, Sandip Bhattacharya wrote: Pardon my ignorance, but I was under the impression that this list is only about official Security Announcements for Debian(DSA), and not a general discussion on security. Am I on the wrong list or did I read the list description incorrectly ? You are confusing debian-security with debian-security-announce. You want the latter. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html msg06007/pgp0.pgp Description: PGP signature
Re: Purpose of this list
Seems like you did both. You need [EMAIL PROTECTED] On Sat, Mar 16, 2002 at 11:43:41PM +0530, Sandip Bhattacharya wrote: Pardon my ignorance, but I was under the impression that this list is only about official Security Announcements for Debian(DSA), and not a general discussion on security. Am I on the wrong list or did I read the list description incorrectly ? - Sandip -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- shiftee [EMAIL PROTECTED] PGP Key: [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Purpose of this list
Quoting Sandip Bhattacharya ([EMAIL PROTECTED]): Pardon my ignorance, but I was under the impression that this list is only about official Security Announcements for Debian(DSA), and not a general discussion on security. Am I on the wrong list or did I read the list description incorrectly ? You're the only one who can decide if he's on the wrong list; debian-security-announce is for debian security announcements (obviously). Greets, Robert -- Linux Generation encrypted mail preferred. finger [EMAIL PROTECTED] for my GnuPG/PGP key. All extremists should be taken out and shot. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Purpose of this list
On Sat, Mar 16, 2002 at 23:43:41 +0530, Sandip Bhattacharya wrote: Am I on the wrong list You're on the wrong list. debian-security is listed on http://lists.debian.org under Development as Security in Debian. You're looking for debian-security-announce which is a restricted posting list featuring security announcements only. HTH, Ray -- The Linux movement has been independent of anything Microsoft is doing. It's one of those cosmic movements in the industry, like the emergence of the Internet, or microprocessors. Irving Wladawsky-Berger, IBM VP in http://www.informationweek.com/793/ibm.htm -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Purpose of this list
debian-security-announce sounds like the list you want. On Sat, Mar 16, 2002 at 11:43:41PM +0530, Sandip Bhattacharya wrote: Pardon my ignorance, but I was under the impression that this list is only about official Security Announcements for Debian(DSA), and not a general discussion on security. Am I on the wrong list or did I read the list description incorrectly ? - Sandip -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SNMP problems published by Schneier/Counterpane
Has anyone else heard of this SNMP problem? Are we up to date with the security fixes on stable, etc? Here is a quick excerpt (CRYPTO-GRAM, March 15, 2002): SNMP Vulnerabilities SNMP is the Simple Network Management Protocol, the most popular protocol to manage network devices. Hundreds, possibly thousands, of products use it. Last fall, a group of Finnish researchers discovered multiple vulnerabilities in SNMP. By exploiting the vulnerabilities, an attacker could cause a denial-of-service attack, and in some cases take over control of the system. The vulnerabilities concerns SNMP's trap-handling and request-handling functions, and stem from problems in the reference code (probably) used inside the Abstract Syntax Notation (ASN.1) and Basic Encoding Rules (BER). The SNMP vulnerabilities affect hundreds of different devices: operating systems, network equipment, software packages, even things like digital cameras. It's a BIG deal. It's actually a bigger deal than has been reported. ASN.1 is used inside a lot of other applications, such as OpenSSL. These vulnerabilities aren't limited to SNMPv1; that's just the only thing that's been well-publicized at this point. (The recently reported problems in mod_ssl and Apache are apparently related to this, too.) The history of the vulnerability's discovery and publication is an interesting story, and illustrates the tension between bug secrecy and full disclosure. A research group from the Oulu University Secure Programming Group in Oulu, Finland, first discovered this problem in October 2001, and decided not to publish because it was such a large problem. CERT took on the task of coordinating the fix with the major software vendors, and has said that the reason publication was delayed so long is that there were so many vendors to contact. CERT even had problems with vendors not taking the problem seriously, and had to spend considerable effort to get the right people to pay attention. Lesson #1: If bugs are secret, many vendors won't bother patching their systems. The vulnerability was published on 12 February. Supposedly, this was two weeks earlier than planned, and because the story was leaking too much. CERT felt that early publication was better than widespread rumors. Some companies were caught off-guard. Even though they had months to patch their systems, they weren't ready and needed those two extra weeks. Some companies didn't bother to start worrying about the problem until publication was imminent. Lesson #2: It is only the threat of publication that makes many vendors patch their systems. (To be fair, many companies did a great job proactively patching their systems. And in many cases, the patches were not trivial. Some vendors were swamped by the sheer number of different products and releases they had to patch and test. And I stress test, because patching mature code carries a strong probability of either not fixing the problem or of introducing new problems.) When CERT finally published and the Oulu Web site went live, there were all sorts of reactions. Some tried to capitalize on the announcement to sell their products; others tried to minimize it. Many vendors had no idea if they were vulnerable or not But because publication included demonstration code -- the PROTOS tool -- vendors and security companies were able to test networks and equipment. Lesson #3: Publication must include enough information to reproduce the vulnerability; otherwise, there's no way for anyone to determine how serious the threat is. And Lesson #4: If there is no way to independently verify the vulnerability, then organizations are forced to rely on information from potentially biased sources. As of this writing, there have been no credible reports of this vulnerability being exploited in the wild. Counterpane's monitoring has not detected any of our customers being attacked via this vulnerability. This is not to say that no one has -- writing an attack tool is a straightforward programming task -- but no one has published such a tool and put it in the hands of the script kiddies. Lesson #5: Publication does not automatically mean the vulnerability will be exploited. So far we've been lucky. But a tool could show up at any time, so relying on that luck would not be smart. And even though everyone has been urged to patch their systems and products, some will not. Even if it takes months before someone writes an attack tool, it will work against a surprisingly large subset of systems. Lesson #6: Publication increases the likelihood that a vulnerability will be exploited. And there are a lot of systems for which patches will never be available. Many router vendors have gone out of business in the last few years, and not every mom-and-pop software company out there has the money or clue to replace their hardware because their code has a problem. Lesson #7:
Re: SNMP problems published by Schneier/Counterpane
On Sat, Mar 16, 2002 at 04:57:42PM -0800, Xeno Campanoli wrote: Has anyone else heard of this SNMP problem? Are we up to date with the security fixes on stable, etc? That's ancient history. The fix was released on Feb. 14. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html msg06015/pgp0.pgp Description: PGP signature
Re: wierd connection attempt
Josh Frick wrote: Yes, I most definitely was confused. Thank you for the clarification. I'm not familiar with the RFCs. My question, however, remains: aren't network addresses in that range supposed to be prevented from crossing (i.e. being routed) the internet? If they are, then it's possible this traffic is local, is it not? I believe my DSL ISP assigns a private class IP address before connection. Would this then indicate that the connection attempt was made by another customer of the person's ISP? Exactly. Perhaps this person's ISP is not the filtering the bogus messages from reaching it's other customers, or perhaps the messages are passing through outside routers that are not complying with the RFC, and allowing them to travel so far. It's most likely that it is coming from another subscriber to the ISP's network. -Will Wesley, CCNA A prediction is worth twenty explanations. -- K. Brecher
Re: 2.2.18 exploit, and updating the kernel
On Fri, Mar 15, 2002 at 06:16:22PM -0500, [EMAIL PROTECTED] wrote: I have a potato system - with the 2.2.18 kernel. Somone has gotten into a box on my network and used this exploit to gain root: http://:infected.ilm.net/xpl0itz/l1nux/epcs2.c+epcs2hl=enie=ISO-8859-1 The other boxes that are net accessible are openbsd -- This system is a dual p6 so I need debian for smp. Is there a proper 'debian' way to go about patching the kernel against this exploit, or updating the kernel to 2.4. 2.2.18 is deprecated. Use the latest one (2.2.19) in potato. It's rock solid (some security patches were backported in it). -- Francesco P. Lovergine
Re: udp port 32794
Noah L. Meyerhans wrote: On Fri, Mar 15, 2002 at 09:09:15PM +0100, Roland Stoll wrote: i'm wondering what this could be. Is it a known exploit, or just a new P2P software like gnutella/kaza/etc ? It is traceroute. Ah, i remember that traceroute connects to high ports, increments the ttl and waits for a dest.-unreachable icmp. funny, that i got traces from over hundred unique IP addresses. thank you for the hint and regards, Roland
Re: ipmasq + port filtering recipe?
On Fri, Mar 15, 2002 at 05:11:37PM -0500, Luke Scharf wrote: I've apt-get install'd the ipmasq package and the IPMasq functionality works great. What I'd like to do now is to use ipchains to do the following: 1. On the external interface, I would like to only accept traffic from port 22 and port 80. Here's what I did for DNS(ISP and Root Servers in Binds hints), NTP, iand SSH; (SSH only uses protocol 2, and pubkeyauthentication) Copy I90external.def to I90external.rul Add these lines; $IPCHAINS -A input -j ACCEPT -i $i -s 194.168.4.100 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 194.168.4.100 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 194.168.8.100 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 194.168.8.100 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 128.8.10.90 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 128.8.10.90 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 198.41.0.4 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 198.41.0.4 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 128.63.2.53 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 128.63.2.53 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 192.33.4.12 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 192.33.4.12 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 192.112.36.4 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 192.112.36.4 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 192.5.5.241 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 192.5.5.241 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 128.9.0.107 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 128.9.0.107 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 198.41.0.10 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 198.41.0.10 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 193.0.14.129 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 193.0.14.129 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 198.32.64.12 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 198.32.64.12 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 202.12.27.33 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 202.12.27.33 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 192.36.148.17 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 192.36.148.17 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 192.203.230.10 53 -d $IPOFIF/32 -p tcp $IPCHAINS -A input -j ACCEPT -i $i -s 192.203.230.10 53 -d $IPOFIF/32 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 158.43.128.33 123 -d $IPOFIF/32 123 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 194.168.4.76 123 -d $IPOFIF/32 123 -p udp $IPCHAINS -A input -j ACCEPT -i $i -s 80.0.159.1123 -d $IPOFIF/32 123 -p udp $IPCHAINS -A input -j ACCEPT -i $i -d $IPOFIF/32 22 -p tcp -l $IPCHAINS -A input -j ACCEPT -i $i -d $IPOFIF/32 22 -p udp -l $IPCHAINS -A input -j ACCEPT -i $i --destination-port 1025: -p tcp $IPCHAINS -A input -j ACCEPT -i $i --destination-port 1025: -p udp $IPCHAINS -A input -j DENY -i $i -d $IPOFIF/32 1:1024 -p tcp -l $IPCHAINS -A input -j DENY -i $i -d $IPOFIF/32 1:1024 -p udp -l 2. The internal interface should be wide open - the internal network we trust the users who are physically in the room not to be malicious. This is the default behavior of IPMasq. HTH, Simon
Re: wierd connection attempt
Josh Frick, 2002-Mar-16 00:21 -0500: Yes, I most definitely was confused. Thank you for the clarification. I'm not familiar with the RFCs. My question, however, remains: aren't network addresses in that range supposed to be prevented from crossing (i.e. being routed) the internet? If they are, then it's possible this traffic is local, is it not? I believe my DSL ISP assigns a private class IP address before connection. Would this then indicate that the connection attempt was made by another customer of the person's ISP? I have a cable modem and that little bugger sends out constant broadcasts from 192.168.100.1, which is itself. It turns out that the modem has a built in DHCP server. I set a filter on my firewall to drop it all silently. Perhaps you DSL modem as the same. I tested this by disconnecting the modem from the public side and plugging my laptop directly into it and running my dhcp client. I got an address on that subnet and the gateway address was set to 192.168.100.1. jc -- Jeff CoppockSystems Engineer Diggin' Debian Admin and User
Purpose of this list
Pardon my ignorance, but I was under the impression that this list is only about official Security Announcements for Debian(DSA), and not a general discussion on security. Am I on the wrong list or did I read the list description incorrectly ? - Sandip
Re: Purpose of this list
On Sat, Mar 16, 2002 at 11:43:41PM +0530, Sandip Bhattacharya wrote: Pardon my ignorance, but I was under the impression that this list is only about official Security Announcements for Debian(DSA), and not a general discussion on security. Am I on the wrong list or did I read the list description incorrectly ? You probably want debian-security-announce@lists.debian.org rather than debian-security. -- You grabbed my hand and we fell into it, like a daydream - or a fever. pgpQ8H13uPuUM.pgp Description: PGP signature
Re: Purpose of this list
On Sat, Mar 16, 2002 at 11:43:41PM +0530, Sandip Bhattacharya wrote: Pardon my ignorance, but I was under the impression that this list is only about official Security Announcements for Debian(DSA), and not a general discussion on security. Am I on the wrong list or did I read the list description incorrectly ? You are confusing debian-security with debian-security-announce. You want the latter. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpFo16vfTCWU.pgp Description: PGP signature
Re: Purpose of this list
Seems like you did both. You need debian-security-announce@lists.debian.org On Sat, Mar 16, 2002 at 11:43:41PM +0530, Sandip Bhattacharya wrote: Pardon my ignorance, but I was under the impression that this list is only about official Security Announcements for Debian(DSA), and not a general discussion on security. Am I on the wrong list or did I read the list description incorrectly ? - Sandip -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED] -- shiftee [EMAIL PROTECTED] PGP Key: [EMAIL PROTECTED]
Re: Purpose of this list
Quoting Sandip Bhattacharya ([EMAIL PROTECTED]): Pardon my ignorance, but I was under the impression that this list is only about official Security Announcements for Debian(DSA), and not a general discussion on security. Am I on the wrong list or did I read the list description incorrectly ? You're the only one who can decide if he's on the wrong list; debian-security-announce is for debian security announcements (obviously). Greets, Robert -- Linux Generation encrypted mail preferred. finger [EMAIL PROTECTED] for my GnuPG/PGP key. All extremists should be taken out and shot.
Re: Purpose of this list
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Said Sandip Bhattacharya on Sat, Mar 16, 2002 at 11:43:41PM +0530: Pardon my ignorance, but I was under the impression that this list is only about official Security Announcements for Debian(DSA), and not a general discussion on security. Am I on the wrong list or did I read the list description incorrectly ? Based on what I've seen, this is for Debian-related security discussion, and debian-security-news is for announcements. - -- [!] Justin R. Miller [EMAIL PROTECTED] PGP 0xC9C40C31 -=- http://codesorcery.net http://www.cnn.com/2002/ALLPOLITICS/01/29/inv.terror.probe/ -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE8k5gX94d6K8nEDDERAq52AKCFssp1psq2C4HG9+TL9Qs+UusujACaAgJz Y2CumO3MHVBp9ZdJJi8UCtA= =xVXv -END PGP SIGNATURE-
Re: Purpose of this list
On Sat, Mar 16, 2002 at 23:43:41 +0530, Sandip Bhattacharya wrote: Am I on the wrong list You're on the wrong list. debian-security is listed on http://lists.debian.org under Development as Security in Debian. You're looking for debian-security-announce which is a restricted posting list featuring security announcements only. HTH, Ray -- The Linux movement has been independent of anything Microsoft is doing. It's one of those cosmic movements in the industry, like the emergence of the Internet, or microprocessors. Irving Wladawsky-Berger, IBM VP in http://www.informationweek.com/793/ibm.htm
Re: Purpose of this list
debian-security-announce sounds like the list you want. On Sat, Mar 16, 2002 at 11:43:41PM +0530, Sandip Bhattacharya wrote: Pardon my ignorance, but I was under the impression that this list is only about official Security Announcements for Debian(DSA), and not a general discussion on security. Am I on the wrong list or did I read the list description incorrectly ? - Sandip -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
SNMP problems published by Schneier/Counterpane
Has anyone else heard of this SNMP problem? Are we up to date with the security fixes on stable, etc? Here is a quick excerpt (CRYPTO-GRAM, March 15, 2002): SNMP Vulnerabilities SNMP is the Simple Network Management Protocol, the most popular protocol to manage network devices. Hundreds, possibly thousands, of products use it. Last fall, a group of Finnish researchers discovered multiple vulnerabilities in SNMP. By exploiting the vulnerabilities, an attacker could cause a denial-of-service attack, and in some cases take over control of the system. The vulnerabilities concerns SNMP's trap-handling and request-handling functions, and stem from problems in the reference code (probably) used inside the Abstract Syntax Notation (ASN.1) and Basic Encoding Rules (BER). The SNMP vulnerabilities affect hundreds of different devices: operating systems, network equipment, software packages, even things like digital cameras. It's a BIG deal. It's actually a bigger deal than has been reported. ASN.1 is used inside a lot of other applications, such as OpenSSL. These vulnerabilities aren't limited to SNMPv1; that's just the only thing that's been well-publicized at this point. (The recently reported problems in mod_ssl and Apache are apparently related to this, too.) The history of the vulnerability's discovery and publication is an interesting story, and illustrates the tension between bug secrecy and full disclosure. A research group from the Oulu University Secure Programming Group in Oulu, Finland, first discovered this problem in October 2001, and decided not to publish because it was such a large problem. CERT took on the task of coordinating the fix with the major software vendors, and has said that the reason publication was delayed so long is that there were so many vendors to contact. CERT even had problems with vendors not taking the problem seriously, and had to spend considerable effort to get the right people to pay attention. Lesson #1: If bugs are secret, many vendors won't bother patching their systems. The vulnerability was published on 12 February. Supposedly, this was two weeks earlier than planned, and because the story was leaking too much. CERT felt that early publication was better than widespread rumors. Some companies were caught off-guard. Even though they had months to patch their systems, they weren't ready and needed those two extra weeks. Some companies didn't bother to start worrying about the problem until publication was imminent. Lesson #2: It is only the threat of publication that makes many vendors patch their systems. (To be fair, many companies did a great job proactively patching their systems. And in many cases, the patches were not trivial. Some vendors were swamped by the sheer number of different products and releases they had to patch and test. And I stress test, because patching mature code carries a strong probability of either not fixing the problem or of introducing new problems.) When CERT finally published and the Oulu Web site went live, there were all sorts of reactions. Some tried to capitalize on the announcement to sell their products; others tried to minimize it. Many vendors had no idea if they were vulnerable or not But because publication included demonstration code -- the PROTOS tool -- vendors and security companies were able to test networks and equipment. Lesson #3: Publication must include enough information to reproduce the vulnerability; otherwise, there's no way for anyone to determine how serious the threat is. And Lesson #4: If there is no way to independently verify the vulnerability, then organizations are forced to rely on information from potentially biased sources. As of this writing, there have been no credible reports of this vulnerability being exploited in the wild. Counterpane's monitoring has not detected any of our customers being attacked via this vulnerability. This is not to say that no one has -- writing an attack tool is a straightforward programming task -- but no one has published such a tool and put it in the hands of the script kiddies. Lesson #5: Publication does not automatically mean the vulnerability will be exploited. So far we've been lucky. But a tool could show up at any time, so relying on that luck would not be smart. And even though everyone has been urged to patch their systems and products, some will not. Even if it takes months before someone writes an attack tool, it will work against a surprisingly large subset of systems. Lesson #6: Publication increases the likelihood that a vulnerability will be exploited. And there are a lot of systems for which patches will never be available. Many router vendors have gone out of business in the last few years, and not every mom-and-pop software company out there has the money or clue to replace their hardware because their code has a problem. Lesson #7:
Re: SNMP problems published by Schneier/Counterpane
On Sat, Mar 16, 2002 at 04:57:42PM -0800, Xeno Campanoli wrote: Has anyone else heard of this SNMP problem? Are we up to date with the security fixes on stable, etc? That's ancient history. The fix was released on Feb. 14. noah -- ___ | Web: http://web.morgul.net/~frodo/ | PGP Public Key: http://web.morgul.net/~frodo/mail.html pgpZu9WnnFzjR.pgp Description: PGP signature
