Newsgroup: it.comp.os.linux.sys
Titolo: [SICUREZZA] Attivare IPTABLES o no?

Ciao, sto mettendo on-line un servizio che potrebbe
essere bersaglio di spammer o comunque soggetti
"fantasiosi" che potrebbero aver voglia di buttarlo giů ...
Di solito la mia politica č disattivare tutti i servizi che non uso
e quindi lasciare aperte solo le porte indispensabili; naturalmente
tenendo sempre tutto patchato.
( e fino ad ora si č rivelata sufficiente )
Dalle vostre esperienze, cosa mi consigliate... attivo anche Iptables
magari con qualche filtro ICMP. ( non sono un esperto di Iptables )...
Mi consigliereste alcune regole che ritenete "utili" per evitare attacchi
DOS,
FLOOD etc...o su Linux non servono?
I servizi attivi sono:
Apache
Mysql
PostgreSql
SSH
Qmail
Vpopmail
Clamd
Spamd
Grazie mille in anticipo
                                        -- Yena --

 wrote in
news:STlSc.125204$
5D1.6...@news4.tin.it
: 

premesso che i server sql, spam e clam li lascerei in ascolto solo su
localhost, io attiverei comunque iptables. 
tutto in drop, o al massimo reject, tranne quelle tre porte che t
servono per fornire servizi all'esterno. 
icmp?
uozzdis??
DROP!
:-)
-- 
+-------
| Paolo opg
|
| janickg ( at ) hotmail ( dot ) com
| (fake address in reply-to field!)
+-------

 servono per fornire servizi all'esterno. 
In drop, non in reject.
Max

 Spamd
binda spamd, clamd, postgresql e mysql solo su lo, se non devi accederci
da altri computer.
Gli altri filtrini su icmp imho servono a poco e possono solo causare
malfunzionamenti. Tanto se uno ti floodda ti satura comunque il link,
visto che scarti i pacchetti a valle e non a monte del collegamento.

 In drop, non in reject.
non credo proprio, ma se ne è già discusso.
-- 
cat: .signature: No such file or directory

 visto che scarti i pacchetti a valle e non a monte del collegamento.
E' quello che pensavo anche io sui filtri icmp :-)
                                            -- Yena --

 wrote in news:h30b87es6lyx$.tq7aktys2jiz
$.
d...@40tude.net
:

ecchevvordě??
io intendevo che metterei tutto in drop, nonostante sia 'poco pulito'.
al massimo, se proprio, mettere il tutto in reject, ma imho, č un'impiego 
poco oculato della mia (costosa) banda.
soprattutto in caso di flood: giŕ mi saturano il link in down, se poi gli 
rispondo, mi saturo da solo il link in up...


 non credo proprio, ma se ne è già discusso.
Si vabbè non è da RFC ed è vero che lo abbiamo già accennato.
Ci sono però dei tipo di DOS che utilizzano anche l'amplificazione e le
risposte per farti sedere ua macchina. E non è bello.
Personalmente, quello ce non uso lo metto in DROP, talvolta uso pure il
tarpit (ancora più fuori RFC).
L'unica cosa che (in alcuni casi) è buona norma tenere in reject è identd
(113/tcp) che potrebbe causare deirallentamenti in alcune situazioni.
Per evitare altre cosette e rendere il sistema leggermente più sicuro e
nascosto:
echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts (per le smurf
amplifications)
echo 1 > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
IMPORTANTE invece accettare -p icmp --icmp-type destination-unreachable che
non vanno droppati, cos' come i -p icmp --icmp-type time-exceeded.
Questo IMHO e fuori RFC, come abbiamo già detto...
Max 

 rispondo, mi saturo da solo il link in up...
esatto... senza considerare che in caso di dos (o flood chiamali come vuoi)
gli ip sono spoofati quindi mandi le risposte a chi non le ha richieste.
Altre volte invece rispondi direttamente a delle macchine cinesi che se
potessi spegnerei completamente... I cinesi come fonte di spam e dos sono
incredibili. Hanno più macchine bucate loro della server farm di microsoft.
Max

 tarpit (ancora più fuori RFC).
sisi, ok.. le uso anche io. Per citare altro thread, era una obiezione
all'assoluto "In drop, non in reject", e non alla soluzione in sè.
Ci sono pro e contro di entrambe le cose, anche lasciando perdere il
pedissequo dispetto delle RFC.
Come detto, se ne è parlato parecchio in varie occasioni, e non mi pare
sia il caso di riprendere il tutto di nuovo.
L'importante non è tanto cosa si fa, ma esser sicuri di averne presenti
le implicazioni.
Hola.
