View Full Version : Firewall: come si vede se il sistema e' compromesso?
Ciao a tutti!
Ormai da un paio di giorni sto giocando con Debian Sarge e mi piace sempre di piu'. Solo oggi, pero', ho installato ed avviato il firewall (Firestarter, anche se credo sia solo un front-end grafico ad iptables, vero?). Comunque solo ora mi rendo conto della miriade di tentativi di connessione provenienti dall'esterno, in particolare del tipo:
Microsoft-ds
Samba (SMB)
DCOM-scm
eDonkey
Webadmin
eccetera.
Poiche' solo da oggi il mio firewall e' in funzione e poiche', suppongo, che tali tentativi si siano verificati anche nei giorni precedenti, c'e' modo di capire se ho subito qualche danno? Quali sono i file di log piu' importanti da consultare?
Inoltre, cercando in giro, ho visto che connessioni del tipo Microsoft-ds possono essere dovuti ad altri computer infettati da virus quali Sasser, quindi posso non preoccuparmi piu' di tanto? :stordita:
Riguardo invece a richieste Samba, come devo comportarmi? Io non ho nessun server Samba attivo, ma se lo avessi e lo impostassi come visibile soltanto alla rete locale ci sarebbero problemi? Stesso discorso per server NFS?
Altri servizi attivi al momento non ne ho, e non uso software per il p2p, quindi i tentativi di connessione da parte di client eDonkey e simili non dovrebbero comunque ricevere risposta, anche senza firewall, giusto?
Le voci che non capisco riguardano sia le connessioni Webadmin che DCOM-scm; che roba e'?
Grazie :)
PS: sto cercando una buona guida alla configurazione del firewall; devo cercare relativamente a Firestarter o iptables?
EDIT: per ora ho trovato questo (http://www.commedia.it/ccontavalli/docs-it/iptables/iptables4dummies/iptables4dummies.html), ma e' un po' datato e si riferisce al kernel 2.4
PS: sto cercando una buona guida alla configurazione del firewall; devo cercare relativamente a Firestarter o iptables?
EDIT: per ora ho trovato questo (http://www.commedia.it/ccontavalli/docs-it/iptables/iptables4dummies/iptables4dummies.html), ma e' un po' datato e si riferisce al kernel 2.4
Io sto usando firehol e mi trovo abbastanza bene. In pratica è uno script molto "umano" che poi traduce in istruzioni per iptables.
Mi sembra anche ben documentato: http://firehol.sourceforge.net
Io sto usando firehol e mi trovo abbastanza bene. In pratica è uno script molto "umano" che poi traduce in istruzioni per iptables.
Mi sembra anche ben documentato: http://firehol.sourceforge.net
Grazie, gli daro' sicuramente un'occhiata. :)
Per ora, pero', ho cambiato la configurazione di Firestarter, passando da "Permessive by default, black list traffic" a "Restrictive by default, whilte list traffic", ed abilitando i protocolli HTTP, POP3, FTP, SMTP e relative porte per chiunque. Solo non capisco una cosa: la porta 80 (relativamente al protocollo HTTP) non si dovrebbe riferire al server? Cioe', sono io che mi collego alla porta 80 di un server web per accedere ad una pagina, mentre il mio browser puo' utilizzare la porta che vuole per farlo. Almeno io sapevo che funzionava cosi'... :stordita:
Quindi, aprire la mia porta 80 mi sembra significhi che posso accettare connessioni a tale porta provenienti dall'esterno, ad esempio se sul mio computer faccio partire il server web.
Pero' se non mi apro la porta 80 non posso connettermi a nessun sito, quindi immagino che nel mio ragionamento ci sia qualcosa di sbagliato.
Credo che l'errore stia nel verso del traffico:
1) se hai un server web da mettere a disposizione di tutti, devi aprire la porta in ingresso
2) se vuoi collegarti a un server web esterno (standard, sulla 80) devi aprire la porta in uscita
3) se vuoi fare entrambi, ovviamente devi fare 1) e 2)
Credo che l'errore stia nel verso del traffico:
1) se hai un server web da mettere a disposizione di tutti, devi aprire la porta in ingresso
2) se vuoi collegarti a un server web esterno (standard, sulla 80) devi aprire la porta in uscita
3) se vuoi fare entrambi, ovviamente devi fare 1) e 2)
Si, hai ragione; in effetti quelle che ho descritto sono le scelte relative al traffico in uscita :)
In entrata non ho definito alcuna politica, quindi nessuna porta dovrebbe essere accessibile dall'esterno.
Mi rimane il dubbio su quello che puo' essere eventualmente successo nei giorni in cui il firewall non era attivo. Chissa' :confused:
Che nessuna porta sia raggiungibile dall'esterno non è detto, altrimenti tu stesso non potresti usare la rete, probabilmente la tua configurazione attuale permette traffico in entrata solo se legato a connessioni richieste o gia stabilite, ad eccezzione dell'FTP (e spero solo quello) che è un po più complicato.
Comunque, se vuoi avere un'idea migliore su come è configurato il tuo firewall evita front-end e usa iptables da shell, sicuramente non è amichevole, ma una volta che lo capisci (e non ci vuole molto) non ha rivali (a mio parere).
Per quanto riguarda i demoni (samba e NFS) impostali in modo da accettare connessioni solo dall'interno E configura iptables in modo che garantisca questa politica. (Ovviamente se ti servono altrimenti non installarli)
Per i log vedi in /var/log, se ti interessa chi s'è connesso a samba guarda il file di samba etc etc etc
Comunque, se vuoi avere un'idea migliore su come è configurato il tuo firewall evita front-end e usa iptables da shell, sicuramente non è amichevole, ma una volta che lo capisci (e non ci vuole molto) non ha rivali (a mio parere).
Sul fatto che non ci voglia molto, ho un po' di dubbi... sul resto sono molto d'accordo.
Non ci vuole molto per delle regole del tipo: blocca tutto, accetta solo questo in ingresso e quest'altro in uscita, ma per avere qualcosa di più comincia a diventare impegnativo.
Probabilmente intendiamo il tempo in modo diverso (detta cosi pare da rompi****ni ;P)
Per impostare le policy generali e mettere 2 regole non ci vuole nulla. Ovvio che in confronto ad avere una cosa gia fatta ci vuole un'infinità di tempo, d'altro canto mica devi impostare una dmz con diverse lan interne, per quello sarei d'accordo con te nel dire che dovresti buttare una cifra di tempo, ma anche in quel caso più per studiare i protocolli che per capire come funziona iptables.
Non ho detto che iptables è amichevole, ho detto che se ci mettiamo di impegno non serve molto a capire come funziona, una giornata penso basti per capire le cose che servono a una rete domestica (ovviamente a patto di non essere nuovi di linux), ma se vogliamo sapere cosa fa iptables non vedo modo migliore di usare la shell (visto che almeno noi linuxiano possiamo farlo ;)
Non ho detto che iptables è amichevole, ho detto che se ci mettiamo di impegno non serve molto a capire come funziona, una giornata penso basti per capire le cose che servono a una rete domestica
Proprio perche' nel mio caso si tratta di rete domestica, non e' sufficiente adottare la politica che ho scelto? Cioe' tutti i servizi e le porte bloccate sull'interfaccia che si connette ad Internet (il modem, nel mio caso) tranne quelle essenziali per l'uso comune (web, posta e client ftp) ed invece nessuna protezione sull'interfaccia di rete locale, a cui collego al piu' qualche client per condividere files e roba varia. Una politica abbastanza spartana, insomma... :rolleyes:
Sisi, va piu che bene e ti ritrovi comunque con una protezione superiore alla stragrande maggioranza dell'utenza (purtroppo persino di alcune reti aziendali), nel leggere il post avevo pensato tu volessi saperne di più sulla configurazione :)
un buon front end grafico per iptables è anche guarddog
un sistema è compromesso quando i dati buoni fuggono via e i dati cattivi che dovrebbero non esserci si intrufolano dentro. :D :cool: :cool: :D :D :rolleyes: :muro:
nel leggere il post avevo pensato tu volessi saperne di più sulla configurazione :)
Beh, i dettagli me li guardero' in seguito; il thread l'ho aperto perche' quando ho installato Debian non mi ero accorto che il firewall non era attivo, e visto che quei tentativi di connessione sono cosi' frequenti volevo sapere se erano dannosi per sistemi GNU/Linux non protetti :confused:
Fino ad ora non mi ero posto il problema perche' su SuSE e Fedora (le distro che uso maggiormente) ti viene chiesto se vuoi attivare il firewall gia' in fase di installazione.
un buon front end grafico per iptables è anche guarddog
Se non sbaglio Guarddog e' per KDE, vero? Al momento su Debian uso solo GNOME perche' voglio imparare ad usarlo meglio :)
A proposito, senza che apro un nuovo thread ( :p ), come si creano i link sul desktop in GNOME? Se faccio click destro, non compare l'opzione "Crea collegamento" :stordita:
:asd:
:(
Comunque grazie per tutti i chiarimenti :)
Io ho messo come firewall Firehol, solo che sto cercando di capire come utilizzarlo e come impostarlo,prima di renderlo attivo.
Io ho messo come firewall Firehol, solo che sto cercando di capire come utilizzarlo e come impostarlo,prima di renderlo attivo.
Lo sto usando anch'io e mi sembra un ottimo prodotto: con una decina di righe si genera circa 170 regole di iptables ;)
Non sono sicuro di avere fatto un buon lavoro (ma credo abbastanza); lo script devo ancora metterlo sul server, per ora lo testo con QEMU e ha resistito bene a nessus.
Se hai qualche dubbio, magari posso dirti qualcosa per quel che ne ho capito ;)
PS: firehol è solo un intermediario, il firewall resta iptables
PS2: a mio avviso un gran vantaggio di firehol è che cancella e sostituisce le regole di iptables. Da quello che ho notato, se si avvia iptables troppo presto (ad es. prima della rete), iptables non viene avviato :(
E' un peccato, perché c'è quell'attimo che rischia di essere scoperto il server (tra l'avvio della rete e quello del firewall). Se il problema dell'impossibilità di avviare iptable prima della rete, fosse dovuto ad alcune regole che cercano di risolvere i nomi (e non ci riescono), usando firehol si potrebbe mettere regole strettissime in iptables (tipo un drop completo, al limite con l'eccezione dell'ip di amminisrazione) e quando tutti i servizi sono su avviare firehol che applica delle regole ad hoc e meno drastiche (probabilmente lo si può fare anche con due diversi set di regole di iptable e 2 scriptini che avviano due volte il servizio con le differenti regole)
Da quello che ho notato, se si avvia iptables troppo presto (ad es. prima della rete), iptables non viene avviato :(
E' un peccato, perché c'è quell'attimo che rischia di essere scoperto il server (tra l'avvio della rete e quello del firewall).
Generalmente è meglio evitare di mettere regole con parti da risolvere, e comunque, se iptables non riesce ad accedere alla rete stai sicuro che non ci riesce nessun altro.
Buona l'idea di avviare iptables in 2 fasi, ma attenzione, alcuni servizi potrebbero richiedere una connessione al loro avvio, se la chiudiamo rischiamo che questi rimangono in attesa.
(probabilmente lo si può fare anche con due diversi set di regole di iptable e 2 scriptini che avviano due volte il servizio con le differenti regole)
Si, si può fare benissimo, torniamo al solito discorso, meglio usare iptables o meglio imparare un front-end che ci allontana dal suo funzionamento? (Fino addirittura a dare l'impressione che siano firewall diversi) Personalmente uso solo iptables, anche in situazioni con centinaia di regole, mi piace sapere esattamente cosa fa e impostralo come volgio io, inoltre (non ne son sicuro) non credo che i front end coprano tutte le opzioni che mette a disposizione iptables.
Penso che i front-end vadano bene all'inizio, se abbiamo bisogno di qualcosa di veloce in situazioni non critiche e non abbiamo voglia di girare senza firewall fino a che ne capiamo il funzionamento. Sostituirlo completamente ai comandi da shell... bho, io non lo farei.
Generalmente è meglio evitare di mettere regole con parti da risolvere, e comunque, se iptables non riesce ad accedere alla rete stai sicuro che non ci riesce nessun altro.
Hai ragione, ma se devo usare servizi di una terza parte che implementa, ad es., un qualche sistema di distribuzione del carico tra più server facendo vedere all'esterno solo un nome, non ho alternativa ;)
Buona l'idea di avviare iptables in 2 fasi, ma attenzione, alcuni servizi potrebbero richiedere una connessione al loro avvio, se la chiudiamo rischiamo che questi rimangono in attesa.
Hai fatto bene a darmi una sveglia: diciamo un drop completo sull'attività di rete in ingresso e uscita dal server e non in localhost
Si, si può fare benissimo, torniamo al solito discorso, meglio usare iptables o meglio imparare un front-end che ci allontana dal suo funzionamento? (Fino addirittura a dare l'impressione che siano firewall diversi) Personalmente uso solo iptables, anche in situazioni con centinaia di regole, mi piace sapere esattamente cosa fa e impostralo come volgio io, inoltre (non ne son sicuro) non credo che i front end coprano tutte le opzioni che mette a disposizione iptables.
Penso che i front-end vadano bene all'inizio, se abbiamo bisogno di qualcosa di veloce in situazioni non critiche e non abbiamo voglia di girare senza firewall fino a che ne capiamo il funzionamento. Sostituirlo completamente ai comandi da shell... bho, io non lo farei.
Il bello di FireHol è che non si sostituisce a iptables, ma mette a disposizione tutta una serire di regole di base per iptables, anche contro il DoS, alle quali aggiunge quelle che imposti con un meta linguaggio.
In più non ti vieta di aggiungere manualmente regole aggiuntive scritte esattamente con la sintassi di iptables.
Non è una brutta cosa ;)
Certo, le eccezzioni ci sono l'importante è non abusarne...
Concordo, sono strumenti utili :)
Certo, le eccezzioni ci sono l'importante è non abusarne...
Concordo, sono strumenti utili :)
Anche eccezZioni è un'eccezione ;) :p
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.