Newsgroup: it.comp.sicurezza.varie
Titolo: nuked!!

 
Chiedo ulteriori conferme al ng,ma mi pare di capire che hai il trojan
NetBus attivo.Oppure era solo un tentativo da parte del tipo?
Controlla...procurati il client Netbus e tenta di fare una connessione a
localhost.Oppure procurati AVP e fai uno scan dell'hd.
Altra possibilità: da finestra dos digita netstat -na 30 (oppure
40...50..è l'intervallo di refresh).Se durante i collegamenti ad
internet trovi connessioni attive alle porte 12345 e 12346 allora è
NetBus.
			Giulio
 
-- 
"Don't be surprised,when a crack in the ice
Appears under your feet
You slip out of your depth and out of your mind 
With your fear,flowing out behind you
As you claw the thin ice"

Che significa??
significa che uno ha controllato se avevi il netbus installato.
Il tipo, tra l'altro, non e' neanche pirla: Password;1;any
Buttha (che si gloria delle poche cose che ha imparato)
-----------------------------------------------------------------------
* HO CAMBIATO INDIRIZZO
* Per rispondere rimuovere i
* PGP Key available with fingerprint:
  7772 5C72 7392 538B  34B8 A189 13BC 867A

  mailto:
m...@iol.it
IRC: Mauri_X on IRCnet
PGP key av. on servers: DH/DSS ID=0x46C0C5BD
(*)(*)(*)(*)(*)(*)

(*)(*)(*)(*)(*)(*)


la connessione........
quella porta non la chiude.
Anch'io con Nukenabber ho selezionato l'opzione di chiudere la porta,
ma quando mi capita qualcuno in cerca di netbus, nukenabber non chiude
la porta.
Buttha


NetBus.
il netstat deve lanciarlo *dopo* aver chiuso Nukenabber, altrimenti
prende molta paura.


la porta.
Ciao,
	quando qualcuno mi fa uno scan sulla
31337, il nabber rilascia una scritta del tipo
"port disabled for........."; presumo che quello
indichi che la porta e' stata chiusa (ma solo
dopo aver ricevuto lo scan......); non ho
il BOgui, ma credo che la persona si dovrebbe
trovare di fronte ad un messaggio del tipo
"connection closed by remote host", mentre
da un PC pulito (senza nabber e BO) la
risposta dovrebbe essere
"connection refused by remote host", appunto
perche' nessun processo era all' ascolto.
	Per altro il fine del Nabber e' intercettare
tentativi di Nuke, e non tanto il controllo della
rete; inoltre uno scan alla ricerca di processi
attivi non e' in se' pericoloso (se finalizzato allo
stabilire una connessione con questi....) sono
certi processi ad esserlo...............
		Ciao, Maurizio.


Ciao,
	ho sentito parlare di una patch
adibita alla chiusura "preventiva" delle
porte, tuttavia non ho mai provato a
cercarla, percio' non ti saprei
dare altre indicazioni al riguardo.....


Soluzioni???
Non servono. Se non hai il server.exe di NetBus residente non possono farti
nulla, perdono solo tempo.
Bye
--
mr. good trips
pgp key id 0x1E06361C

Che significa??
Che qualcuno ha inviato un pacchetto di "Richiesta Connessione" fatto
per NetBus, un Trojan. Probabilmente, stava cercando dei NetBus sulla
rete del tuo provider.
La connessione "Password;1;any..." significa che NetBus l'avrebbe, in
ogni caso, fatto entrare.
Normalmente questo "scan" dara' risultato negativo perche' nessuno e'
in ascolto sulla porta 12345, sul tuo computer; ma nel caso tuo, c'e'
qualcuno in ascolto: NukeNabber. Percio' il tizio di Toronto :-) vede
che qualcuno ha risposto e manda la sequenza di login, che NukeNabber
usa per pulircisi il... il buffer, quello della rete... :-)
...comunque, scherzi a parte, dopo sei secondi Toronto lascia perdere
(deve aver capito come stavano le cose). Fine della storia.
Volendo, uno manda una letterina a 
ro...@better.net
, dicendo: "Siore e
siori, il Vs. abbonato collegato il 10/17/1998 00:44:51.620 GMT+0200,
sul POP 
Toronto07-31.Better.Net
, e' nu poco fetuso!".
In caso di rogne gravi (un 'ping' NetBus non e' una cosa grave; se tu
avessi avuto NetBus e fosse entrato allora...) ne uccide piu' la mail
della spada; ma dipende da chi e' il provider.
Se e' su TIN vive tranquillo (5 lamentele, nessuna risposta).
Su IOL anche (3 lamentele, nessuna risposta).
Su Flashnet lo caa l'orso (2 lamentele e 2 accounts trombati nel giro
di 24 ore).
Agora', @TS ed altri non mi hanno mai dato rogne; devono avere utenti
un tantino piu' educati. Tranne Agora', che ha me, che gli abbasso la
media.
Leonardo
".signature": bad command or file name

 Che significa??
