Newsgroup: it.comp.os.linux.sys
Titolo: paranoid firewall!

ciao mi stavo accingendo a configurare il firewall per un serverino
web. Utilizza ancora il kernel 2.2 quindi dovrei usare ipchains.
In breve, con questa macchina deve essere possibile interagire con il
web (ovviamente) e ci si deve poter accedere con ssh. La macchina ha
un'unica interfaccia eth0.
Mi sono studiato un pochino gli script di MrShark, molto bello a dire
la verita', ma il mio approccio voleva essere molto piu' KISS,
eheheh!!!
per cui, accingendo a piene mani da quello script, vorrei sottoporvi
tutti i miei dubbi.
In breve, quello che mi interessa configurare e':
1) accessi al DNS
2) ICMP
3) accesso al server WEB
4) accesso tramite ssh
5) _quando_ richiesto, cioe' quanto si e' loggati dentro al server con
ssh, deve essere possibile utilizzare web e ftp DA quella macchina,
per scaricare patch o nuovi programmi insomma.
la cosa importante e' che deve assolutamente essere evitata qualsiasi
forma di connessione non autorizzata, proprio per lo spirito paranoico
della sicurezza, insomma non vorrei che un troiano che gira sulla
macchina potesse connettersi ad un sever remoto in qualche tipo di
strano protocollo e mandare le informazioni del mio database (???).
Per cui iniziamo. Io ci metterei un bel:
ipchains -F
ipchains -X
in modo da cancellare tutto il possibile.
ora, come settare le policy di default? MrShark mette a DENY solo
l'input ed aggiunge una regola per far passare tutto il traffico
locale:
ipchains -P input DENY
ipchains -A input -i lo -j ACCEPT
ora: non sono esperto di firewall, per cui vi chiedo: avrebbe invece
senso, sarebbe piu' o meno sicuro il fatto di mettere tutte le catene
di default a DENY e creare una o piu' catene personalizzate con le
regole per i servizi che servono a me??? Questo e' un
bell'interrogativo a cui non so dare risposta, ci ho pensato fino alle
tre stanotte.
Poi ci sono le regole per appunto far passare i miei servizi.
Tralascio la parte per abilitare tutti i meccanismi di protezione TCP
SYN Cookie, Always Defragging, Broadcast Echo, etc etc etc per
questioni di brevita'.
DNS: so che il traffico DNS viaggia su UDP e in certi casi TCP sempre
sulla porta 53. Io voglio che sia possibile contattare solo il mio
server DNS (esterno ma in rete locale) in modo resolv.conf, non so se
valga la pena montare un caching ns locale. A proposito, per
un'attivita' di web server il dns e' molto usato o no? Avrebbe senso
mettere un caching locale? Se ogni accesso fosse risolto inversamente
avrebbe un buon impatto sulle prestazioni a questo punto, dato che la
stessa persona farebbe decine e decine di accessi http durante una
sessione...
In ogni caso:
ipchains -A input -p tcp ! -y -s [ip server dns] 53 -d [ip eth0]
1024:65535 -j ACCEPT
ipchains -A input -p udp -s [ip server dns] 53 -d [ip eth0] 1024:65535
-j ACCEPT
queste regole valgono dato che ho output in ACCEPT e devo solo
accettare i pacchetti in entrata. Se avessi voluto chiudere tutto
probabilmente questo non sarebbe stato sufficiente...
Non capisco pero' il '! -y' nella prima riga. Perche'...????
Ora ICMP:
giustamente MrSharky lascia passare solo i tipi 0 (echo reply, in modo
da poter pingare dalla macchina), 3 e 11 (necessari per il buon
funzionamento), lasciando fuori gli echo request.
ipchains -A input -p icmp 0 -d [ip eth0] -j ACCEPT
ipchains -A input -p icmp 3 -d [ip eth0] -j ACCEPT
ipchains -A input -p icmp 11 -d [ip eth0] -j ACCEPT
nota: se tralasciassi anche il -d [ip eth0] funzionerebbe tutto lo
stesso? sapete non vorrei trovarmi nel caso in cui inserissero una
nuova scheda di rete nel server, tutto il traffico si spostasse su
eth1, che risulterebbe sprovvista di firewall. Allo stesso modo ho
tolto il -s 0/0 perche' ipchaind dovrebbe usarlo come default
(giusto?)
Ora si tratta di permettere alla gente di usare il mio server web e la
ssh: eheheh ho vergogna a mettere la mia soluzione perche' sono
proprio agli inizi ed ho paura di sbagliare. Mi dareste un aiutino? Il
server web deve poter anche fare https...
Infine, in uno script di riserva, inserisco la possibilita' di
permettere o no il funzionamento dei servizi di ftp e http _come
client_:
-A input -p tcp ! -y 80 -d [ip eth0] 1024:65535 -j ACCEPT
-A input -p tcp ! -y 443 -d [ip eth0] 1024:65535 -j ACCEPT
ipchains -A input -p tcp ! -y --source-port 21 -d [ip eth0] 1024:65535
-j ACCEPT
ipchains -A input -p tcp ! -y --source-port 20 -d [ip eth0] 1024:65535
-j ACCEPT
la regola del "passive mode" mi pare uno sfracello... a questo punto
lascio tutto aperto...
beh la prossima volta me la dovro' vedere con i log. Per ora un
sentito grazie a chiunque si prendera' la briga di darmi delle
indicazioni!!!
ciao
as



