Newsgroup: it.comp.sicurezza.varie
Titolo: porte da controllare

Mi sono installato NukeNabber 2.9.
Queste sono le porte che controllo:
[09/21/1998 13:22:09.830 GMT+0200] Attivo sulla porta 5001 (tcp).
[09/21/1998 13:22:09.830 GMT+0200] Attivo sulla porta 5000 (tcp).
[09/21/1998 13:22:09.830 GMT+0200] Attivo sulla porta 1080 (tcp).
[09/21/1998 13:22:09.830 GMT+0200] Attivo sulla porta 1032 (tcp).
[09/21/1998 13:22:09.940 GMT+0200] Attivo sulla porta 1029 (tcp).
[09/21/1998 13:22:10.000 GMT+0200] Attivo sulla porta 1027 (tcp).
[09/21/1998 13:22:10.000 GMT+0200] Attivo sulla porta 139 (tcp).
[09/21/1998 13:22:10.000 GMT+0200] Attivo sulla porta 138 (tcp).
[09/21/1998 13:22:10.000 GMT+0200] Attivo sulla porta 137 (tcp).
[09/21/1998 13:22:10.000 GMT+0200] Attivo sulla porta 129 (tcp).
[09/21/1998 13:22:10.050 GMT+0200] Attivo sulla porta 53 (tcp).
[09/21/1998 13:22:10.050 GMT+0200] Attivo sulla porta 19 (udp).
[09/21/1998 13:22:10.050 GMT+0200] Attivo sulla porta 31337 (udp).
tutto giusto?
Qualche aggiunta da fare?
Buttha (che comincia ad attrezzarsi)
-----------------------------------------------------------------------
* Il giudice disse: "Figliolo, cos'hai da dire a tua discolpa?"
  "Cinquantasette canali, e niente da vedere."
* Per rispondere rimuovere niente
* PGP Key available with fingerprint:
  7772 5C72 7392 538B  34B8 A189 13BC 867A

 Buttha (che comincia ad attrezzarsi)
Tutto giusto, solo che cosi' le porte sono aperte! (controllate, ma
aperte!)
Umpi

aperte!)
e quindi? tanto le gestisce il NukeNabber!!! Mica è invisibile! secondo te
le apre e basta? Non ce passa nienteeeee! eh eh
Cmq mettici anke le 61466 TCP e 50505 TCP; vengono usate da altre backdoorz
che non mi sto ricordando!
ciaociao
x