Che qualcuno a cercato di scoprire la password del tuo Netbus (che non
hai) per accedere al tuo computer
-- 
Sono gradite risposte anche via e-mail.
Grazie e ciao,
Giglio
!!!ATTENZIONE!!!: il mio vecchio e-mail address 
gig...@crusader.it
 non
e' piu' attivo!!!
E-mail: 
gig...@poboxes.com
E-mail per files binari: 
gig...@mclink.it
Homepage: 
http://members.xoom.com/giglio/
ICQ: 12385960

perche' nessun processo era all' ascolto.
se fai uno scan con il client bo, hai risposta solo se la persona e'
boservizzata. Nel caso non lo sia, non c'e' risposta.


  mailto:
mc....@iname.com


ehehehehh   ... Sei di Livorno????  :-p
No. Abbonato al Vernacoliere.


il tipo mi ha sparato un nuke?
Gia'. Quanto alla faccenda della connessione, "connection refused" o
"closed" vale se la connessione e' di tipo TCP, cioe' orientata alla
connessione, appunto. UDP e ICMP non hanno connessione 8-D


   >>il tipo mi ha sparato un nuke?
   >
   >Non credo, dovrebbe trattarsi
   >di un attacco OOB che (credo...spero....)
   >funziona solo con winNT.
   >
mmmm.... il tipo dall'altra parte ha senza dubbio usato il nuke 2.3 di ATS
(non solo per il Die sucker che e' la frase di default... ma lo scrive anche
il report del nn!!!!).
Questo prog dall'autore e' spacciato come un nuker per win 95....
Di piu' non so, ma... 
			Luca dEX'
Una volta un uomo saggio disse:
"E' sempre una buona politica quella di azionare le sinapsi
 prima  di eiaculare sentenze."
                                 Master

connessione, appunto. UDP e ICMP non hanno connessione 8-D
toglimi una curiosita':
differenza tra scan TCP e UDP.
Con aggressor vedo che lo scan UDP e' veloce, quello TCP no.
Domanda: lo scan UDP e' affidabile? Cioe', se mi dice, per esempio,
che la porta 139 e' aperta, e' così? 
Ci possono essere discrepanze tra lo scan TCP e quello UDP?
Buttha (che ha la netta impressione di aver fatto una domanda idiota,
ma che sa pure che la domanda piu' idiota e' quella non fatta)


