Newsgroup: it.comp.sicurezza.varie
Titolo: porte Closed e porte Stealthed

Ho eseguito uno "Steath Scan" dal sito della Sygate e il risultato e stato
quello che mi aspettavo, ovvero tutte le porte che ho chiuso con CHX-I
Packet Filter risultano effettivamente chiuse.
Ma il report di Sygate mi dice che sarebbe più sicuro se fossero stealthed.
Fino a che punto è vera questa affermazione?
Eventualmente a quali rischi sono esposto visto che le mie di porte sono
"solo" chiuse?

Ho eseguito uno "Steath Scan" dal sito della Sygate e il risultato e stato
quello che mi aspettavo, ovvero tutte le porte che ho chiuso con CHX-I
Packet Filter risultano effettivamente chiuse.
Ma il report di Sygate mi dice che sarebbe più sicuro se fossero stealthed.
Fino a che punto è vera questa affermazione?
E poi come mai se uso invece il "Quick Scan" (sempre dallo stesso sito della
Sygate) mi dice che sono "Blocked" ovvero anche stealthed?
Eventualmente a quali rischi sono esposto visto che le mie di porte sono
"solo" chiuse?
Qualcuno mi saprebbe indicare qualche altro test on-line affidabile con cui
poter effettuare anche dei confronti?
Grazie in anticipo a tutti.

 E' falsa.
Mbhe.. si e no, nel senso che è falso il fatto che
una porta closed sia meno sicura di una stealth
è però vero che è possibile floodare una porta
closed .. o utilizzarla con pacchetti spoof per un
attacco DDoS .. non dico che sia semplice ma
può essere fatto; da questo punto di vista una
porta stealth evita di offrire "appigli" del genere
Ciao

 attacco DDoS ..
Con questo sistema l'attaccante ha il vantaggio di non identificarsi, ma
deve comunque avere banda sufficiente a floodare il bersaglio da solo (dato
che ad ogni pacchetto RST al finale bersaglio deve corrispondere un SYN
mandato alla macchina intermedia). Non vedo altri DDoS possibili: un RST su
una connessione inesistente viene ignorato, e un RST e' l'unica cosa
risposta ottenibile da una porta chiusa.
Ciaotutti,
*

 Packet Filter risultano effettivamente chiuse.
Sicuro che sia andato tutto come era tua intenzione? AFAIK non mi
pare che si possano filtrare le porte con CHX-I in altro modo che
non rendendole stealth (cioe' droppando il traffico in ingresso).
Se ora non sono stealth, forse non stai filtrando come intendevi.
Fabio
PS: oppure ci sono nuove features di CHX-I che non conosco.

 proprio qui qualche tempo fa)
Scusate tutti e due se mi aggancio qui ..cmq...
si, l'idea era un DDoS "RST" con ... qualcosina
d'altro ;-) tieni presente che avendo abbastanza
"zombie" a disposizione non č proprio un'idea
cosě balzana (indipendentemente da Gibson o
altri); ammetto che va tenuto in considerazione il
discorso "RST rate limiting" fatto da Alessandro,
resta il fatto che la cosa č possibile (ed č anche
stata fatta); che poi come ho scritto sopra richieda
un certo numero di "drones d'attacco" (si ok ho visto
StarWars ieri sera :-D) beh.. non ci piove
Ciao

Rispondo un po' a tutti:
premesso che quanto segue sono il risultato delle mie osservazioni con uno
sniffer sulla rete locale (di per se dotata di dhcp,dns,web,smtp,pop3 e
nntp, tutto ad uso interno) le regole di chx-i per quanto riguarda il modem
adsl, e quindi la connessione ad internet sono le seguenti:
action type    priotity    direction    source ip    dest ip    protocol
source port                    dest port
deny                1-low    outgoing    any            any         tcp
any                                (!)25,80,110,119,443
deny                1-low    incoming   any            any         tcp
(!)25,80,110,119,443        any
deny                1-low    outgoing    any            any         udp
any                                (!)53,67,68
deny                1-low    incoming   any            any         udp
(!)53,67,68                        any
deny                1-low    incoming    any            any
            -na-                                -na-
inoltre come ho già detto col quick-scant risultano "Blocked", mentre con lo
stealth-scan risultano solo "Closed".
sulla rete interna ci sono pressapoco le stesse regole con una deroga solo
per le porte e i protocolli usati per l'amministrazione remota del server.
però da quello che ho capito dalle vostre risposte mi posso sentire
moderatamente sicuro, un po' di più se penso al fatto che comunque il pc non
è collegato 24h/24h alla rete e che non deve offrire nessun servizio
all'esterno, giusto?

 any                                (!)25,80,110,119,443