locale:
Per quel che ho letto io, è meglio REJECT di DENY. Questo perché DENY fa
"cadere" tutti i pacchetti in arrivo senza dare notizia a chi tenta di
accedere, il risultato è che questo resta collegato in attesa di una
eventuale risposta (che non arriverà mai) fino al timeout, però intanto
continua a caricare il kernel perché tiene una porta impegnata in waiting.
REJECT invia un segnale di rifiuto, e sgancia immediatamente il tentativo
di connessione, col risultato di liberare prima la porta e caricare meno
il sistema con connessioni in attesa.
Poi magari è una interpretazione mia, ma avevo trovato un discorso di
questo tipo su qualche documentazione (adesso non ricordo quale, però: ma
non è tutta farina del mio sacco!)
-- 
Crononauta               
==========               | togli 'sse' da ulissebarra | 
ICQ UIN: 4005815         | per rispondermi in  e-mail | 
IDAnet: 
http://adcserver1.biodip.unimi.it/ida/index.htm
GP Legends: 
http://www.multiplayer.it/driving/

mmmmmhhh, da quello che dici non hai tutti i torti..... pero' mettendo
un REJECT spechi ulteriore banda in upstream per spedire il pacchetto
di reject, ... con DENY no ....
...se qualcuno ha qualcosa da aggiungere e' ben accetto....
ciao,
Riccardo
----------------------------------------------------------
Riccardo
www.netcat.it
           -> Internet services
www.netcat.it/ferrari/
  -> La Ferrari e la F1
----------------------------------------------------------

 ...se qualcuno ha qualcosa da aggiungere e' ben accetto....
A parte il problema di banda (in ogni caso non trscurabile) con DENY il
rompiballe non ha idea se effettivamente dall'altra parte vi è qualcuno,
con REJECT viene avvertito che qualcosa c'è e potrebbe insistere a cercare
accessi al sistema.
.... anch'io rimango in attesa di ulteriori info.
Ciao
Antonioq
______________________________________________
!!!! attenzione: campo From alterato !!!!
----------------------------------------------
Antonio Madesani 
madesani(at)
versilia.toscana.it
amadesani(at)
galactica.it
----------------------------------------------

accessi al sistema.
Con deny ha la stessa idea che c'č qualcuno che con reject, perché se
provi un accesso a un host inesistente, non ti agganci e trovi un
messaggio di "no route to host", se invece resti agganciato senza che
succeda niente hai invece giŕ capito che lě un host c'č ed č configurato
in deny...



La manpage dice che la differenza tra i due e` _soltanto_ questo che hai
detto tu. Quindi non dovrebbero esserci altre controindicazioni a usare
deny/drop.
-- 
    Pardo 
 
www.pardo.cjb.net