che la porta 139 e' aperta, e' cosě?
Le porte TCP e quelle UDP sono diverse. In particolare, per TCP esiste
uno "handshake"
---> "Porta, sei aperta?"
<--- "Socket in apertura, parametri A-B-C"
---> "Confermo A-B-C, parliamone", Z
<--- "Login: ", vedo il tuo Z, rilancio di K
---> "gino", vedo il tuo K, rilancio di T
<--- "Password: ", vedo T, rilancio di Q
---> "pippobaudo (so' diabbolico)!", ...
...non che funzioni DAVVERO cosi', si fa per ridere; comunque i primi
tre passi tu non li vedi (fanno parte dell'apertura del canale), e se
li esegui stai facendo uno "scan" di quella porta.
In UDP, e' previsto soltanto l'invio monodirezionale. Non sai neanche
se quell'altro t'ha sentito, perche' non c'e' il "vedo A, rispondo B"
- la connessione TCP usa un metodo ACK, cioe' ogni pacchetto arrivato
genera, nel pacchetto successivo, un ACKnowledgment (e sarebbe meglio
secondo molti usare il NAK, cioe', si genera una risposta solo quando
un pacchetto NON arriva... ma si esce dal seminato).
Per questo non capisco bene neanche come si possa FARE, uno scan UDP;
tu mandi un pacchetto UDP, ma non hai nessuna garanzia che "qualcuno"
ti RISPONDA. Un server potrebbe rispondere solo se mandi un pacchetto
ben determinato (manda un "sproing" al Boserver, invece del "ping", e
vedi che ti ca'a zero :-) ). Non so se viene rispedito un ICMP che ti
segnali errore, in questo caso (non ho mai provato e non ho voglia di
tirar fuori il manuale: sono pigro!). Mi sa di no.
Su TCP si puo' fare scanning in vari modi: aprendo (completando tutto
il three-way handshake), inviando un pacchetto falso
---> "A proposito dell'apertura di questa porta, rimando K"
<--- "QUALE apertura? E' chiusa!"
	(porta chiusa)
---> "A proposito dell'apertura di questa porta, rimando K"
<--- "K e' sbagliato"
	(porta aperta)
oppure si puo' abortire il three-way handshake appena arriva la reply
- eccetera. Questi ultimi due sono "stealth scan" perche' non avviene
alcun tentativo di APRIRE davvero la connessione, e quindi, i loggers
piu' stupidi non loggano niente.
I loggers moderni su Linux loggano, anzi, mettono pure la bandierina,
con "Suspicious TCP packet (illegal flag: F) from x.y.z.k" 8-)
Leonardo fatto l'inganno, trovata la legge


