Newsgroup: it.comp.sicurezza.varie
Titolo: E' possibile "bypassare" un firewall?

Buongiorno  e un saluto a tutti i partecipanti.
Vorrei un vostro parere riguardo cio':.
Con un firewall attivo e configurato opportunamente ( permesso in/out
dei pacchetti per le applicazioni scelte)
ieri avevo una connessione attiva non riportata dal firewall
ma ben visibile con un programmino come NetworkAgent 
(non ricordo la porta) che non ne voleva sapere di "zittirsi" e
continuava a "lavorare".
Escludo la presenza di server.
La cosa mi e' sembrata singolare...e cosi' eccomi qua.
Che ne pensate?
Ciao a tutti.
Pippo

 Escludo la presenza di server.
la presenza di Server dovresti verificarla con un netstat a macchina appena
accesa!
Dici di non ricordare la porta... TCP, UDP?? A noi quella serve!
dai..manda un output dell'accaduto se sei ripresenta..
ciao

Che ne pensate?
Che e' singolare. Qual'e' il firewall che usi?
Lapalissiano
ICQ 57269703

ciao

"Pippo" <Pipp...@wodooslam.slam> ha scritto nel messaggio
news:3933bf96...@news.libero.it...

Beh ....ormai molti troian si attivano solo al momento della connessione
quindi
è spesso inutile fare un netstat appena accendi il PC
Ciao Ciao

 Pensavo che NetworkAgent fosse valido in questo caso....o no?
certo che e' valido. Magari dacci qualche indicazione in piu': potrebbe
benissimo essere una connessione di quelle lecite, cioe' quelle
esplicitamente autorizzate da te stesso. Chesso': una interrogazione al
DNS, una sessione ftp o http, ecc...
ciao
Buttha
-- 
* Per rispondere in email rimuovere una i dall'indirizzo
* 
http://members.xoom.it/buttha/
* Diffondete i messaggi a basso costo

Pensavo che NetworkAgent fosse valido in questo caso....o no?
Certo, come e piu' di netstat!
 Ma nella barra di AtGuard erano segnalate veramente 0 (zero) network
connections?
Per vedere se hai server dimenticati o nascosti fai partire atguard
'a macchina appena accesa' e controlla se il numero di network
connections e' zero... Se cosi' non fosse clicca sopra al numero e
guarda quali porte sono aperte e soprattutto da quali programmi sono
tenute aperte
Lapalissiano
ICQ 57269703

 Pensavo che NetworkAgent fosse valido in questo caso....o no?
Certo che lo è! NA è netstat stesso, ma con i colori :-)
Certo il fatto che tu abbia NA mica ti garantisce la sicurezza! Ti permette
di vedere se ci sono LISTENING e ESTABILISHED sospetti..

non e' possibile
hai ragione, ma temo sia il caso di farsi capire meglio dai newbie.
nessun server installato NON vuol dire nessun SERVER DI BACKDOOR installato.
qualunque server potrebbe esser mal configurato od exploitabile per bachi
interni di programmazione. Basti vedere il mondo UNIX/NT/2000 o qualunque
sistema che offra servizi di rete.
invy

Certo il fatto che tu abbia NA mica ti garantisce la sicurezza! 
chiaro,certo.
Grazie a tutti.
Ciao 
PiPPo

Lo chiedo perche' non lo so'... :-)
beh, da un punto di vista NON ci sono differenze. Quale, chiedi ?
Entrambi offrono un accesso da remoto. Nel caso di una backdoor questo
accesso e', teoricamente, illimitato ed opportunamente, sempre teoricamente,
occultato. Un altro demone invece, quale che sia, offrira' servizi diversi
a seconda delle necessita' del cliente e possibilita' del server.
Da un altro sono ovviamente diversi:
una backdoor avra' magari una password di accesso, ma permette di fare
piu' o meno TUTTO. Un server normale permette solo quello che e' deputato
ad offrire. Ma in questo caso, se mal configurato o mal programmato,
potrebbe permettere un accesso non originalmente preventivato.
Quindi POSSONO, non SONO, essere pericolosi ugualmente.
Come sentenziato da piu' persone, un computer sicuro NON ha accesso ad
una rete, ma solo da consolle [dicevano anche altro :) ma non inerente al
presente thread].
invy

 nome PRIMA di aprire socket ?