<snip>
Uh .. capito !! CHX funziona in "logica inversa", questo significa che
se inserisci (come hai fatto tu) delle regole "deny" questo per CHX
significa "deny" per quelle regole ed ... "allow" per tutto il resto.. e
questo č il motivo del risultato "closed"; direi che dovresti azzerare
le regole e caricare il "workstation sample ruleset" poi magari potrai
personalizzarlo (se necessario) ma in ogni caso dai un'occhiata a
come č costruito tale ruleset (basato su allow .. in pratica "deny all"
eccetto quello che č ammesso) inoltre una volta caricato il ruleset
assicurati che SPI sia abilitato !!
Ciao

 cosa potrebbe amplificare.
Beh .. diciamo di avere "N" macchine "infette con qualcosa" e di
conoscere gli indirizzi di "X" macchine con porte "closed" a questo
punto, ciascuna delle "N" macchine invia alle varie macchine "X"
un "SYN" su una porta closed spoofando il source IP con l'indirizzo
della macchina vittima .... che magari allo stesso tempo è soggetta
ad (es.) un syn flood ... ti torna ora :-) ??

 ad (es.) un syn flood ... ti torna ora :-) ??
No. Esempio:
10 zombie
Vittima con banda da 100kbit
per saturare la banda serve una emissione di 100kbit, mettiamo pacchetti
da 100 bit => servono 1000 pacchetti secondo.
Suddivisi per 10 zombie => 100 pacchetti secondo per ogni zombie.
Per emettere 100 RST/sec l'attaccante deve emettere 100 SYN/sec con
indirizzo spoofato per ogni uno dei 10 zombie => 1000 pacchetti.
A questo punto, attaccante faceva prima a floodare direttamente la
vittima con pacchetti 1000 pacchetti/secondo RST con src spoofata.
-- 
*    HappyCactus - Linux User #209744 - BOFH Certified Engineer    *
*                         
http://www.google.com
                    *
*                                                                  *
*                           ET IN ARCADIA EGO                      *

 cosa potrebbe amplificare.
Mi pare che l'unica cosa in cui si guadagni ad attaccare in questo
modo sia di complicare il traceback delle vere sorgenti, specie se
usi ogni "riflettore" per brevissimo tempo (tanto ce ne son quanti
ne vuoi).
Fabio

 significa "deny" per quelle regole ed ... "allow" per tutto il resto..
chx-i permette il force-allow, allow (deny all except), deny.
Io in particolare, nota il (!) prima delle porte, ho negato tutto ad
eccezione di ciò che specifico, che praticamente equivale al allow (deny all
except).
La cosa sarebbe stata più chiara se le righe non fossero state spezzate.
Ero partito con i sampleset del programma, ma non capivo bene le regole,
perciò mi sono messo con uno sniffer alla mano e ho verificato quali fossero
effetivamente i protocolli e le porte che mi servivano.
Cmq no mi spiego perchè con un test mi dice che sono solo chiuse e con
l'altro mi dice che sono stealth.
Ad occhio e croce posso stare tranquillo con le regole che ho imposto io?

 Vittima con banda da 100kbit
OK ... 1000 zombie ... tanto ci vuole
poco ... basta vedere netsky ...
cmq resta il fatto che se metti la porta
in stealth eviti anche 'stò pensiero....
e resta anche il fatto che stealth o closed..
la _sicurezza_ non cambia di una virgola
checchè ne dicano siti vari ...
Ciao

 regole che ho imposto io?
Hm .. si, solo che con quelle regole hai dei "buchi" in "allow"
che potrebbero essere sfruttati per mettersi in "listen", secondo
me.. come scrivevo sopra.. ti conviene ripartire dal "sample"
(magari salvati il tuo set) e proseguire da lì con l'aiuto del
manuale .. e magari anche del forum
Ciao

 ne vuoi).
Esatto ... supponi che gli "zombie" in attacco siano (esempio a
caso) delle macchine con delle belle connex .. OC3 o simili, a
quel punto, se non ti vuoi "bruciare" gli zombies usi un bounce
del genere .. o anche altre cosucce simili

 in stealth eviti anche 'stò pensiero....
