Anybody doing a "Code Green" for 1434?
Back when the Code Red worm came out, somebody wrote a program that responded to Code Red probes by using the same hole to break into the infected server and disable it. Is anybody doing that with this worm? Or does it step on the infected process too hard for that to work? Even if people don't want to run it on the open internet, due to concerns about appropriateness of reverse hacking, it might be useful for inside-the-firewall cleanup for corporations that get hit. Thanks; Bill Stewart, billstewart at att dot com bill.stewart at pobox dot com
On Mon, 27 Jan 2003 00:35:19 EST, "Stewart, William C (Bill), SALES" <billstewart@att.com> said:
Even if people don't want to run it on the open internet, due to concerns about appropriateness of reverse hacking, it might be useful for inside-the-firewall cleanup for corporations that get hit.
It's inappropriate inside a corporation for the same reason it's not right for the open internet. But hey, if you don't wanna get paid this time around because somebody installed a patch that rebooted the payroll server and it didn't come back.. Well.. it's your paycheck, not mine. I mean.. really. if a company needs a "code green" tool to clean up after this for their own internal stuff, the right answer isn't code green, the right answer is outsourcing their IT to someplace that has a clue. -- Valdis Kletnieks Computer Systems Senior Engineer Virginia Tech
On Mon, 27 Jan 2003, Stewart, William C (Bill), SALES wrote: : :Back when the Code Red worm came out, somebody wrote a program :that responded to Code Red probes by using the same hole to :break into the infected server and disable it. :Is anybody doing that with this worm? I understand your point, but: Wouldn't such a mechanism simply help to foster the laziness of those whose machines helped propagate this issue (by delaying their awareness of the problem and the need for their intervention)? :Or does it step on the infected process too hard for that to work? : :Even if people don't want to run it on the open internet, :due to concerns about appropriateness of reverse hacking, :it might be useful for inside-the-firewall cleanup :for corporations that get hit. Might be. Let those inside worry about that (imho). -brian
On this topic... I've noticed that my packet counters stopped going from >1000/sec to under 100/sec. Anyone else confirm the same? Has someone went and hacked the 5000 or so remaining infected hosts that were hackable somehow, and patched/rebooted? --Phil
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.
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.
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
| 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
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
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 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com 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 <blacklist@brics.com>, or you are likely to be blocked.
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
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 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com 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 <blacklist@brics.com>, or you are likely to be blocked.
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 +0000 (GMT) From: A Trap <blacklist@brics.com> To: blacklist@brics.com 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 <blacklist@brics.com>, or you are likely to be blocked.
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
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 ... -r This 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
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
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. -- Barney Wolff http://www.databus.com/bwresume.pdf I'm available by contract or FT, in the NYC metro area or via the 'Net.
participants (13)
-
alex＠yuriev.com -
Barney Wolff -
Brian Wallingford -
Darren Pilgrim -
David Charlap -
E.B. Dreger -
Jack Bates -
Joe Abley -
Phil Rosenthal -
Rubens Kuhl Jr. -
Sean Donelan -
Stewart, William C (Bill), SALES -
Valdis.Kletnieks＠vt.edu