Newsgroup: it.comp.sicurezza.varie
Titolo: Scanning in locale

Salve,
oggi notavo su una macchina Windows 2003 Server una cosa alquanto 
strana: centinaia di connessioni loopback in TIME_WAIT dalla 1433 
a porte in sequenza dalla 2000 alla 4000 circa. Tcpview mi da questo:
....
[System Process]:0  TCP	 
127.0.0.1:2307
 
127.0.0.1:1433
	 TIME_WAIT
....
e se non erro questo processo dovrebbe essere associato all'Idle 
Process di Windows... solo che a questo punto non capisco il nesso :)
Per quanto puo' servire una passata con un antivirus non ha rilevato 
nulla.
Pareri?

 Process di Windows... solo che a questo punto non capisco il nesso :)
1433 non era la port predefinita di sql server?
-- 
ciao, hal

 1433 non era la port predefinita di sql server?
Si, e detto server è anche installato sulla macchina.
Peroo' lo scanning in questo caso non è diretto alla 1433 ma *dalla* 
porta in oggetto, e comunque anche fermando i servizi SQL la situazione 
non cambia.

 Si, qualche ragazzino idiota avraà voluto provare l'exploit del giorno..
Ribadisco che la 1433 non è la porta target e tu tutto avviene comunque 
in locale, difficile sia un tentativo di exploit...

 Si, qualche ragazzino idiota avraà voluto provare l'exploit del giorno..
Su localhost?
-- 
Chaos A.D.		|	Raging crowd
Tanks on the streets	|	Burning cars
Confronting police	|	Bloodshed starts
Bleeding the Plebs	|	Who'll be alive?

 Ribadisco che la 1433 non è la porta target
Guarda meglio.


 giorno.. 
o è infetto? (Slammer gira ancora parecchio..)
-- 
PELLICCE: 
http://www.strasbourgcurieux.com/fourrure/spanish.php
DOG CONNECTION: 
http://www.randagismo.info/traffici/
Contro i TRAFFICI di animali: 
http://www.bairo.info/traffici.html
LABORATORI CRIMINALI: 
http://www.laboratoricriminali.cjb.net/
------------------------------------------------------------------
* X-Privat NNTP and MAIL services: 
http://www.x-privat.org
 *


non mi preoccuperei piu' di tanto( o quasi), tanti utilizzano 
l'interfaccia di loopback per le connessioni SQL(ovviamente in locale) , 
probabilmente l'applicativo che usi chima SQL server in locale...
bye
peppe

 Guarda meglio.
netstat -na
[..cut..]
 TCP    
127.0.0.1:3908
 
127.0.0.1:1433
         TIME_WAIT
 TCP    
127.0.0.1:3909
 
127.0.0.1:1433
         TIME_WAIT
 TCP    
127.0.0.1:3910
 
127.0.0.1:1433
         TIME_WAIT
 TCP    
127.0.0.1:3911
 
127.0.0.1:1433
         TIME_WAIT
 TCP    
127.0.0.1:3912
 
127.0.0.1:1433
         TIME_WAIT
 TCP    
127.0.0.1:3913
 
127.0.0.1:1433
         TIME_WAIT
 TCP    
127.0.0.1:3914
 
127.0.0.1:1433
         TIME_WAIT
 TCP    
127.0.0.1:3915
 
127.0.0.1:1433
         TIME_WAIT
 TCP    
127.0.0.1:3916
 
127.0.0.1:1433
         TIME_WAIT
 TCP    
127.0.0.1:3917
 
127.0.0.1:1433
         TIME_WAIT
 TCP    
127.0.0.1:3918
 
127.0.0.1:1433
         TIME_WAIT
[..cut..]
mi sfugge qualcosa?

 Process di Windows... solo che a questo punto non capisco il nesso :)
Una connessione in TIME_WAIT non appartiene a nessun processo e windows,
per convenzione, gli assegna quel pid.
 
Ah... slammer lavora su UDP (1434/udp).
Fabio


Ok stavo dormendo ieri notte e stamattina le cose non sono cambiate di 
molto evidentemente :) Il tentativo di connessione è *verso* la 1433, 
forse bloccato in continuazione da una regola di routing 
impostata sul server, anche se la cosa mi sembra strana visto che 
l'SQL gira tranquillamente. Mo' controllo...

 mi sfugge qualcosa?
Si: il significato dello stato TIME_WAIT...

 per convenzione, gli assegna quel pid.