aperte!)
ma il nukenabber ha l'opzione per chiuderle:
nel caso in cui becca qualcuno a curiosare, chiude la porta per un
intervallo di tempo a scelta.
Basta come precauzione? O, prima che riesca a chiudere la porta, si
riescono a fare lo stesso danni?
Buttha (sempre piu' curioso)


Buttha (che comincia ad attrezzarsi)
Netbus si collega alle porte 12345 e 12346
Ciao, Franco.
Key fingerprint: A6 A1 62 22 5F FB F6 04  64 4E 33 E8 C8 6F CB 9A

le apre e basta? Non ce passa nienteeeee! eh eh
Ah si'? Si comincia a dire che e' possibile mandare dati OOB, il Nabber
non li ferma, ergo ti ci vuole la patch.
Inoltre i sockets il Nabber li apre e ci legge dati, e consente di fare
un pessimo servizio allo stack TCP.
Leonardo
".signature": bad command or file name

riescono a fare lo stesso danni?
La seconda che hai detto...


Netbus si collega alle porte 12345 e 12346
tcp o udp?
Buttha (ignorante che cerca di rimediare)


La seconda che hai detto...
considerando che io non chatto, c'è qualche porta che posso tenere
chiusa (dalla lista che ho dato)?
Buttha (che brama risposte)


tcp o udp?
tcp.


chiusa (dalla lista che ho dato)?
Allora:
[09/21/1998 13:22:09.830 GMT+0200] Attivo sulla porta 5001 (tcp).
[09/21/1998 13:22:09.830 GMT+0200] Attivo sulla porta 5000 (tcp).
[09/21/1998 13:22:09.830 GMT+0200] Attivo sulla porta 1080 (tcp).
[09/21/1998 13:22:09.830 GMT+0200] Attivo sulla porta 1032 (tcp).
[09/21/1998 13:22:09.940 GMT+0200] Attivo sulla porta 1029 (tcp).
[09/21/1998 13:22:10.000 GMT+0200] Attivo sulla porta 1027 (tcp).
Queste non ti servono davvero: le >1024 sono aperte in outbound, a
meno che tu abbia qualche software mai visto per Windows 95.
[09/21/1998 13:22:10.000 GMT+0200] Attivo sulla porta 139 (tcp).
[09/21/1998 13:22:10.000 GMT+0200] Attivo sulla porta 138 (tcp).
[09/21/1998 13:22:10.000 GMT+0200] Attivo sulla porta 137 (tcp).
Queste tre ti tocca. Pero', se disinstalli NetBIOS o magari installi
WinNuke95 e selezioni "Patch against Nuke", le puoi togliere. E dopo
puoi anche togliere WinNuke95 :-)
[09/21/1998 13:22:10.000 GMT+0200] Attivo sulla porta 129 (tcp).
129 non e' neanche un servizio standard.
[09/21/1998 13:22:10.050 GMT+0200] Attivo sulla porta 53 (tcp).
SE non hai un DNS sul tuo PC, accessibile dall'esterno, puoi levarlo
[09/21/1998 13:22:10.050 GMT+0200] Attivo sulla porta 19 (udp).
Il servizio chargen non ce l'hai, su Win95. Su WinNT, eliminalo, dal
pannello di controllo "Small TCP Services".
Questo suggerimento (19 e 53) deriva dal fatto che puoi indurre NT a
cortocircuitare le proprie porte 19 e 53, uccidendosi :-) ... ma, se
hai Win95/Win98, non te ne fai niente.
[09/21/1998 13:22:10.050 GMT+0200] Attivo sulla porta 31337 (udp).
Non ti arrivano nukes sulla 31337 UDP. Puoi magari vedere chi e' che
cerca di connettersi ad un eventuale boserver sul tuo PC.


 non li ferma, ergo ti ci vuole la patch.
Quale patch? dove la prendo?
-- 
Sono gradite risposte anche via e-mail.
Grazie e ciao,
Giglio
E-mail: 
gig...@crusader.it
E-mail per files binari: 
gig...@mclink.it
Homepage: 
http://members.xoom.com/giglio/
ICQ: 12385960

Quale patch? dove la prendo?
ftp.microsoft.com... ora non ho con me il database preciso, comunque
c'e' un index.txt di un 300 Kb, con tutte le patch esistenti e a che
cosa servono.
Puo' essere utile anche patchare il registry; c'e' un programma, che
si chiama WinNuke95 e che lo fa automaticamente. Sono *quasi* sicuro
di averlo trovato dentro uno script per mIRC ("Vandalism-qualcosa"),
che avevo tirato giu' da 
www.nonsolokick.com
 in cerca di falle. Era,