E te ne cerchi altri 35 quando sei in altre situazioni: se iniziano ad
arrivarti SYN/ACK di rimbalzo e non rispondi con RST, ti becchi anche
tutte le ritrasmissioni fino a timeout...
In *questo* caso, ottieni una moltiplicazione del traffico. A tuo
danno...
-- 
the Skull says:
+---------------------------------------------------------------------+
 We are Pentium of Borg. Division is futile. You will be approximated.


Spero che quei buchi si riferiscano agli "any port", altrimenti la mia poca
conoscenza della materia non mi fa vedere altri problemi.
Se è così forse è meglio che ti descriva, seppur a grandi linee, il
ragionamento che ho seguito, magari mi puoi dare qualche indizio su
cos'altro dovrei considerare:
Come già detto il pc che fa da server e da gateway per la rete monta iis per
il web (con php e mysql sotto), server dhcp,dns e posta e news, tutto ad uso
esclusivo della rete interna.
Le regole le ho create e testate sulla rete interna e poi le ho trasposte
sul modem anche se con una filosofia di fondo leggermente diversa.
In pratica sulla rete interna ho dapprima negato espressamente qualsiasi
tipo di traffico e poi gradatamente ho usato i force allow per i servizi che
mi interessano, sul modem invece ho riassunto le regole interne nella
maniera in cui ti ho mostrato.
Teoricamente il server mi fa da barriera con l'esterno, infatti accetta
connessioni solo sulle porte che ti ho elencato nei permessi e stabilisce
connessioni con l'esterno sulle stesse porte.
Nelle mie piccole prove nessun programma (chat,p2p,file sharing, ecc...) o
servizio tipo netbios che funzioni su porte diverse dalle specificate è
riuscito a portare a termine la sua funzione. Consultando i log tutto è
rimasto confinato all'interno della rete oppure al di fuori della stessa,
niente è transitato da dentro a fuori o viceversa.
Cmq sto per ricaricare le regole del sampleset per cercare di capire meglio
come mi devo comportare.
Grazie per le info e apresto.

 (banda in ingresso al target).
Uhm .. mi sa che non ci siamo capiti, per "zombie" intendo macchine
"infette con qualcosa" e controllabili da remoto, a quel punto basta
inviare agli "zombie" qualche pacchetto di "comando" contenente la
lista dei "riflettori" (macchine con porte closed) e l'IP della vittima, da
quel momento ciascuno degli "zombie" inizierŕ ad inviare SYN ai vari
riflettori spoofando l'IP origine con quello della vittima a questo punto
quello che conta č avere abbastanza "zombies" .. dato che di sistemi
con porte "closed" ne puoi trovare a bizzeffe

 comportare.
Beh .. ti consiglio di postare una richiesta sul forum
http://forum.idrci.it
 visto che a quanto ne so sia Stef
che Luca lo controllano regolarmente, detto questo
L'importante è capire l'idea di BASE di CHX, ossia
nel momento in cui crei un ruleset, CHX imposta il
tipo di ruleset in base alla prima regola per cui
Se la regola è "allow" CHX assume che tutto quello
non permesso dalla regola andrà automaticamente
in "deny" (drop)
Se la regola è "deny" CHX assume che tutto quello
non bloccato dalla regola andrà automaticamente
in "allow" (permit)
questo significa che, se ad esempio imposti soltanto
tre regole del tipo (uso una sintassi spannometrica)
allow, outbound,  local, anyport, remote, 80, tcp
allow, outbound, local, anyport, remote, 110, tcp
allow, outbound, local, anyport, remote, 25, tcp
allow, inbound, local, 25, remote, anyport, tcp
assumendo di avere SPI abilitato avrai permesso il
traffico in uscita per HTTP e POP3 ed SMTP ed inoltre
permesso il traffico SMTP in ingresso ma _bloccato_
il resto del traffico, in pratica è come avere una regola
finale automatica "deny all" ... spero sia chiaro
Ciao


/me ci pensa...
/me conclude che hai raGGione
Ciaotutti,
*

 vittima
E senza ottenere nessun vantaggio rispetto a mandare i SYN direttamente alla
vittima spoofando l'ip sorgente con quello di qualcun'altro, magari un'ALTRA
vittima...
Ciaotutti,
*

 con porte "closed" ne puoi trovare a bizzeffe
Si, ma, come detto, dove sta il vantaggio?
Per far arrivare un RST al target, ogni zombie dovrà inviare un SYN a uno
dei "riflettori".
Se proprio vuoi fargli arrivare una scarica di RST (qualunque possa essere
lo scopo, il che mi sfugge...), tantovale che ogni zombie forgi
direttamente un rst e lo invii al target.
Non cambia nulla, quindi non c'è nessuna ragione per usare un
"riflettore"...
-- 
wash the blood from your hands
bury your secrets in the sand
and forget