basta fare un esperimento: autorizzare icq.exe a fare tutto, poi provare
ad installare una backdoor chiamata icq.exe. Chissa' se viene
considerata, anche, la path.
BTW, questo problema di sicurezza potrebbe essere risolto: mi viene in
mente una chiave privata bella incastonata nel firewall, che firmera' le
applicazioni che coinvolgono le rule.
ciao
Buttha
-- 
* Per rispondere in email rimuovere una i dall'indirizzo
* 
http://members.xoom.it/buttha/
* Sai le risposte a questa domanda?

> Beh ....ormai molti troian si attivano solo al momento della connessione
troian, dici? mmhh.... sarà mica Trojan eh?

nome PRIMA di aprire socket ?
AtGuard semplicemente permette al/nega al/si fotte del programma x,
che ha nomefile y e che risiede nella path z di piazzarsi in ascolto
sulla porta a col protocollo b. Non so che controlli faccia, ma
sembrerebbe essere abbastanza difficile da eludere.

considerata, anche, la path.
Viene considerata anche la path, e, che mi risulti, anche l'header
dell'exe. Pero' qui potrei sbagliarmi :d

 considerata, anche, la path.
<saluto> BUTTHAAAAAAA ciao :)))))) BHU ! </saluto>
ma come non ti ricordi ??? se ne abbiamo parlato a suo tempo... alle 
prime installazioni... :)
@guard lavora sulla path, non sul nome dell'exe.. quindi l'unica 
soluzione sarebbe quella di cancellare fisicamente un prog e sostituirlo 
con il trojan opportunamente rinominato.
Non so se faccia anche un controllino sulla dimensione o un check di 
altro genere sul binario, ma non sarebbe uan cosa cosi' impensabile..
( è da provare.. e io non c'ho molta voglia :) )
per quanto riguarda le conenssioni non segnalate (nel senso rilevate da 
@guard in learning mode) non vorrei dire una frignaccia ma mi pare che 
firewall le rileva solo se attivato prima della connessione stessa. Se 
per caso viene aperto dopo, magari quando si è gia' online... se ne 
frega :)
erGoline

 considerata, anche, la path.
            ^^^^^^^^^^^^^^^^^^^
magari la prossiam volta leggo con attenzione tutto il post.. ok ;))
erGoline

 ( č da provare.. e io non c'ho molta voglia :) )
cmq, una cosa che mi domando e': perche' in linux non si puo'
implementare una cosa simile? Autorizzare determinate applicazioni e'
una cosa molto utile.
ciao
Buttha
-- 
* Per rispondere in email rimuovere una i dall'indirizzo
* 
http://members.xoom.it/buttha/
* Il potere non corrompe molto di piů della sua mancanza. (Roberto Gervasio)

una cosa molto utile.
Non basta metterle come owned da un certo utente, e dare a
quell'utente "fittizio", diciamo cosi', permessi un po' meno
restrittivi di altri?
Oppure ho sparato una stupidaggine?

frega :)
e allora NON e' un vero filtro di pacchetti. Ma dico io, se la rule e'
ESATTA, e blocca connessioni verso la tua porta 31337, non blocca solo
pacchetti con flag SYN, ma TUTTI quelli verso la suddetta porta. Quindi anche
a connessione iniziata. Ma se la gente non scrive rules adeguate perche'
lui controlla i pacchetti o le porte usando il nome del file .........
invy

una cosa molto utile.
1) si PUO' implementare. Controlla le Linux Capabilities [POSIX1.e] nel
   src capability.c nella dir del kernel, e capability.h ...
