Re: Is it time to block all Microsoft protocols in the core?
On Wednesday, Jan 29, 2003, at 04:56 Asia/Katmandu, Steven M. Bellovin wrote: In message <[EMAIL PROTECTED]>, Barney Wolff writes: On Wed, Jan 29, 2003 at 03:50:34AM +0545, Joe Abley wrote: On Wednesday, Jan 29, 2003, at 01:25 Asia/Katmandu, Joe Abley wrote: On FreeBSD, NetBSD, OpenBSD and Darwin/Mac OS X (the only xterms I happen to have open right now) this is not the case, and has not been for some time. I presume, perhaps na?vely, that other operating systems have done something similar. This is not right. Guess I was typing "man" in the wrong xterms. FreeBSD (4.x, 5.x) listens to the network by default (and can be persuaded not to with a "-s" flag). NetBSD (1.6) does the same. You were right the first time, at least for FreeBSD. The "-s" flag is applied by default - see /etc/defaults/rc.conf . Not quite as idiot-proof as a compiled-in default, but way better than defaulting to listening. The same is true of NetBSD 1.6; look in the same place. Serves me right for contradicting myself.
Re: Is it time to block all Microsoft protocols in the core?
In message <[EMAIL PROTECTED]>, Barney Wolff writes: > >On Wed, Jan 29, 2003 at 03:50:34AM +0545, Joe Abley wrote: >> >> On Wednesday, Jan 29, 2003, at 01:25 Asia/Katmandu, Joe Abley wrote: >> >> >On FreeBSD, NetBSD, OpenBSD and Darwin/Mac OS X (the only xterms I >> >happen to have open right now) this is not the case, and has not been >> >for some time. I presume, perhaps na?vely, that other operating >> >systems have done something similar. >> >> This is not right. Guess I was typing "man" in the wrong xterms. >> >> FreeBSD (4.x, 5.x) listens to the network by default (and can be >> persuaded not to with a "-s" flag). NetBSD (1.6) does the same. > >You were right the first time, at least for FreeBSD. The "-s" flag >is applied by default - see /etc/defaults/rc.conf . Not quite as >idiot-proof as a compiled-in default, but way better than defaulting >to listening. The same is true of NetBSD 1.6; look in the same place. --Steve Bellovin, http://www.research.att.com/~smb (me) http://www.wilyhacker.com (2nd edition of "Firewalls" book)
Re: Is it time to block all Microsoft protocols in the core?
On Wednesday, Jan 29, 2003, at 01:25 Asia/Katmandu, Joe Abley wrote: On FreeBSD, NetBSD, OpenBSD and Darwin/Mac OS X (the only xterms I happen to have open right now) this is not the case, and has not been for some time. I presume, perhaps naïvely, that other operating systems have done something similar. This is not right. Guess I was typing "man" in the wrong xterms. FreeBSD (4.x, 5.x) listens to the network by default (and can be persuaded not to with a "-s" flag). NetBSD (1.6) does the same. Darwin/Mac OS X and OpenBSD do not listen by default (and can be persuaded to listen with a "-u" flag). (Looks like Darwin ships with OpenBSD's syslogd). Various people mailed me and told me that "Linux" does not listen by default, presumably for commonly-packaged values of "Linux". Joe
Re: Is it time to block all Microsoft protocols in the core?
Joe Abley wrote: You're using mixed tense in these sentences, so I can't tell whether you think that syslog's network port is open by default on operating systems today. On FreeBSD, NetBSD, OpenBSD and Darwin/Mac OS X (the only xterms I happen to have open right now) this is not the case, and has not been for some time. I presume, perhaps naïvely, that other operating systems have done something similar. Current versions of Linux appear to be safe. This is from the syslog package that ships with RedHat version 8 (sysklogd package version 1.4.1-10). NAME sysklogd - Linux system logging utilities. ... OPTIONS ... -rThis option will enable the facility to receive message from the network using an internet domain socket with the syslog service (see services(5)). The default is to not receive any messages from the network. This option is introduced in version 1.3 of the sysklogd package. Please note that the default behavior is the opposite of how older versions behave, so you might have to turn this on. The default RedHat installation does not turn on this option. Looking through RedHat's FTP server, their 4.2 distribution (the oldest on on their server) is at version 1.3-15, and therefore incorporates this feature. This release has a README dated 1997, and the sysklogd package on their server is dated December 1996. I would assume that other Linux distributions from the same era (1997 through the present) would also have sysklogd version 1.3 or later, and therefore have this feature. -- David
Re: Is it time to block all Microsoft protocols in the core?
On Monday, Jan 27, 2003, at 14:04 Asia/Katmandu, Sean Donelan wrote: Its not just a Microsoft thing. SYSLOG opened the network port by default, and the user has to remember to disable it for only local logging. You're using mixed tense in these sentences, so I can't tell whether you think that syslog's network port is open by default on operating systems today. On FreeBSD, NetBSD, OpenBSD and Darwin/Mac OS X (the only xterms I happen to have open right now) this is not the case, and has not been for some time. I presume, perhaps naïvely, that other operating systems have done something similar. [...] DESCRIPTION syslogd reads and logs messages to the system console, log files, other machines and/or users as specified by its configuration file. The options are as follows: [...] -u Select the historical ``insecure'' mode, in which syslogd will accept input from the UDP port. Some software wants this, but you can be subjected to a variety of attacks over the network, including attackers remotely filling logs. [...] Joe
Re: Is it time to block all Microsoft protocols in the core?
> AY> [I]t is a job of your customer to decide if they want to filter > AY> some ports from their network or if they want to contract you > AY> to do that for them. > > A job that many are incapable of performing. > > One must contact one's upstreams to enable BGP; the consequences > of freely-available, unfiltered BGP would be catastrophic. Most > people simply don't need BGP. Those who claim to need it are > required to follow rules set by their upstreams and the rest of > the Internet community. That is not correct. A customer that is multihoming does it. Single homed customer does not do it. > Packet filtering at the edge would be far from a panacea, and in > many ways would be a very bad thing, but perhaps it's time to re- > evaluate the "need" for every network to have complete end-to-end > connectivity. Some dialup providers and cable networks already > offer less than EtE. Some dialup providers and some cable networks. Alex
Re: Is it time to block all Microsoft protocols in the core?
AY> Date: Mon, 27 Jan 2003 14:16:40 -0500 (EST) AY> From: alex@... (Alex Yuriev) AY> [I]t is a job of your customer to decide if they want to filter AY> some ports from their network or if they want to contract you AY> to do that for them. A job that many are incapable of performing. One must contact one's upstreams to enable BGP; the consequences of freely-available, unfiltered BGP would be catastrophic. Most people simply don't need BGP. Those who claim to need it are required to follow rules set by their upstreams and the rest of the Internet community. Packet filtering at the edge would be far from a panacea, and in many ways would be a very bad thing, but perhaps it's time to re- evaluate the "need" for every network to have complete end-to-end connectivity. Some dialup providers and cable networks already offer less than EtE. Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
Re: Is it time to block all Microsoft protocols in the core?
> Date: Mon, 27 Jan 2003 14:01:33 -0500 (EST) > From: alex > > Filtering ASNs and adverts (BGP) at the edge generally is > > accepted as a good thing. The RADB is one's friend. > > > > Protocol/port equivalent, anyone? > > /etc/services? I was referring to end users registering the ports they need open, and filtering the rest in a heavy-handed manner a la edge BGP filtering. /etc/services ~= whois ??? ~= RADB Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
Re: Is it time to block all Microsoft protocols in the core?
> > I don't think it's so much of a problem of programs opening listen > > sockets as it is a problem of admins not properly controlling their > > networks and a certain software company pushing insecure features like > > printing over the internet that refuse to work from behind a firewall > > and have no direct proxy support. > > > > > This is the exact reason why any arguments to management to block NETBIOS > have failed. The reasons it is rejected are always the same: > > a) We're not responsible for our users getting infected through their own > ignorance > b) Some of our users refuse to use VPN or lack the knowledge to effectively > use it and want to use NETBIOS services over the Internet There are two different things that you are grouping together, when in fact they are separate. As an ISP, you have two networks. The first one of them is your internal network on which you may have MSSQL server or any other servers used by your company. The second network is the network to which you connect your customers. These two networks have two distinctly different security policies. I will venture as far as to say that you probably are filtering what comes in and what comes out of your internal network. On the other hand, you are proving IP transit to the customers. Filtering randon ports on the second network baffles me. Why would you do it? Dont you bill people for the traffic that they receive/get? Obviously, should your customer be attacked, you want to participate in coordination of the response, however, it is a job of your customer to decide if they want to filter some ports from their network or if they want to contract you to do that for them. Alex
Re: Is it time to block all Microsoft protocols in the core?
> > Filtering ASNs and adverts (BGP) at the edge generally is > accepted as a good thing. The RADB is one's friend. > > Protocol/port equivalent, anyone? /etc/services? Alex
Re: Is it time to block all Microsoft protocols in the core?
| c) We buy Cisco 5200's in mass volume because they support our rural | networks better than any other modem bank we've tried (welcome to Oklahoma | :) and the processor on this wonderful piece of hardware will not support | the overhead of using a per user access-list methodology to filter the | majority and whitelist those who need the service. Use different IP pools, one for regular users, one for whitelisted. Uplink hop filters netbios, ms-sql, common trojan ports before they get to customers based on destination IP being from regular pool. Rubens
Re: Is it time to block all Microsoft protocols in the core?
From: "Darren Pilgrim" > > Sean Donelan wrote: > > > Should ISPs start blocking all Microsoft protocols in self-defense? > > > I don't think it's so much of a problem of programs opening listen > sockets as it is a problem of admins not properly controlling their > networks and a certain software company pushing insecure features like > printing over the internet that refuse to work from behind a firewall > and have no direct proxy support. > > This is the exact reason why any arguments to management to block NETBIOS have failed. The reasons it is rejected are always the same: a) We're not responsible for our users getting infected through their own ignorance b) Some of our users refuse to use VPN or lack the knowledge to effectively use it and want to use NETBIOS services over the Internet c) We buy Cisco 5200's in mass volume because they support our rural networks better than any other modem bank we've tried (welcome to Oklahoma :) and the processor on this wonderful piece of hardware will not support the overhead of using a per user access-list methodology to filter the majority and whitelist those who need the service. If anyone has good recommendations for a strategy of getting around these arguments, I'd love to hear it. I personally want to protect my users from their own ignorance, particularly where NETBIOS is concerned. While win32 unbinds it from dialups in some cases, I'm still finding even the newer OS's binding on the dialups. I'm not sure why this is, but I suspect that virus infection in my network is coming from methods other than email; although my email protections do have bugs (need to fix those this week). Jack Bates Network Engineer BrightNet Oklahoma
Re: Is it time to block all Microsoft protocols in the core?
SD> Date: Mon, 27 Jan 2003 03:19:33 -0500 (EST) SD> From: Sean Donelan SD> Its not just a Microsoft thing. SYSLOG opened the network SD> port by default, and the user has to remember to disable it SD> for only local logging. Filtering ASNs and adverts (BGP) at the edge generally is accepted as a good thing. The RADB is one's friend. Protocol/port equivalent, anyone? (Of course, filtering BGP routes is much easier than filtering every last packet with forwarding time constraints...) Eddy -- Brotsman & Dreger, Inc. - EverQuick Internet Division Bandwidth, consulting, e-commerce, hosting, and network building Phone: +1 (785) 865-5885 Lawrence and [inter]national Phone: +1 (316) 794-8922 Wichita ~ Date: Mon, 21 May 2001 11:23:58 + (GMT) From: A Trap <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Please ignore this portion of my mail signature. These last few lines are a trap for address-harvesting spambots. Do NOT send mail to <[EMAIL PROTECTED]>, or you are likely to be blocked.
Re: Is it time to block all Microsoft protocols in the core?
Sean Donelan wrote: Should ISPs start blocking all Microsoft protocols in self-defense? All of my routers block netbios, DHCP, and packets with improper source addresses. But then I'm spending router memory and CPU cycles many people don't have. Since many of users install database products just for local use, why does the database open up a network port on the initial installation? Wouldn't it be better to ask the user, or only open the network port if its being used? Its not just a Microsoft thing. SYSLOG opened the network port by default, and the user has to remember to disable it for only local logging. I don't think it's so much of a problem of programs opening listen sockets as it is a problem of admins not properly controlling their networks and a certain software company pushing insecure features like printing over the internet that refuse to work from behind a firewall and have no direct proxy support.
Is it time to block all Microsoft protocols in the core?
On Mon, 27 Jan 2003, Phil Rosenthal wrote: > Has someone went and hacked the 5000 or so remaining infected hosts that > were hackable somehow, and patched/rebooted? Have you tried sending a UDP 1434 packet through a major Internet core network this weekend? Most of those machines are still blasting away, but the packets are getting dropped. It may be a long time before many of those filters are ever removed. I suspect Monday morning, ISP customer service centers are going to get calls from users asking why they can't access their MS-SQL databases across the Internet. Should ISPs start blocking all Microsoft protocols in self-defense? 135, 137, 138, 139, 322, 349, 445, 507, 522, 568, 569, 593, 612, 613, 691, 1232, 1270, 1433, 1434, 1477, 1478, 1512, 1607, 1711, 1723, 1731, 1745, 1801, 1863, 1895, 1900, 1944, 2106, 2234, 2382, 2383, 2393, 2394, 2460, 2504, 2525, 2701, 2702, 2703, 2704, 2724, 2869, 3020, 3074, 3126, 3132, 3268, 3269, 3343, 3389, 3535, 3544, 3587, 4350, 4500, 5678, 5679, 5720, 6073, 6588, 9753, 11320, 47624, Since many of users install database products just for local use, why does the database open up a network port on the initial installation? Wouldn't it be better to ask the user, or only open the network port if its being used? Its not just a Microsoft thing. SYSLOG opened the network port by default, and the user has to remember to disable it for only local logging.