se quell'altro t'ha sentito, perche' non c'e' il "vedo A, rispondo B"
Eppure...
Dial-Up Adapter [0001][Ref# 367] Blocking incoming UDP: src=195.210.86.72,
dst=212.216.21.7, sport=1027, dport=31337.
Anche a me risultava che il protocollo UDP non desse la conferma della
ricezione, ma se più e più gente li manda un motivo ci sarà...
La cosa mi incuriosisce...fatemi sapere...



UDP non da certezza dell'invio e non ha di per se un sistema
di ACKing (nulla vieta che un protocollo di layer superiore
che si appoggia su UDP abbia pero' un sistema di ACKing di
qualche tipo).
Esattamente come per il sottostante IP puro ("raw") un
pacchetto puo' perdersi o essere scartato da qualcuno durante
il percorso in modo "silenziosio".
Ciononostante quando un host, un firewall o un router blocca
un pacchetto UDP (o in generale un qualsiasi pacchetto IP)
"puo'" inviare indietro al mittente un messsaggio di errore
ICMP (tipicamente un port unreachable, host unreachable,
timeout o un "denied") per avvertirlo, pacchetto ICMP che
a sua volta puo' perdersi lungo il percorso (e in questo caso
non genera MAI ulteriori messaggi).
Se sia una buona cosa o no generare un errore ICMP in risposta
a un pacchetto UDP rifiutato e' difficile da dire, la regola
d'oro di ICMP e' "accettare e capire tutto e mandare il meno
possibile" e del resto mandare un "denied" in risposta a un
tentativo di attacco significa solo fare capire all'attaccante
che non c'e' nulla da fare e fargli risparmiare tempo e fatica.
Per contro negli altri casi (errore generico, porta di un servizio
chiuso ma che di solito non e' un exploit) mandare un errore
ICMP significa far si che chi sta di la capisca cosa succede
e non resti "in attesa" di una possibile risposta fino al
timeout o non continui a provare. [Tipico esempio: identd,
chi non ha identd attivo mandando un errore ICMP in risposta
a un tentativo di connettersi sulla porta ident accelera di
parecchi secondi l'accesso a tutti i servizi che tentano di
identificare l'utente: IRC, alcuni mailserver, alcuni server 
ftp eccetera; con ident attivo o che da un errore entri in un
server irc in meno di un secondo, se e' disattivo e ignora
silenziosamente le richieste senza dare errori di "port 
unreachable" aspetti almeni 10-15 secondi].
Regards,
-- 
Andrea (oggi logorroico)

Andrea (oggi logorroico)
Grazie Andrea.."logorroico" ma efficace :)
Gio' (molto contenta che incrementa le poche nozioni)

ricezione, ma se più e più gente li manda un motivo ci sarà...
Infatti, UDP non da' conferma. Pero' un protocollo di piu' alto livello
(strato delle applicazioni, suppongo) puo', ricevendo un UDP specifico,
RISPONDERE in maniera opportuna.
Per esempio, il protocollo IP non prevede risposte ne' conferme. Pero',
il protocollo TCP, che si appoggia sull'IP (viaggia "dentro" i segmenti
IP), implementa questa risposta.
Nulla vieta di reinventare l'acqua calda e usare un protocollo privo di
connessione (UDP per esempio) per creare un sistema "connesso".
Un modo semplicissimo sarebbe quello di usare, come payload di UDP, uno
header TCP. Si avrebbe una connessione TCP che viaggia con UDP :-), con
uno spreco di banda micidiale, pero' funzionerebbe.
Mi dicono che FSP faccia file transfer in modo analogo.
Leonardo


 
La tua spiegazione e' molto chiara, volevo solo precisare che, in un
ambiente non configurato espressamente secondo criteri di sicurezza,
l'ICMP port unreachable viene SEMPRE inviato quando si tenta di
contattare una porta UDP (o TCP) su cui nessun processo e' in ascolto.
I vantaggi per il buon funzionamento di una rete "normale" dovrebbero
essere evidenti: se non riceve il messaggio di errore, l'applicazione
tipicamente non si arrende prima che sia trascorso un certo timeout, e
solo dopo aver riprovato (i pacchetti che ha inviato per aprire la
connessione potrebbero essere andati persi per vari motivi). 
D'altra parte lo stesso meccanismo puo' essere sfruttato per realizzare
una sorta di ping: mando un pacchetto UDP senza senso ad un host, ad un
numero di porta opportunamente scelto su cui presumo che non ci sia
niente in ascolto (ad esempio una porta scelta a caso ma superiore a
30000), e aspetto che mi ritorni un ICMP port unreachable entro un certo
timeout, esattamente come faccio con il ping tradizionale basato su ICMP
Echo Request e ICMP Echo Reply.
Potrei farlo sia ben chiaro senza alcun intento malevolo, infatti sono
anni che esiste la utility "traceroute" basata proprio su questo
meccanismo ("tracert" di Windows invece non lo e'), ed e' un
dignitosissimo strumento diagnostico come del resto il ping
tradizionale.
D'altra parte lo strumento e' neutrale, come diceva (piu' o meno) un
tizio che di questi tempi viene citato sempre piu' raramente, quindi
"qualcuno" potrebbe approfittare (abusare?) dello strumento ICMP port
unreachable per fare uno scan in cerca di porte aperte in cui cercare
di intrufolarsi.
A quanto pare Internet brulica di questo genere di "qualcuno", quindi
potrei decidere di mettere tra me e loro un "qualcosa" che gli confonda
il piu' possibile le idee, ad esempio rispondendo anche per gli host che
non esistono, bloccando i messaggi ICMP per rallentare gli scan, e chi
piu' ne ha piu' ne metta. Questo non significa necessariamente impedire
l'uso di strumenti diagnostici, piu' che altro limitarlo a chi e'
autorizzato.
Per riassumere: e' vero che UDP non da' alcuna conferma di ricezione, ma
di solito fornisce una segnalazione se e' stata contattata una porta non
utilizzata, il che puo' favorire gli scan. Percio' in quelle situazioni
in cui si vuole tentare di ostacolarli, e' normale che quella
segnalazione venga filtrata. Lo standard pero' e' di mandarla.
Ciao,
Francesco

 Mi dicono che FSP faccia file transfer in modo analogo.
Mi dicono che TFTP fa file transfer con pacchetti UDP e
una sistema di desequenced ACKing, ecco perche' con pingloop
lento e packet loss significativo ma banda ampia e' molto 
piu' veloce di FTP (che invece passa su TCP e per questo ogni
tanto resta "busted" perche' ha perso qualche pacchetto...)
Ciao,
-- 
Andrea

 segnalazione venga filtrata. Lo standard pero' e' di mandarla.
Concordo con il tutto, con una sola precisazione:
non e' affatto "lecito" aspettarsi che anche in condizioni
"normali" (cioe' nulla si e' perso nel percorso) l'errore
ICMP arrivi, un esempio ? Prendo NetBSD e lo installo
in configurazione "standard", poiche' portmapper riceve *tutti*
i pacchetti UDP (o fino alla porta 30000 se non ricordo male)
ed "eventualmente" li passa al demone superiore, "normalmente"
NetBSD non da nessun ICMP di port unreachable e il pacchetto
viene semplicemente "dropped". [E per capire perche' cavolo
quando ero in localhost sul mio server IRC ci mettevo 15-20
secondi a connettermi ce ne e' voluta :-)]
Ciao,
-- 
Andrea

nu...@tin.it
 wrote:
 >Mi dicono che TFTP fa file transfer con pacchetti UDP e
 >una sistema di desequenced ACKing, ecco perche' con pingloop
 >lento e packet loss significativo ma banda ampia e' molto 
 >piu' veloce di FTP (che invece passa su TCP e per questo ogni
 >tanto resta "busted" perche' ha perso qualche pacchetto...)
Questo e` FSP (ma anche TFTP usa UDP), peccato che ormai non lo usi piu`
nessuno, anche perche` ha dei limiti strutturali che ne limitano la
velocita`.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *

piu' veloce di FTP
Pero' allora deve usare una finestra piuttosto grossa, anche su
UDP si perdono i pacchetti... ci sono server tftpd interessanti
a giro? Io ho, per l'appunto, packet losses micidiali (okay, io
esagero, ormai mi conoscete ;-) ) e pingloops da PA.
Ho appena scoperto di avere sia tftp che in.tftpd installati da
sei mesi :-)
Leonardo che si sente notevolmente ignorante