2) davvero lo vorresti fare ? io lo trovo assurdo.
Vediamo di capirci:
un filtro di pacchetti e' uno dei sistemi con cui si costruisce un firewall.
Il quale, per inciso NON e' un filtro, NON e' un proxy, NON e' un SOCKS, ma
e' una architettura che utilizza sw,hw,design di rete, per proteggere un
sistema. Il fatto che ORA ogni singolo utente lo voglia usare per proteggersi
da BO, DoS e compagnia bella, non vuol dire che pur preferendo il DENY ALL
si debba per forza rendere facile la vita nella stesura delle rulesets
permettendo i nomi invece delle connessioni. Ribadisco, bypassare un nome,
anche con path e dimensioni non trovo sia cosi' difficile in Windows. Se
si e' ottenuto accesso root non lo sara' neanche qui su Linux.
Secondo me, nel campo della sicurezza, la semplicita' vince sulla complessita'.
Un filtro deve usare delle rules. Punto. Basarsi sui parametri della 
connessione, e non sui parametri del file lanciato. Aggiungere layer di
funzionalita' al di sopra di quelle opinabili sui socket, vuol dire aggiungere
nuovi post su BUGTRAQ a fronte di poche innovazioni o comodita'.
Poi lo vuoi implementare ? Fallo. Potra' anche essere utile a chi non riesce
a far convivere ICQ2000 o suo clone con il suo DENY ALL, ma di sicuro non
servira' ad un server di produzione che DEBBA DAVVERO esser protetto da
firewall.
Io ti comprendo quando dici che autorizzare applicazioni e' una cosa
molto utile. Ma considera che praticamente tutte le applicazioni di rete hanno
un pattern di socket facilmente esprimibile via rule, quasi tutte almeno ;P,
ma cmq ci si riesce. potresti ribattermi che permettendo le effimere in qualche
senso, forse permetterai tante altre applicazioni ....
Beh, e' un NON-PROBLEMA. Se sei su Win e sei da solo, considera ad usare il tuo
antivirus per esser sicuro che non siano troyan o altro [non l'ho messo io
nelle FAQ :)))]. Su Linux, root dovra' farlo, e guarda caso, lo dovrebbe
fare anche senza che ci sia un ruleset di cui preoccuparsi. Controllera'
permessi, capabilities per l'esecuzione, blocchera' il bloccabile.
Ovvio che una intrusione a livello piu' alto, possibile, renda vano ogni
accorgimento o quasi. Forse con un controllo criptografico del file in
questione ? Non so, potrebbe andare. Ma credo, che in caso di vera intrusione
seria, un modulo kernel od una .dll mi fregherebbero cmq, no ?  :)
ciao,
invy

dell'exe. Pero' qui potrei sbagliarmi :d
WOW. Intelligentissimo. Direi che oltre ad usare silkrope o similari
per infilare un server nell'.exe CON PATH del tuo ICQ o FTPd, si possono
anche provare tanti altri metodi che quasi non sono contabili.
Se un file non ha permessi o ACL associate nel file system, non ha molto
senso basarsi sul nome e path per essere sicuri che sia lui, no ? E gia'
in quel caso gli faremmo un favore, visto che servirebbe comunque un
qualche hash per verificarne la non compromissione o l'autenticita' ...
Qui siamo nel TIPICO caso di assurdita' del mondo windows. Un filtro di
pacchetti che, PUR DI LEVARE LA DIFFICOLTA' [peraltro non piccola] DI
STESURA DEI RULESETS, decide di prendere il posto stesso dell'utente e
di basarsi sugli occhi, per filtrare o meno, o per permettere il binding
di una porta o meno. Ma d'altronde, Win9x permette il binding anche
delle porte privilegiate a chiunque, e non potrebbe fare altro visto che
non ha veri e proprio id utente.
Questo vale sia per il tuo @guard che permette il binding, sia per l'altro
di cui parla Buttha [se non e' la stessa, ehm, a sto punto, schifezza] per
il filtraggio pacchetti. Se non puoi essere sicuro che un file in un
path sia e faccia quello che dice, non gli si puo' permettere dal solo
nome di bypassare le rules. ASSURDO.
invy


ZoneAlarm fa proprio questi controlli (almeno dimensione e versione
del file): infatti io ho aggiornato il FreeAgent e mi è toccato
ridargli l'autorizzazione come fosse stato un file nuovo (il nome era
uguale: agent.exe).

ASSURDO.
Poco ma sicuro. Tieni pero' presente che si parte dal presupposto che
non ci sia solo il firewall a "difendere" il sistema, ma anche un buon
antivirus aggiornato, e un minimo di intelligenza da parte
dell'utente. Se io dico esplicitamente ad atguard "guarda, lo vedi
quell'exe li? Bene, fagli aprire tali servizi senza preoccuparti di
cosa fa", *so* cosa fa quel programma, e mi fido di lui.
Se poi quel programma e' una backdoor accessibile a tutto il mondo, la
colpa non e' certo di atguard, ma mia che ho autorizzato qualcosa di
cui non ero sicuro del comportamento. Se poi io autorizzo un
programma, e poi eseguo qualche file che va a modificare un programma
di cui ero a conoscenza del comportamento, sono triplamente scemo,
perche' ho eseguito qualcosa di dubbia provenienza, e non sapevo cosa
avrebbe fatto.
Questo discorso vale per *qualunque*
sistema/so/ambiente/firewall/proxy/sostituire con un prog a scelta.