pero', una bestia immane. 600 K o giu' di li'.
Vedi se trovi il solo winnuke presso 
ftpsearch.ntnu.no
 ("nu" e "no",
forse, sono invertiti; sai, l'Alzheimer...)


cerca di connettersi ad un eventuale boserver sul tuo PC.
per essere chiari, mi interessa monitorare chi cerca di "introdursi"
nel mio PC quando sono in rete. Cioe' chi e' in cerca di trojan e
simili. In pratica voglio difendermi da possibili intrusioni, e voglio
vedere chi ci prova (e mandargli una ricevuta di ritorno con
aggressor, ma questo non ditelo a nessuno...)
Io non chatto, il PC ha win95 e solo collegato tramite tin.
Dopo le vostre precise risposte sono arrivato a questa situazione:
[09/25/1998 14:58:20.190 GMT+0200] Attivo sulla porta 139 (tcp).
[09/25/1998 14:58:20.190 GMT+0200] Attivo sulla porta 138 (tcp).
[09/25/1998 14:58:20.190 GMT+0200] Attivo sulla porta 137 (tcp).
[09/25/1998 14:58:20.190 GMT+0200] Attivo sulla porta 31337 (udp).
[09/25/1998 14:58:20.190 GMT+0200] Attivo sulla porta 61466 (tcp).
[09/25/1998 14:58:20.190 GMT+0200] Attivo sulla porta 50505 (tcp).
[09/25/1998 14:58:20.190 GMT+0200] Attivo sulla porta 12345 (tcp).
[09/25/1998 14:58:20.190 GMT+0200] Attivo sulla porta 12346 (tcp).
tutto bene?
Buttha ("fin qui tutto bene, il problema non e' la caduta, ma
l'atterraggio" L'odio)


[09/25/1998 14:58:20.190 GMT+0200] Attivo sulla porta 12346 (tcp).
OK.


Perkè gli hai fatto togliere la 5000 tcp? E' quella usata da Sokets de Trois
v1. Come anche la 1080 è usata da una backdoor di cui non mi sto ricordando
il nome. Un ultimo consiglio fresco fresco di giornata: mettici anke la 555!
ciaociao
x

Un ultimo consiglio fresco fresco di giornata: mettici anke la 555!
certo che la metto; tcp?
Quale nuove simpatico programmino usa la 555?
Buttha


 Nuovo proprio no!  Master paradise e' una delle backdoor piu' vecchie mai
viste.
    .. cio' non toglie che sia una delle migliori!

    .. cio' non toglie che sia una delle migliori!
P.S: eppure a me continua a non funzionare ... molte versioni mi dicono ke è
già scaduto (anke se torno indietro con la data!), compresa la 9.8, mentre
la 8 funziona, ma solo il client ... il server no!!!  ;-(

...
| Nuovo proprio no!  Master paradise e' una delle backdoor piu' vecchie mai
|viste.
|
|    .. cio' non toglie che sia una delle migliori!
|
|
HAAAAA monello !!!!!!!!! Master paradise !!!!!!!! spippola dietro la porta
!!!!!!!
Ciao MASTER ;-)
WROTE     THE  ///\\\ END

ah gia' e' vero .. ma guarda .. ormai faccio confusione!!
   deve essere Leonardo che mi ha attaccato l'Altzaimer. ;-))

ok...ma 555 tcp o udp?

non li ferma, ergo ti ci vuole la patch.
Ho le idee un po' confuse. Potresti spiegarmi dirmi che sono e come l
lavorano questi dati mandati fuori banda.
Grazie       Stefano

ok...ma 555 tcp o udp?





pin...@usa.net
 (stefano) wrote:


Facile: c'e' un bit nello header TCP che vale 0 di serie, 1 se il dato
e' "urgente". E' l'undicesimo bit della settima word, o il primo dei 6
flags TCP (OOB, ACK, PUSH, RST, SYN, FIN)... gli altri servono per una
gestione dello "handshake" di apertura [NdA: e sono quelli che rendono
impossibile lo spoofing per un socket TCP, fatte salve tecniche losche
di SEQACK-guessing... ho letto giusto di recente su BugTraq sul come i
validi programmatori di Redmond abbiano messo un sequencer in WinNT da
fare onco ai sassi... Marco, te ne sai mica niente...?]
Win95 non gestisce il caso in cui quel bit sia 1. Be', non gestiva. La
patch glielo fa ignorare. Se la porta e' chiusa, ovviamente il dato e'
lasciato non-processato, e puo' contenere tutti gli OOB che vuole...
...comunque in questo momento m'e' venuto il sospetto d'aver non detto
ma PENSATO una colossale stronzata, per cui torno ai miei tulz ;-) per
vedere se e' vero... e se e' vero la patch che serve non e' quella che
avevo pensato io :-)
Leonardo che serve sempre. Patchate, patchate!


avevo pensato io :-)
Tanto per non smentirmi, l'avevo pensata infatti. E l'avevo anche
DETTA. NukeNabber ferma  i pacchetti marcati "out of band", pero'
per farlo apre una porta, e di conseguenza si espone all'invio di
pacchetti con frammentazione anomala su quella porta.
Quindi se adesso, vivadio, la dico giusta (ma non fidatevi)... le
cose stanno cosi':
					   	OOB	Frag
