Merged - Port blocking

[Dooby]

I would just like to point out something in that 'FAQ'

The Welchia and Blaster worms spread over port 135, which has already been blocked, but virus writers can make variants of these that spread over other ports, and so ntl are blocking these to reduce the potential danger to our customers

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)

[threadbare]

Originally Posted by Dooby

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)

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

[utt]

Originally Posted by iadom

For attention of utt.


Here is the screen grab you requested from first bootup this morning. Still flooding in, over 400 today up to now.

Jim.

Thanks

We are looking into it

[Dooby]

Originally Posted by threadbare

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

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.

[threadbare]

Originally Posted by Dooby

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.

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.

Originally Posted by Dooby

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.

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

[Stuartbe]

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

Originally Posted by stuartbe

Does anyone on the net actualy need to use netbios and file/print sharing.

Yes.

[Stuartbe]

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

Originally Posted by stuartbe

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

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.

[Stuartbe]

Originally Posted by cliveb

There is a very good reason why mail sent direct from a dynamic IP can't be trusted. Although at the moment, that dynamic IP happens to belong to you, and you can be trusted, tomorrow that IP might be handed out to someone else who is running an open relay. (I know IP addresses in NTL tend to stick around, but they *can* change - mine did a couple of weeks ago after a hardware "upgrade" at NTL's end).

I agree with you that NTL's SMTP servers can't be trusted (nor can their POP3 servers for that matter), so the only real solution is to buy email services from a reliable third party. I happen to use UK Web Solutions Direct, who have been very reliable (20 quid a year for POP3, SMTP, webmail, and 100MB of web space), but I'm sure there are plenty of other suitable providers.

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

[Stuartbe]

Originally Posted by pem

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.

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

Originally Posted by stuartbe

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

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

[Stuartbe]

Originally Posted by pem

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

Have a good christmas - and dont get too drunk

[rdhw]

Originally Posted by stuartbe

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.

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.