Anyone seeing any port 80 issues tonight? We're having some issues with our
port 80 off-net traffic tonight.
Do you think you could be a little more vague?
no port 80 issues (other than Code Red on the initial ramp up as
always this time of the month).
However, 445 is taking off. The new 'deloader' virus is taking off quick.
It is installing VNC on infected machine ...
Are other people having problems with this right now?
There doesn't seem to be very much traffic or information about this on any of
the security lists (it is Sunday...).
The last posted URL points to an impending storm...
Other operators opinions about blocking port 445 before this thing starts
spreading faster than it already is?
Are other people having problems with this right now?
There doesn't seem to be very much traffic or information about this on any of
the security lists (it is Sunday...).
The last posted URL points to an impending storm...Other operators opinions about blocking port 445 before this thing starts
spreading faster than it already is?
IMHO, this is similar in impact to Opaserv. As an ISP, I would probably block
445 just to avoid having lots of people call Monday morning complaining about
slow connections after they got infected. This worm is unlikely to cause
major 'global' network slowdowns, so filtering further upstream probably makes
not too much sense.
The main 'facts' so far:
- this virus does attempt to exploit weak passwords, not just open / no password
shares
- there are some reports that this worm has a VNC or IRC backdoor component,
which opens the infected machines to future exploits.
- port 445 has gotten a lot of attention from the malware community recently.
So there are likely further exploits in the works.
Other operators opinions about blocking port 445 before this thing starts
spreading faster than it already is?
We are an ISP, and we just decided to.
Extended IP access list 199 (Compiled)
deny tcp any any eq 445 (66574 matches)
Last configuration change at 14:49:44 MST Sun Mar 9 2003
It is 15:35 now. ~ 1305 packets/min. Since we leave ports 135-139 open, the
effects
"should" be none on the users by blocking 445.
Here is part of a conversation Jake Bates and I have been having:
<James responds>
You read my mind, this was the very issue running around my mind ! I am a
router admin for the ISP cybermesa.com
and I was trying to sort out this question so I could consider asking to
block this port.
What I know is the port 445 is a port XP and 2000 can run SMB on, much like
what happens on 135-139 (Netbios, Client for MS networks, Print and File
Sharing).
So if the users use these services (on port 445) across the
internet, blocking
will effect them. My experience is that if the users do SMB, they do it on
135-139. So, my working theory
is that blocking 445 will have no effect on them. If you block 135-139
already as part of policy (i.e., no Netbios),
blocking 445 would also be part of the policy. Only XP and 2000 use 445, but
can use 135-139; whichever
is open. Cyber Mesa does not block 135-139 as legacy MS Messenger used those
ports and it causes
a "big deal" if they are blocked. So in my case I am really leaning to block
port 445.
Do you block ports 135-139 and what effect did it have on the users ?
<Jack answers>
I'm with you, though. Blocking 445 may work well with 135-139 still open.
I'll presume that XP/2000 tries 445 and upon a set timeout reverts to the
older method.-Jack
<James answers>
Yep. I think actually 135.-139 is the default and it falls back to 445.
http://www.microsoft.com/windows2000/techinfo/reskit/en-us/default.asp?url=/
windows2000/techinfo/reskit/en-us/cnet/cnbc_imp_wcug.asp
In Windows 2000, it is also possible to use direct hosting to establish
redirector or server connections between Windows 2000 computers without the
use of NetBIOS. By default, Windows 2000 attempts to make connections using
both methods so that it can support connections to older versions of Windows
computers. However, in Windows 2000-only environments, you can disable
NetBIOS over TCP/IP as described in the "NetBIOS Over TCP/IP Sessions"
following in this chapter.
James Edwards
jamesh@cybermesa.com
Routing and Security Administrator
Blocking ports in the core doesn't stop stuff from spreading. There are
too many alternate paths in the core for systems to get infected through.
In reality, backbones dropped 1434 packets as a traffic management practice
(excessive traffic), not as a security management practice (protecting
users).
So far the Deloder worm appears to be responding to normal congestion
feedback controls, limiting its network impact. Like CodeRed, Nimda, etc
some edge providers may need to implement network controls due to
scanning activities causing cache busting, but I suspect most network
backbones will not need to do anything.
So far the Deloder worm appears to be responding to normal congestion
feedback controls, limiting its network impact. Like CodeRed, Nimda, etc
some edge providers may need to implement network controls due to
scanning activities causing cache busting, but I suspect most network
backbones will not need to do anything.
I agree. It will mostly be useful at edge networks to spot outbound traffic
of possibly infected users. 445 should normally be very light, and I suspect
that 99% of the systems issuing the traffic will be found to be infected
with at least one worm or virus, and probably have more security issues. My
last 445 spewing customer had 3 back door programs, 5 viruses, and 2 worms.
It was, of course, a school computer.
The problem with blocking is if you decide to remove the blocks. Upon
removal of 1434 from my EBGP routers, I immediately saw 3 systems infected
and start spewing. One of them, scarily, was a dialup while another was on a
transit customers network and, of course, shut him down. If we protect the
customer, the customer won't fix the problem. Blocks always have to be used
with caution because of this.
-Jack
So far the Deloder worm appears to be responding to normal congestion
feedback controls, limiting its network impact. Like CodeRed, Nimda, etc
some edge providers may need to implement network controls due to
scanning activities causing cache busting, but I suspect most network
backbones will not need to do anything.
I agree this is not a backbone issue. Since we are an ISP and at the edge,
it is a good place to drop this. Traffic is not as large, as of yet, as the
SQL worm.
Blocking port 445, for us, means far less $$ in support time to deal with
abuse reports
and infected users.
I'm just waiting for hakerz to finally figure out that having the port
number a hash of host address will effectively make port-based
"notch" filtering useless. Usin