Newsgroup: it.comp.reti.ip-admin
Titolo: 137/udp

Ho l'abitudine di filtrare il range 137-139 sia udp che tcp. Ultimamente
pero', i
log del packet filter solo sommersi di pacchetti filtrati diretti alla
137/udp, che provengono dai posti piu' disparati, di solito pochi pacchetti
prvenienti pero' da molti host.
Che cosa e? 
saluti
Lele

le...@windmill.ibn.it
 wrote:
 >log del packet filter solo sommersi di pacchetti filtrati diretti alla
 >137/udp, che provengono dai posti piu' disparati, di solito pochi pacchetti
 >prvenienti pero' da molti host.
 >Che cosa e? 
Spoofing. Con la collaborazione di chi ti fornisce la banda cerca di
inchiodarli.
-- 
ciao,			[To reply remove "+nospam" from my address.        ]
Marco			[Per rispondere togli "+nospam" dal mio indirizzo. ]
             * The Internet is not for sissies.  -- Paul Vixie *

...


 Che cosa e? 
Se la domanda si riferisce a  quali servizi ci  sono sulle porte 137/139, si
tratta si SMB (ossia la famiglia dei protocolli  di LAN Manager, LAN Server,
WfWG, ecc.).  
Se invece   ti domandi *perche'*    ti arrivano tutti questi   tentativi  di
connessione...  be', i casi  piu` probabili sono due:  macchine WfWG o Win95
configurate male  e con  router  di  mezzo altrettanto mal   configurati, se
lasciano passare dei broadcast; se invece le connessioni sono punto a punto,
allora la cosa  e` intenzionale: qualcuno sta usando  molte  macchine (o una
sola,  magari con  tanti abbonamenti di    prova, ecc.) per trovare  qualche
server NT  da inchiodare o penetrare usando  i  bug ormai ben  noti scoperti
negli ultimi mesi, nella speranza di  trovare qualche server ancora privo di
patch.
Se vuoi, puoi provare a risalire ai "proprietari" degli indirizzi e scrivere
ai  loro amministratori e chiedere  ulteriori indagini: se non hanno tentato
un IP spoofing (cosa non banale, e che sarebbe in contrasto con la banalita`
e la "rozzezza" dell'attacco  via SMB), dai loro log  si potrebbe risalire a
chi era collegato e da dove, ecc. ecc. 
Saluti,
Luca Polo.
-- 
 / Luca Polo : 
Luca...@gest.unipd.it
 || System administrator          \
| (
http://www.gest.unipd.it/~jake
 for  || Ist. di Ingegneria Gestionale  |
 \ address and phone numbers)          || Universita` di Padova, Italy  /


To: 
NTBU...@RC.ON.CA
Subject: NT DNS Implicit Search Order Hole
Morning all,
Here is one to be wary of:
        NT 4.0 implements an implicit DNS search order.
Seems like a simple, harmless statement, but actually it creates
two major security holes...
1. Background
Old (deprecated) DNS client behaviour was to implement an implicit search
path for domain name lookups.
Basically, it will implicitly escalate an unsuccessful DNS request for
HOST.WG.SUB.DOMAIN.COM.AU
 to 
HOST.SUB.DOMAIN.COM.AU
 then
HOST.DOMAIN.COM.AU
 then 
HOST.COM.AU
 and, maybe even, HOST.AU before
returning an error.
As you can see, this can lead to a name being resolved against entirely
the wrong host, and one which is in another company or even country.
This is deprecated behaviour, and should be disabled, or at least have a
registry setting which does disable it. For more on search paths, see the
O'Reilly DNS book, pp. 95 (2nd Ed).
Of course, being deprecated behaviour, that means NT implements it.
[Why, oh why, can't they learn from the world around them. :-( ]
The problem is made more subtle (hidden) by Microsoft - a blank "search
order" in the DNS config screens would imply no search order, rather than
'use an undocumented deprecated one'.
2. The Problems
Problem #A:
 If a site is not using WINS, but incorrectly sets the "Enable DNS for
 Windows" option. Configuring a machine HOSTA in in a workgroup WG and a
 DNS domain 
DOMAIN.COM.AU
 will result in netbios attempting to exchange
 browser lists (or similar - I am not sure exactly what it is doing) with
 
HOSTA.WG.DOMAIN.COM.AU
 and, failing that, with 
HOSTA.DOMAIN.COM.AU
,
 
HOSTA.COM.AU
, etc.
Problem #B:
 If a site does use WINS, but a machine is turned off (e.g. for the
 weekend) or crashes, then the client will escalate the query as
 previously described.
 This version of the problem is far more insideous. A site with good NT
 expertise, who has done everything right, is still susceptible should
 a box crash (or the network to it).
3. The Security Holes
In both cases, the potential to exchange classified information exists,
and most definitely a storm of NETBIOS traffic every 13 minutes results. I
am receiving just such a storm as I write this. :-(
This means that by turning a machine off (or it BSODing) my private
internal company traffic is suddenly heading out over the Internet!  No
authorisation, no logging, silently. The only way to stop it is with a
firewall (filtering router), which is also the only way to detect it.
Someone less scrupulous could easily craft a fake NETBIOS server to
exchange false lists and extract this information. As Jason suggested when
I posted this to the SAGE-AU list, it would be interesting if someone went
out and registered "
workgroup.com.au
" or similar. They could just sit back
and collect privileged information.
As a lesser hole, the amount of erroneous traffic that NT 4 machines are
generating across the Internet is massive - every 13 minutes, most of it
entirely undetected, and dropped because the (non NT) machine at the other
end isn't listening to that port. Maybe we should sent MS our traffic
bills? :-)
4. The Symptoms
The problem relates to name resolution, and the effect is a whole lot of
unauthorised NETBIOS traffic to your site from random sites across the
world.  (Actual symptom: attempts from foreign site to connect to port
UDP/137 [netbios-ns] on one of your (probably not even NT) hosts.)
The upshot of this is that sites all across the Internet are being blasted
with NETBIOS packets every thirteen minutes because their registered
domain name happens to coincide with a mis-formation of a random NT
workgroup name.
As the registered owner of '
sysadmin.com.au
' and '
is.com.au
', I get more
of these because 'sysadmin' and 'is' are common host and workgroup names.
I suspect that the implementation of the search path means that non-US
sites (with a top level domain other than .com etc) are more likely to
see this bug (the top level domain side-steps the built in limit in the
implied search path).
5. The Workaround
Many organisations do not use WINS, and certainly don't use WINS through
DNS. So it is important to make sure that the "Enable DNS for Windows"
option (very badly named) on the WINS configuration screen is disabled.
This stops problem A dead.
I do not know of a workaround to problem B other than the correct
solution.
6. The Solution
The solution is simple; either (a) remove this deprecated functionality,
or (b) create a registry setting to disable it (which should default to
disabled).
Warm regards to all,
Geoff
----------------------------------------------------------------------------
Geoff Halprin                                 
Geoff....@sysadmin.com.au
Managing Director                                     Phone:
+61-3-9686-3233
The SysAdmin Group Pty Ltd                            Fax:  
+61-3-9686-3399
238 Richardson Street, Middle Park, VIC 3206          Pager:   
03-9483-0355
PGP Fingerprint: (FE349AAD) 05 93 68 35 B2 09 8E 6F  79 8C 16 F8 8F BC 2E
CB
----------------------------------------------------------------------------