L.S...@agora.stm.it
 wrote:
 >UDP si perdono i pacchetti... ci sono server tftpd interessanti
 >a giro? Io ho, per l'appunto, packet losses micidiali (okay, io
ftp.linux.it
 ha un server FSP installato ma non l'ho mai pubblicizzato.
 >Ho appena scoperto di avere sia tftp che in.tftpd installati da
 >sei mesi :-)
Male, se non hai workstation che fanno il boot via rete non ti serve e
quindi considerate le sue caratteristiche e` un possibile buco da
tappare.


tappare.
No, no: ho tftp e in.tftpd installati, nel senso che ho i binari. In
inetd.conf, tutto quello che non mi serviva l'ho tolto.
Leonardo "e anche quasi tutto quel che non serviva abbastanza :-)"



Buono a sapersi, questa mi mancava. Ma portmapper non e' un demone?
Intendiamoci, non che io voglia avere ragione per forza... anzi nel dire
"lo standard pero' e' di mandarla" ho semplificato di parecchio.
Quello che intendevo e' che il pezzo di codice che implementa il livello
UDP prevede l'invio di ICMP port unreachable quando viene contattata una
porta su cui non c'e' niente (ma proprio niente) in ascolto.
Questo almeno in una (uno?) stack TCP/IP che rispetta gli standard "de
jure", cioe' le RFC, e quelli "de facto" (NON intesi nell'accezione
Microsoft, mi riferisco invece alle convenzioni consolidate nel corso
degli anni -- per esempio questa di mandare l'ICMP port unreachable mi
sa che non e' scritta in nessuna RFC).
Il criterio di sfruttare questo meccanismo per fare degli scan (che poi
e' all'origine del thread) mi pare rimanga valido nella maggioranza dei
casi.
Comunque hai ragione anche tu, e' che stiamo cercando di riassumere
argomenti intrinsecamente complessi.
Ciao
Francesco