lui controlla i pacchetti o le porte usando il nome del file .........
AtGuard blocca qualunque pacchetto arrivi alla porta "sprangata", a
patto che la connessione non sia gia' attiva, funzionante, e con un
flusso di dati costante quando viene attivato. Visto e considerato che
si attiva automaticamente durante il login al provider, quando non e'
ancora possibile ricevere dati, e' relativamente sicuro. In ogni caso,
fa *cmq* un log delle connessioni che trova gia' aperte all'avvio.
E vale sempre lo stesso discorso: se uno e' utonto (o uidiota, se
preferisci :P), nemmeno il miglior firewall del mondo, configurato nel
migliore dei modi possibile, puo' difenderlo. A meno che non sia un
utente infimo di una macchina *nix configurata bene, ma questo e' un
discorso a parte :)

una cosa molto utile.
E, infatti, "SI PUO' FARE!!!" :-) - in almeno due modi, il piu' sano e'
usando le capabilities.
Leonardo
".signature": bad command or file name

discorso a parte :)
indubbio. ma prima che tu ed io nascessimo gia' lo si sapeva questo.
allora, mi chiedo, perche' peggiorare puntando verso il basso ? se e'
vero che la ridondanza e' uno dei metodi di sicurezza, la ridondanza
di PROBLEMI a margine di features, e' poco edificante in un fw.
Siamo nel solito motto "it's a feature, not a bug" !??!?! ;P
invy

che del sistema operativo in se stante.
beh non intendevo quello. intendevo solo dire che @guard ha una feature
forse ..... magari .... non so ..... interessante. ma male implementata
e pericolosa in un OS monoutente. Poi guarda, il discorso sulla intelligenza
dell'utente e' una astrazione teorica che si utilizza per definire il caso
peggiore che possa capitare. un po' come quando descrivo un attacco come
quello di 20 righe sopra. Il sistema DEVE fare qualcosa a riguardo. NON
puoi assolutamente devolvere il tutto alle sole applicazioni. E' un
approccio FORTEMENTE sbagliato. Progetti come OpenVMS, OpenBSD, Linux
Capabilities, Delta9 in fondo in fondo vogliono dimostrarlo. Windows e'
insicuro in quanto tale, non solo perche' il 95% dei demoni per NT/2000 e'
passibile di remote overflow.
E comunque seguiamo pure il discorso della capacita' ed accortezza.
@guard NON aiuta l'intelligente, badando al solo nomefile+path, figuriamoci
l'utonto. Se guardi la cosa da questo punto di vista assume una connotazione
un pochino fosca, no ? ;)
ciao,
invy

 un pochino fosca, no ? ;)
Io ho @guard. 
Che faccio? Passo a Conseal?
Giusto giusto sono piů sotto i miei due post "tentata intrusione".
Ciao!
-- 
Morfeo, a midnight surfer
*************************
* "In vino veritas" *
* 
http://space.tin.it/io/giaczucc
 *
* Remove "ONLY" from my address to reply *
******************************************

 pacchetti o le porte usando il nome del file .........
hehehehe sottile ironia?
ciao
Buttha
-- 
* Per rispondere in email rimuovere una i dall'indirizzo
* 
http://members.xoom.it/buttha/
* CiocoSnack: Farina tipo 0, uova, cacao, latte, zucchero, nocciole.
  Non disperdere nell'ambiente. (Corrado Guzzanti) 

 cmq, no ? :)
si certo, ma sbaglio o stiamo parlando sul come *evitare* l'intrusione?
:)
hola
Buttha
-- 
* Per rispondere in email rimuovere una i dall'indirizzo
* 
http://members.xoom.it/buttha/
* Noi vogliamo le vostre critiche, vogliamo ascoltare tutto cio' che
  volete dirci: che siano accuse, che siano proteste che siano grida... 
  non abbiate timore... parlate dopo il segnale acustico (C.Guzzanti)

hehehehe sottile ironia?
nooooooooooooo :) , tu dici ?
invy

Giusto giusto sono più sotto i miei due post "tentata intrusione".
mah, qui credo possano esserti d'aiuto maggiormente gli utilizzatori di
windows. cmq il mio discorso e' relativo all'utilizzo della 'feature' di
@guard del creare rules basandosi sul nome dell'applicazione. se non lo
fai non ci sono problemi quali quelli delineati in questo thread.
magari altri, non so, ma non questi :)
invy