si, č chiaro. I miei problemi venivano dal fatto che sono partito dal
ruleset del public server visto che effettivamente il mio "server" offre dei
servizi alla rete interna come posta,news e http.
Le regole della workstation invece sono molto piů semplici anche se ho visto
che si limitano all'incoming e permettono parte dell'ICMP.
Non so se per ignoranza o per eccesso di zelo ho voluto regolamentare sia il
traffico entrante sul modem che l'uscente, ovvero della serie "bravo, sei
riuscito ad entrare, ora perň devi anche riuscire ad uscire!!".
Questo perchč ho voluto rendere esplicita quella che tu hai indicato come
"regola finale automatica deny all" (sulla rete interna sono partito con due
regole deny all incoming e outgoing e poi ho liberato le porte che mi
servono).
Ti ringrazio per i consigli e consultando i log al momento pare che le
regole funzionino abbastanza bene, bloccano di tutto, ping, pacchetti syn e
tanta altra roba che arriva a mia insaputa.
Col tempo spero di perfezionare il tutto e pararmi quanto piů č possibilie
il c.... ops, volevo dire popň!
Ciao ciao e ancora grazie.

> Si, ma, come detto, dove sta il vantaggio?
Beh ... evitare che qualcuno possa risalire alla
reale sorgente dell'attacco .. inoltre, il discorso
di usare dei riflettori per SYN č anche quello di
"allargare" il range di indirizzi di provenienza
dei pacchetti rendendo impossibile un filtraggio
a livello di router o firewall, in pratica avendo che
so .. 1000 "zombies" potresti generare pacchetti
SYN da .. diciamo 1000000 di indirizzi diversi il
tutto senza "bruciare" gli zombies (i cui indirizzi
non saranno mai direttamente visibili nei logs
della vittima) e rendendo in ogni caso molto piů
difficile il risalire alla reale fonte dell'attacco...
Ciao

 "allargare" il range di indirizzi di provenienza
Se i syn sono spoofed, il source puo' avere almeno 2^32 indirizzi di cui
2^32-1 saranno falsi ;)


 del genere .. o anche altre cosucce simili
Be', non puoi certo esser sicuro di non bruciarteli, ovviamente :-) 
Semplicemente aggiungi un po' di altra strada che, chi indaga, deve
percorrere a ritroso per arrivare al tuo zombi, magari passando per
i router di qualche oscuro provider birmano o per un telefonino 3G.
Con questo non intendo assolutamente dire che sia piu' sicuro o che
sia preferibile usare policy DROP indiscriminate, e' ovvio.
Fabio

 i router di qualche oscuro provider birmano o per un telefonino 3G.
Appunto... è _ovvio_ che la sicurezza al 100% non esiste, ma visto
che parecchi sysadm sono _pigri_ (ed altri sono palesemente ....
lamers) una cosa del genere ..come dire.. alle volte aiuta :-)

 2^32 indirizzi di cui 2^32-1 saranno falsi ;)
Ok ... solo che ... moltiplica quanto sopra per il numero
di possibili "riflettori" (non "zombie" .. "riflettori") e rifatti
il calcolo .. poi vedi :-)
PS/OT:
Stavo rileggendomi or ora il numero di Aprile di LJ
(LinuxJournal) e ci sono alcune cosucce interessanti
.. a parte la "serie" su Zorp, ci sono alcune cosette su
iptables che, anche se non nuovissime sono.. come
dire .. intriganti, tipo ad esempio
iptables -A INPUT -p tcp -m tcp -m mport --dports 135,139.1025 -j TARPIT
Ciao :-)

 giustamente e' stato osservato.
Cioè mi stai dicendo che se io forgio un SYN con srcip 195.130.225.118
(per pigliare il primo ip a caso), lo faccio partire con un TTL di 58
(tanto per romperti le balle) tu riesci a capire che invece è arrivato da
me?
Senza avere sniffer su ogni routing hop?!?


 iptables -A INPUT -p tcp -m tcp -m mport --dports 135,139.1025 -j TARPIT
Opportunità carina di rompere le balle ad un sacco di spam-bot, ritengo...


 Opportunità carina di rompere le balle ad un sacco di spam-bot, ritengo...
