Anybody doing a "Code Green" for 1434?

Mailman List Mirror (Read Only)
1

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

2

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.

3

:
: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

4

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

5

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.

6

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.

7

Date: Mon, 27 Jan 2003 03:19:33 -0500 (EST)
From: Sean Donelan

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.

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

8

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
:slight_smile: 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

9

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
:slight_smile: 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

10

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

11

> 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

12

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

13

Date: Mon, 27 Jan 2003 14:16:40 -0500 (EST)
From: alex@... (Alex Yuriev)

[I]t 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.

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

14

> [I]t 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.

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

15

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

16

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

17

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

18

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.