News archive December 2002 - Koos van den Hout

Archive by year: 1999 | 2000 | 2001 | 2002 | 2003 | 2004 | 2005 | 2006 | 2007 | 2008 | 2009 | 2010 | 2011 | 2012 | 2013 | 2014 | 2015 | 2016 | 2017 | 2018 | 2019 | 2020

2002-12-29 Port 137 keeps going 17 years ago

Lately the log of my Linux firewall has become unreadable due to the high
amount of port 137/udp traffic. Traffic rose over 1 packet/minute which is
(was?) somewhat unusual in my 'part of the woods' (an IP block dedicated to
DSL customers of an ISP).

There is only so much room in the kernel message buffer, room which I like
to keep for serious system troubles such as failing disks. At certain times,
the *only* thing in the message buffer was dropped port 137/udp traffic.

So I started asking around.. only to find that more places are seeing the
same rise in traffic, but no real reason why, nor any news reports on the
reasons of increased traffic.

Several reasons exist. Some 'scanners' use this kind of request to find
open machines. Some viruses use this to spread themselves.

An earlier rise has been seen in April/May 2000.
Sans describes this in an article Port 137 scan. They give scanning
activity and a virus named network.vbs as probable reasons for this
traffic.

I captured some of the traffic using tcpdump, giving:

22:03:17.964361 cable.ip.1025 > my.dsl.ip.137: [udp sum ok]
>>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
TrnID=0x100
OpCode=0
NmFlags=0x1
Rcode=0
QueryCount=1
AnswerCount=0
AuthorityCount=0
AddressRecCount=0
QuestionRecords:
Name=* NameType=0x00 (Workstation)
QuestionType=0x21
QuestionClass=0x1

(ttl 111, id 62037, len 78)

Compared, doing an 'nmblookup -A' gives in traffic:

22:00:07.416647 unix.machine.34098 > my.dsl.ip.137: [udp sum ok]
>>> NBT UDP PACKET(137): QUERY; REQUEST; UNICAST
TrnID=0x5EC7
OpCode=0
NmFlags=0x0
Rcode=0
QueryCount=1
AnswerCount=0
AuthorityCount=0
AddressRecCount=0
QuestionRecords:
Name=* NameType=0x00 (Workstation)
QuestionType=0x21
QuestionClass=0x1

(DF) (ttl 245, id 29589, len 78)

Which only sees the differences that the unix nmblookup approach
sets a df bit, and that nmblookup is better at the Transaction ID
(TrnID).


Tags: ,
2002-12-13 reply to ISPs and filesharing contents 17 years ago
I mailed the same as I wrote in my previous piece on
ISPs and filesharing contents in a mail to the Sans editor.

After more then a week, I got a reply, which was in its entirety:


It really all boils down to whether organizations and individuals take
copyrights seriously. It appears that you do not. I do....


I would have expected a better thought-out reply from someone who gets to
write in the role of Sans newsletter editor.


Tags: ,
2002-12-09 (#) 17 years ago
HP printers with 'Internet ready' overdo the 'Internet ready' bit since anyone with port 80 access to the printer can change the configuration, even when an access-list has been set using the jetdirect config file. Set an administrator password and firewall the printer.

Tags: , ,
2002-12-07 (#) 17 years ago
I have a public webcam running again giving you the view outside my living room window. Need to fix the problem with light in the evening .. good optical cardboard is hard to find (optical cardboard is very very black).

Tags: ,
2002-12-04 ISPs and filesharing contents 17 years ago
Reply to SANS NewsBites Vol. 4 Num. 49 article/editorial comment

Quoting The SANS Institute who wrote on Wed, Dec 04, 2002 at 08:25:37AM -0700:

> --26 November 2002 ISPs May Limit Bandwidth Consumption
> Some high speed ISPs are considering placing limits on the amount of
> bandwidth their customers may consume each month. If they decide
> to do it, it could significantly curtail file-swapping activity,
> which makes up a large portion of network traffic.
> http://news.com.com/2100-1023-975320.html

> [Editor's Note (Schultz): Peer-to-peer file sharing not only consumes
> a great amount of network bandwidth, but it also often involves
> illegal downloading of copyrighted materials. One would think that
> ISPs would realize this and take measures to preclude such activity.

In my opinion, an ISP should not police the *content* of what you do with
your Internet connection. Who is the ISP to decide that any connection
made by the user is bad.

File sharing as-is does not damage the Internet. Part (yes, a large part)
of what offers is not legal to share. According to normal laws for the
countries the ISP clients are in. Those laws should apply. If a district
attorney or a judge orders a user disconnected for law-breaking, the ISP
should disconnect that user. The ISP should not police the content of what
their user does by itself. The user can then apply to this decision
through the normal ways of justice.

Your comment seems to suggest thinking along the lines (like the RIAA)
'since filesharing can and is abused for transferring content which has
copyrights applied, all filesharing must be forbidden'. This is the same
line of thinking as the RIAA showed in sueing mp3.com for making the mp3
format popular which can be used for transferring contents of CD's while
mp3.com only offers mp3 format files for which no copyright violations
occur by downloading them.

You might bring up open smtp relays here. These damage the structures
the Internet is build on.

Technical reasons are a reason to not allow certain types of traffic (such
as traffic seeming to originate from a different IP then your own). But an
ISP should be open and clear about what they filter and why. A change in
filtering should be seen as a change in the offered amount of "Internet"
so it is a change in contract between ISP and user.

Bytes transferred through an ISP are a finite resource. With a price.
Paying for overusage of this resource is reasonable to me, if the ISP
is clear enough on what they consider 'enough' and 'too many' bytes
transferred. A counter can be applied both by the customer and ISP to
see when the user is over his limits. This puts the choice how important
each of those bytes is to the user at the user who is responsible.

The original article has the order of things right. If people find they
have to be careful with their bandwidth usage, they should use it wisely.
Yes, this might make sharing files a lot less interesting, unless you
have something you really want to spread.

> Where I work someone has developed "KO," the "KaZaA Obliterator,"
> which detects and kills sessions involving use of KaZaA and other
> peer-to-peer file sharing programs altogether.

Work is a different place. At work, management can set rules on what can > (Shpantzer): One company working on the P2P bandwidth issue
> claims that these applications hog as much as 60% of bandwidth
> on the internet. Also see the link for a University of Chicago
> study of the Gnutella P2P network effects on bandwidth patterns.]
> http://www.theregister.co.uk/content/22/27092.html]

Koos van den Hout
(speaking for himself)


Tags: ,


, reachable as koos+website@idefix.net. PGP encrypted e-mail preferred.

PGP key 5BA9 368B E6F3 34E4 local copy PGP key 5BA9 368B E6F3 34E4 via keyservers pgp key statistics for 0x5BA9368BE6F334E4 Koos van den Hout
RSS
Other webprojects: Camp Wireless, wireless Internet access at campsites, The Virtual Bookcase, book reviews
This page generated by $Id: morenews.cgi,v 1.46 2019/10/20 15:42:02 koos Exp $ in 0.013282 seconds.