Re: Merged - Port blocking
 

I would just like to point out something in that 'FAQ'
that is complete ********, they can write OTHER viruses that exploit DIFFERENT vulnerabilities, but blaster and welchia use an RPC/DCOM exploit, and that service listens on port 135 period.
You cannot connect to it on a different port any more than you can tell a web server you want to connect to it on port 3987 rather than port 80 ( of course the owner of the machine can change the port the webserver listens on, but that is different)

Re: Merged - Port blocking
 

not really! the welchia virus was a blended threat and was active on other ports not just 135

Re: Merged - Port blocking
 

Thanks

We are looking into it

Re: Merged - Port blocking
 

it was ACTIVE on other portsd ( it uses udp port 69, tftp, to retrieve its download, but it MUST make contact on port 135 in order to infect a machine, it relies on a vulnerability within the RPC service in windows that allows arbitrary code execution, without that, it cant do anything.
Other viruses do use other vulnerabilities in other services ( 137 for example is one of the filesharing ports, which also has similar vulnerabilities ) but they are not variants of blaster, they are different viruses, ok, I maybe splitting hairs, but claiming that blaster can spread using different ports is just wrong.

Re: Merged - Port blocking
 

ok agreed. pointless splitting hairs over it. there's not likely to be too many new variants of blaster or welchia in the future and although it is possible for future variants to spread by other means, this is unlikely.

Re: Merged - Port blocking
 

There is no filesharing on port 137 - it is the NETBIOS Naming Service.

Re: Merged - Port blocking
 

Lests be honest guys. !!!

Does anyone on the net actualy need to use netbios and file/print sharing. Its so insecure that I would not dream of letting it out of my lan.

If people unbound this pointless protocols from there network or usb adaptors we would have less of these types of viruses going around.

Incidently - I am still getting a huge ammount of hits on 137 as well as spoofed 127.0.0.1 port 80 scans.

Isn't the world wide wait fantastic !!!

Re: Merged - Port blocking
 

Yes.

Re: Merged - Port blocking
 

Who....

I have never met anyone who uses it. Its not secure - its unstable and it was written for use on a lan - not the internet !!!!!!

Re: Merged - Port blocking
 

Well I thought that the reply implied who (i.e. me). :)

Define "not secure" and "unstable" - and who says it was written for use on a Lan ? (and the "internet" is basically just a big Lan anyway)

JFYI - it is perfectly secure enough for my use of it and I have never had a file transfer fail.

Re: Are Isp's Right To Block Mail From Dynamic IP's ??
 

Hi m8

The trouble is that even if you go with a static ip with someone like pipex they dont offer reverse dns. All these Isp's are simply performing a reverse lookup and rejecting the mail.

On the subject of using a third party mail server I need to know that there mail server is secure and supports encrypted mail passthrough. Not many do !!!

I know that the ip can and does change, I was simply trying to speak for caring genuine users and small business's that have this as there only option.

Cheers m8 and have a great crimbo !!!

Re: Merged - Port blocking
 

Hi pem.

It was written for use in a internal network only. Have a look at the RFC for netbios and file & printer sharing. This is why any routers in an autonamous network will stop these protocols travaling outside the network unless it is programed otherwise.

I know the guy has a bit of a big head but Gibson of www.grc.com has done a great deal of research on netbios. There is also a good paper on the subject at http://www.petri.co.il/what_is_port_445_in_w2kxp.htm

Looks like we may have to agree to disagree on this one :) :) :)

Re: Merged - Port blocking
 

Indeed we will - but thanks for the links - I will have a look at them over xmas. :D

Re: Merged - Port blocking
 

Have a good christmas - and dont get too drunk :beer:

Re: Merged - Port blocking
 

pem & stuartbe:

You are arguing over different things, and you're both right in your separate ways.

In the beginning, there was only NetBIOS, and it was both (a) a LAN-only protocol, and (b) an API specification for networking, that applications and services could write to. The low-level protocol was layered on 802.2.

IBM and Microsoft developed the SMB protocol for file and print sharing, and layered it on top of NetBIOS.

As networking developed, the protocol and the API were split apart. The low-level protocol became known as NetBEUI, while the high-level API remained called NetBIOS.

NetBEUI was and is a LAN-only protocol, which relies on system-wide broadcasts for locating other nodes, and cannot be routed.

NetBIOS was then ported onto several other transport protocols besides NetBEUI. One of those was IPX/SPX in Netware environments. Another was TCP/IP. The NetBIOS port onto TCP/IP uses the well-known ports 135-139. This enables applications written to the NetBIOS API to communicate over any of the underlying transport protocols (NetBEUI, IPX/SPX, TCP/IP) without being aware of which protocol they are using.

Because Microsoft/IBM file and print shaing used SMB (now also known as CIFS), which was layered on top of NetBIOS, this meant that file and print sharing could occur over any of the underlying low-level protocols: all of them were supporting SMB via NetBIOS.

There is no reason why the Filesharing-SMB-NetBIOS-TCP/IP stack cannot be routed over the internet and support long-distance file and print sharing. By default all IP routers support this because the traffic is indistinguishable from all other IP traffic, apart from port numbers. The downside to this is that it exposes the entire NetBIOS interface of each PC to the internet, and the NetBIOS API had no security model.

With Win2K and XP, Microsoft ported the SMB/CIFS filesharing protocol (which does have an inbuilt security model) to a direct TCP/IP transport on port 445, eliminating the NetBIOS layer. For backward compatability with Win9x systems, they left the NetBIOS transport still enabled by default. The port 445 implementation is perfectly capable of long-haul connections over the internet.

So now, 2K and XP users can do filesharing by any of the following stacks:

SMB -> TCP/IP port 445 -> LAN & internet
SMB -> NetBIOS -> TCP/IP ports 135-139 -> LAN & internet
SMB -> NetBIOS -> IPX/SPX -> LAN only
SMB -> NetBIOS -> NetBEUI -> LAN only

NTL, and many other ISPs, have now blocked both 135-138 and 445, thus making MS filesharing impossible over the broadband connection. If you need to do MS-style filesharing over the internet, you should set up VPN servers/clients and use PPTP or L2TP as the transport over the broadband connection, which imposes another layer of security and authentication over these links.