E non solo <g> quello sopra, preso pari pari da LJ era un'esempio
con utilizzo di porte "netbios" ma .. avendo voglia/banda/risorse
mettere in piedi un tarpit potrebbe far comodo .. non fosse altro che
per raccogliere indirizzi IP "infetti" da inserire direttamente nella lista
"/dev/null" del router .. così si evita del tutto anche il traffico :-)
Ciao

 "/dev/null" del router .. così si evita del tutto anche il traffico :-)
Beh.. per far questo genere di cose non serve certo mettere su tarpit,
però... basta una normale honeypot con un po' di logging e un paio di
script.
L'idea di tarpittare qualche porta (mydoom?!?) di tutta la classe B è
invece una cosa che mi attizza... <g>


 Senza avere sniffer su ogni routing hop?!?
Forse quel tizio... quello del film che, da poco, gira nelle sale... con
la barba et con cotanto padre, hai presente? Lui avrebbe qualche chance,
penso. Quel che non capisco e' perche' ipotizzare che non si possa avere
una idea di quel che passa dai vari router. Anche senza avere sniffer di
sorta (un incubo su certe appliance) ci sono altri strumenti che possono
aiutare a fare il backtrace (tipo netflow rmon et similia) in una ottica
di collaborazione tra i soggetti/isp/carrier attraverso cui transitano i
flood incriminati. Se stai floodando direttamente dai tuoi zombie, bot o
quel che vuoi, alla lunga e con difficolta' puoi riuscire a risalire fin
alla sorgente, se c'e' collaborazione. Se stai "rimbalzando" arriveranno
subito a trovare il povero "riflettore", ma se lo usi per poco tempo per
poi passare velocemente a un altro e' piu' difficile per gli inseguitori
mettere in atto i meccanismi per cercare di risalire alle sorgenti. Se i
pacchetti arrivan direttamente dagli emettitori che spoofano la sorgente
o hai un grandissimo numero di bot, oppure, se vuoi sostenere il flood a
lungo, prima o poi i bot potrebbero venir scoperti. Per lo meno, in meno
tempo (molto meno, IMHO) che nell'altro caso. Tutte supposte ovviamente.
E, altrettanto ovviamente, non stiamo parlando di mettere in piedi cacce
del genere per una scaramuccia su irc, ma per i grossi flood che vedono,
tra le vittime, entita' che giustifichino i mezzi da dispiegare.
A un tale gibson, se non mi ricordo male, avevan fatto sudare un paio di
camice dietro a un flood del genere. Gibson quello ROTFL, non quello del
Signore barbuto di cui sopra.
FantaFabio
PS: tra l'altro rimbarzando puoi anche passare per reti remote et oscure
    anche se non hai il controllo di macchine che vi appartengono.

 del Signore barbuto di cui sopra.
Si .. ho letto la cosa .. anche se non č che creda molto al resoconto, resta
il fatto che il flood ha sbattuto l'intera network bersaglio fuori da
internet per
delle ore intere ... ed era un giochino come quello sopra ... per cui la
cosa
funziona.. oltretutto se non ricordo male un'attacco del genere ha avuto
anche altri bersagli .. se riesco a trovare i links li riposto ..
Ciao

 mettere una buona metà di internet in null-routing ovviamente)
Questa invece è una obiezione con continuo a ritenere falsa: visto che
il null routing lo fai sulla destination, e visto che il traffico
proviene in entrambi i casi da ip a caso, vorrei capire che cosa
null-routeresti, in entrambi i casi: l'ip reale dell'emittente? e da
dove lo hai pescato? E che effetto avresti su pacchetti che tanto non
risultano averci nulla a che fare in ogni caso, visto che appartengono
a qualcun altro?
L'ip spoofato? e a che pro, visto che in entrambi i casi è random?
Anzi: l'attacco di rimbalzo, per sua natura, risulta provenire da ip di
macchine reali, con un grado di randomicità sicuramente inferiore a
quello di un source fully-spoofed. Per cui, a ben vedere, il secondo
caso è anche peggiore per il difensore, in un certo -inutile- senso...
Hola entrambi...


 diventa veramente "nearly impossible".