Windows non patchato, RAS ha solo TCP/IP	No	No
Windows non patchato, porta 139 chiusa		No	No
Windows non patchato				SI	SI
Windows patchato				No	SI
Windows con l'ultima patch 
www.microsoft.com
	No	No
 (che pero' non so se e' solo per Socket2)
Windows con NukeNabber				No	SI
E' chiaro quindi che, se hai un Windows con porta 139 chiusa, non
solo NukeNabber non ti serve, ma ti fa pure dei danni. La patch a
quanto mi consta e' la strada migliore.
C'e' un programmino, WinNuke95, che fra le varie cose modifica il
registro di sistema (poi devi riavviare) e chiude 139 e simili.
Leonardo


v1. 
Perche' non sapevo neanche che esistesse, 'sto coso che dici. Cos'e',
l'ennesima backdoor via TCP?
Leonardo che se gli gira storto mette su uno scanner *generico* B-[


 avevo pensato io :-)
eheheh forse anche io ... non le diciamo tutti prima o poi ;) ?!
invy

eheheh forse anche io ... non le diciamo tutti prima o poi ;) ?!
Pero' io di piu'.
Leonardo che rivendica il primato (o primate?)


Leonardo che se gli gira storto mette su uno scanner *generico* B-[


L.S...@agora.stm.it
 wrote:
 >validi programmatori di Redmond abbiano messo un sequencer in WinNT da
 >fare onco ai sassi... Marco, te ne sai mica niente...?]
Non c'e` molto altro da sapere, su bugtraq hanno detto tutto il
necessario. Riassumendo: NT e` estremamente vulnerabile al blind
spoofing fatto tirando a indovinare il sequence number.
Banalizzando: chiunque sia abbastanza determinato puo` aprire una
connessione TCP con un host NT facendo finta di essere un altro host.
-- 
ciao, | [Per rispondere togli "toglimi" dal mio indirizzo.]
Marco | * The Internet is full. Go away.  -- Joel Furr *













in...@eCheLoN.net wrote:
 >dall'implementazione dello stack TCP (ad esempio URG e' in posizione
 >diversa nello stack SUNOS e Linux)
Figuriamoci. Anche ammettendo che sia in una posizione diversa nella ram
del computer (ma chissenefrega? Per accedere ai dati del pacchetto uso
la struct definita negli #include di sistema.) i pacchetti che passano
in rete sono tutti in Network Byte Order.


Si! ma fa piu' vasini lei ke il virus CIH!!! ;-(
vasini??? e ke sono?? ho detto KASINI non VASINI!!!  eheheh
ciaociao
x

Ommadonnamia!!! scusate per i post ma sto Outlook Express è veramente uno
skifo a postare!!! :-\
ciao
x
PS: spero ke questo arrivi una sola volta

Pero' io di piu'.
se lo dici tu :) (e' una stronzata ? :P)
invy

 >diversa nello stack SUNOS e Linux)
<Figuriamoci. Anche ammettendo che sia in una posizione diversa nella ram
<del computer (ma chissenefrega? Per accedere ai dati del pacchetto uso
<la struct definita negli #include di sistema.) i pacchetti che passano
<in rete sono tutti in Network Byte Order.
ARGH! Ma allora qui si prendon tutti per fessi !?
E' MALEDETTAMENTE OVVIO CHE TUTTE LE COMUNICAZIONI SEGUANO LO STESSO ORDER.
E poi che c'entra la ram ?! IO parlavo dello stack. Ovvero le struct tcphdr
hanno le varie flag in posizioni diverse su linux/x86 e SUNOS/SPARC ad es.
Puoi dare un occhio alle differenze tra netinet/tcp.h e linux/tcp.h
PUNTO. Poi e' ovvio che il network byte order sia lo stesso ;) altrimenti
come faremmo a portare avanti questo inutile scambio di msg ??? :)
invy

E' MALEDETTAMENTE OVVIO CHE TUTTE LE COMUNICAZIONI SEGUANO LO STESSO ORDER.
Allora, siamo tutti d'accordo. Per precisare, io mi riferivo
all'endianity e al formato Network, e intendevo "parola" con
16 bits.
Ohe', mica ci ammazzeremo per un fetente bit! 8-D... sarebbe
un ulteriore danno del winnuke 8-D
Leonardo