Non sapevo, grazie mille per l'info.
A questo punto: qualche consiglio per individuare il processo padre?

 Ah... slammer lavora su UDP (1434/udp).
ah già, vero! :-|


 Si: il significato dello stato TIME_WAIT...
Ti ringrazio per la "pungolata", penso di aver trovato il bandolo della 
matassa.

 trovato il bandolo della matassa.
Ad occhio e croce potrebbe essere un'applicazione
che "gira" sul server stesso e che usa SQLserver
(es. per il logging); basterebbe aprire la management
console di SQLserver e controllare le connessioni e le
relative credenziali per riuscire a ... capire qualcosina
in più ;-)
Ciao
-- 
* ObiWan
Microsoft MVP: Windows Server - Networking
http://www.microsoft.com/communities/MVP/MVP.mspx
http://italy.mvps.org
DNS "fail-safe" for Windows clients.
http://www.ntcanuck.com
Newsgroups and forums
news://
news.ntcanuck.com
http://forums.ntcanuck.com
408+ XP/2000 tweaks and tips
http://www.ntcanuck.com/tq/Tip_Quarry.htm

 In stato TIME_WAIT? Dubito.
Che ha di strano lo stato TIME_WAIT?!?
Il socket è chiuso e viene portato in TIME_WAIT per un TOT prima di 
poter riutilizzare la stessa porta...
/me perplesso

 client sulla stessa macchina, ma non credo proprio sia questo il caso.
Dipende tutto da come è pensata la macchina...
Se hai (esempio) un webserver contenente delle pagine dinamiche che 
interrogano il DB in locale (tramite TCP), non ci vedo nulla di strano...
10 connect separate, 10 socket, 10 TIME_WAIT...

 non ci vedo nulla di strano...
Esattamente lo stesso mio sospetto, se sulla macchina
sta girando un webserver che utilizza il database per un
qualsiasi motivo, è possibile che vengano effettuate delle
connessioni al DB per richiedere i dati usando l'indirizzo
di loopback e che queste connessioni vengano chiuse
subito dopo, questo spiegherebbe sia il numero di connex
sia il discorso loopback; quello che mi suona strano però
è il il fatto che le connex sembrino appartenere a "system"
secondo me l'ideale sarebbe utilizzare la console di SQL
per controllare le connessioni in corso e vedere cosa in
effetti stia accadendo sul server (richieste, accounts, ecc)
Ciao

 č il il fatto che le connex sembrino appartenere a "system"
Posto che io Win32 non lo conosco affatto, le connessioni in stato 
TIME_WAIT vengono mantenute lě dallo stack (quindi dal kernel), e non 
dal processo che ha richiamato la connect(): nulla di strano che 
l'utenza su cui risultano mappate non sia quella dell'utilizzatore 
"reale", quindi...

 "reale", quindi...
Si, esatto, il client di SQLserver si connette al DB sulla 1433/tcp
fa "quello che deve" poi chiude la connessione, a questo punto
lo stack winsock tiene la connex in TIME_WAIT per un certo tempo
prima di rilasciarla e permettere il riutilizzo della porta (dinamica)
Ciao

> A questo punto: qualche consiglio per individuare il processo padre?
Se hai un'interfaccia grafica di management vai a vedere il numero di 
processi attivi. Se hai solo un'interfaccia sql (osql) puoi usare una
cosa tipo select * from sysprocesses. Ma ci vedrai solo i... processi
attivi, per l'appunto. 
Se in quel momento 'un c'e' nulla che lavora, e/o se quei socket sono
aperti da qualche processo che non stabilisce una connessione con sql
server (ad esempio: sistema di monitoraggio che verifica che la porta
tcp sia in ascolto) puoi usare tdimon, lasciandolo li' in ascolto per
un po' finche' non trovi traccia di quello che cerchi.
Fabio

 prima di rilasciarla e permettere il riutilizzo della porta (dinamica)>
Esatto ragazzi, la situazione alla fine è proprio questa (webserver che 
intepella l'sql in loopback). La fretta e il sonno mi avevano fatto 
supporre l'ordine inverso delle connessioni, complice anche il fatto che
le porte del client sono aperte in sequenza, e quindi un possibile
scanning.
Tutto ok, grazie mille per il supporto.
ciao,
d. 

 una istanza
Un application server che si connette su localhost ad un db è cosa
piuttosto diffusa...