Son d'accordo, ma è una considerazione che IMHO ignora l'inerzia di
providers e carriers in questo genere di attività.
Se iniziano ad essere coinvolti una decina di hop, il tempo di risposta da
una qualsiasi segnalazione ed indagine sarà di almeno una settimana, per
la mia percezione.
Inoltre, se si iniziano ad avere transiti su backbone internazionali,
perchè ci sia un interessamento effettivo, la questione deve essere
davvero grossa.
E avere una cosa davvero grossa con una tattica come quella descritta, che
non fa uso di alcun amplificatore, richiede averne davvero *tanti*, di
zombie (e quindi *tanti* provider e carriers coinvolti).
In un tempo ragionevole (ipotizziamo una settimana, che comunque per un
evento di tale portata è una enormità) quanti è plausibile individuarne?
10? 100? 1000? è comunque una frazione abbastanza bassa della massa critica
necessaria a portare un attacco della portata ipotizzata...
Tutto IMHO, aspetto smentite ;-)


 Tutto IMHO, aspetto smentite ;-)
No .. non si tratta di smentire, ma di rivedere il tutto nell'ottica
corretta; ammetto
che una cosa del genere non sia qualcosa portato avanti dal solito
"lameruzz"
ma .. visti i tempi, potrebbe essere un problema; a questo punto, tornando
al
discorso originale, visto che piazzare le porte in stealth non costa nulla..
non
vedo perchè non farlo... sembra di assistere alle discussioni di parecchio
tempo
fa a proposito del filtraggio dei (famigerati) broadcast ICMP :-) ....
Ciao

 
beh ottica corretta mi pare una affermazione molto Gibsoniana (sempre
quello ROTFL), applicata all'argomento.
Se l'obiettivo è non favorire l'utilizzo di proprie macchine nel corso di
attacchi verso terzi, come fatto notare in altre occasioni, avere porte in
stealth è la maniera migliore di farsi spoofare per un bel syn flood...
Quindi, il vantaggio dove sta?


 Quindi, il vantaggio dove sta?
Urk .. prima di tutto non  ho associazioni con SG e neanche
partecipazioni (non mi paga se è per questo) inoltre il fatto
che io frequenti (si, lo ammetto ... ok ... vai di flame .. chissene)
i newsgroups di GRC non e ripeto NON significa che io
condivida determinate opinioni o punti di vista; detto questo
il discorso di farsi "spoofare per un bel syn flood" dipende
molto anche dalla config del router (e non solo da quella del
f/w) inoltre, a meno di non dover pubblicare servizi (es. un
server SMTP o DNS) non vedo il problema nel mettere le
porte in stealth ... ma... ripeto, forse mi sbaglio; fatto sta che
alcuni tizi (es. tal Dave Anderson) consigliano proprio di
impostare tale "modalità" di filtraggio (escludendo ovviamente
eventuali servizi pubblicati) cmq, come ripeto, potrei essere
completamente in errore ... nessuno ha mai detto il contrario
Ciao :-)

 porte in stealth ... ma... ripeto, forse mi sbaglio; fatto sta che
Il problema invece si pone, visto che il syn-flood richiede due condizioni
al contorno:
1) che l'ip spoofato non risponda quando riceve i SYN/ACK di rimbalzo,
sennň gli RST chiudono le risorse allocate dal SYN spoofato, provocando al
massimo la saturazione della banda del target ma nulla piů...
2) che la macchina spoofante (lo zombie) possa fare spoof (quindi niente
egress filtering sui router che ha davanti)
Nel caso in questione, sulla 2 non hai controllo, ma se metti in atto la 1
(appunto) altro non fai che facilitare il compito di chi il flood lo sta
facendo. In quest'ottica, che tu stia facendo girare un webserver o che
l'ip sia di una stampante di rete non ha rilevanza di sorta...
Quindi non sosterrei con leggerezza il fatto che "se le metti stealth non
fai nulla di male e contribuisci a rendere la rete piů sicura"...
;-)
Uno skull che era da un pezzo che non capitava...


 Uno skull che era da un pezzo che non capitava...
...mbhe ... che c'č di male :-) ?? Mica stiamo sparandoci addosso;
finchč si parla (senza partire in quarta con flames) va tutto bene imo
Ciao :-)

 finchè si parla (senza partire in quarta con flames) va tutto bene imo
Mica mi lamentavo... :-P
Uno skull che una impressione: o di routing e filtering non c'ha mai
capito una sega, oppure di recente la mia abilità dialettica lascia molto a
desiderare... ;-)


 non fai nulla di male e contribuisci a rendere la rete più sicura"...
Condivido in pieno. Lo scenario da fantascienza dell'attacco distribuito
e la presunta rintracciabilita' di un attacco diretto con syn spoofati
contrapposti ai vantaggi di avere le porte closed e quindi di rispondere
negativamente alle richieste di connessione, mi convincono assai.