si certo, ma sbaglio o stiamo parlando sul come *evitare* l'intrusione?
non necessariamente. una rule sulla 80 attivando solo explorer.exe non mi
aiuta contro una intrusione piu' della sola rule verso 80, no ? :)
gli attacchi contro i client dipendono si dall'accortezza di chi li usa, ma
appena userai un server bacato, che sia attivato solo lui poco importa se
permette di entrare, usare cmd.exe e lanciare tanti bei codicilli che possano
modificare @guard, il suo dbase, le sue rules, i log, le easter eggs di win :P
etc etc etc
invy IMHO

 del file): infatti io ho aggiornato il FreeAgent e mi è toccato
??????? C'e' una nuova versione di Free Agent? Io sapevo che era stato
"quasi dismesso"...
Max che va subito al sito.
-- 
Attenzione: questo messaggio ti e' arrivato dalla rete e
in qualche modo si e' insinuato nel tuo hard disk...
SecurFaq             : 
http://members.xoom.com/gouldukat/
Biancorossi Siamo Noi: 
http://www.tifonet.it/free/ancona/

Che faccio? Passo a Conseal?
Conseal e' molto piu' versatile di atguard, ma ha anche altri problemi
legati alla configurazione (non esattamente facile ai poco esperti, si
rischia di avere un sistema molto piu' aperto di quanto si voglia.
Inoltre atguard ha anche le funzioni di ad washing che personalmente
amo :D

"quasi dismesso"...
Io avevo la 1.11 e adesso ho la 1.21
In che senso dismesso? Sul loro sito, 
www.forteinc.com
 , c'è ancora.

 per netcat ? O chiudiamo @guard ? E se volessi provare altri browser ? :)
Se non ho capito male, in sintesi dici che avere un firewall che dà
autorizzazioni alle singole applicazioni, può generare più senso di
falsa sicurezza o generare un buco rispetto ad un firewall che si
limitasse solo a bloccare o meno le singole porte (senza curarsi di
chi le chiede).
Però, penso che intanto nulla vieta che un fw del tipo @guard possa
comunque essere usato come un fw del secondo tipo, limitandosi a
concedere o meno il permesso sulle porte singole, quindi la
possibilità di usarlo nell'altro modo è una feature in più che non
limita l'altra; poi è evidente che se uno ha dato un permesso ad
un'applicazione di aprire una porta http, sa di correre il rischio che
anche qualcun altro ne possa approfittare (ogni riferimento ad Aureate
non è certo casuale). Tuttavia, una backdoor che voglia nascondere i
suoi tentativi di connessione, se trova un firewall come @guard che di
default non gli concede nulla e ha autorizzato solo browser.exe ad
usare http, perlomeno la fatica di camuffarsi da browser, o di
compromettere in qualche modo il fw o l'integrità del sistema, la deve
fare - mentre se si trova un fw che spalanca la 80 a tutti altrimenti
non si può browsare su Internet, si risparmia pure questa fatica.
Per esempio, io potei scoprire che il Comet Cursor tentava connessioni
non autorizzate alla porta 80 di un server di nome '
host1.net
', per
finalità di inviare dati probabilmente. Se non fosse stato per @guard,
che aveva autorizzato SOLO Internet Explorer, e non tutti, ad usare la
80, la cosa poteva passare tranquillamente inosservata.
E' chiaro che se si parla di sistema operativo monoutente cui la
sicurezza è lasciata in mano solo alle applicazioni, è un altro
discorso, e tutti sono concordi nel dire che comunque il solo fatto
che tutti possano fare tutto è già un buco di sicurezza in sé.
Bye Krmel
Microsoft Outlook Express: cosa vuoi postare postare postare postare oggi?

che tutti possano fare tutto è già un buco di sicurezza in sé.
gia'. ed infatti un exploit remoto che fornisse un cmd.exe o che nello
shellcode stesso modificasse il registro per quanto riguarda @guard e
patchasse il binario ..... :)
 
invy
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GSS/TW/O>AT d?(dx) s+:+, s: a-->a- C++(C+++) UL+++>UL++++ P+ L+++>L++++
E-- W(W-) N++ K? w-- O- M- V- PS++ PE Y+ PGP++ t++@ 5 X+ R+(R++) tv b+++
DI+++@ D+ G>G++ e++ h r+(r-) y++*
------END GEEK CODE BLOCK------

 In che senso dismesso? Sul loro sito, 
www.forteinc.com
 , c'è ancora.
Si, diverso tempo fa avevo letto su qualche ng che Forte' era stata
acquisita da non so chi e che la sua offerta avrebbe subito un
evoluzione, infatti molti erano preoccupati per il possibile abbandono
di (Free) Agent. La cosa non e' avvenuta, non puo' farmi che piacere.
Max IN FINALE!!!!!
