Newsgroup: it.comp.os.linux.sys
Titolo: Domanda su iptables

Ciao a tutti,
in questi giorni stavo studiano iptables e i primi risultati e i primi
divertimenti sono arrivati.
Ora ho un piccolo problema, io su di un server ho imposta le seguenti
regole:
iptables -A INPUT -s xxx.xxx.xxx.xxx -j ACCEPT
iptables -A INPUT -s yyy.yyy.yyy.yy -j ACCEPT
iptables -A INPUT -s zzz.zzz.zzz.zzz/
255.255.255.0
 -j ACCEPT
iptables -A INPUT -p tcp -j LOG --log-level 6
La policy per l'INPUT è DROP
OK tutto funziona regorarlmente, inoltre ho impostato delle regole di
port-forwaring, ma per il problema che vi pongo non dovrebbe ecessario
che allunghi il mio post.
Adesso vorrei che qualunque indirizzo esterno possa connettere una
precisa porta (in questo caso ssh)
Allora io ho fatto così:
iptables -I INPUT 1 -s 
0.0.0.0/0
 -p 22 -j ACCEPT
Ma non funziona, non riesco ad accedere alla porta ssh...  Ho provato
anche con altre sintassi... ma niente!
Vi ringrazio.
Mr. Deckard

 iptables -I INPUT 1 -s 
0.0.0.0/0
 -p 22 -j ACCEPT
jesus, --dport, -p e` il protocollo

 > Allora io ho fatto così:


 iptables -I INPUT 1 -s 
0.0.0.0/0
 -p 22 -j ACCEPT
Dalla man page di iptables(8):
-p, --protocol [!] protocol
     The protocol of the rule or of the packet to check. The specified
     protocol can be one of tcp, udp, icmp, or all, or it can be a
     numeric value, representing one of these protocols or a different
     one. A protocol name from /etc/protocols is also allowed. A "!"
     argument before the protocol inverts the test. The  number
     zero is equivalent to all. Protocol all will match with all
     protocols and is taken as default when this option is omitted.
Quindi -p 22 significa
	lucav@batucagnaz:~$ grep 22 /etc/protocols
	xns-idp 22      XNS-IDP         # Xerox NS IDP
	lucav@batucagnaz:~$
che non è certo ssh.
Prova con un
	iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT
Per tutte le info, come al solito
	man 8 iptables
P.S.: mettere la policy a drop è pericoloso, perché un iptables -F 
cancella tutte le regole di tutte le catene, ma *non* modifica la policy 
di default. Siccome prima o poi un iptables -F scappa, ti tagli fuori 
completamente dalla macchina e devi andare in console. Se hai il server 
vicino, poco male, ma se ce l'hai in server farm a 200 o 300 kilometri 
di distanza è tutto diverso...
Piuttosto lasciala ad accept e chiudi la serie di regole con un
	iptables -A INPUT -j REJECT
P.P.S: abilita qualcosa di icmp, altrimenti non fai più test e generi 
malfunzionamenti, consiglio almeno echo request, echo reply, ttl 
exceeded, destination unreachable.
P.P.P.S: magari abilita anche ESTABLISHED e RELATED, altrimenti sono 
guai pure li.
-- 
Luca Villani            Mobile Team, Dada S.p.A.
                         Remove "+settanta" in address for e-mail replies
GPG key fingerprint: 7FC9 E2FE 0BEE 9DF8 1719  8761 1B79 82CC F0B5 B7CF

Grazie Luca,
ecco adesso funziona, in realtà avevo provato oggi, ma collegandomi
con putty sembrava non funzionasse...
Gazie per molte delucidazioni in più che mi hai offerto...
In realtà queste semplici regole vorrei impostarre su di una macchina
che dovrebbe fungere da unica macchina riconosciuta come amica da altri
server di produzione (sui quali ci sono delle regole molto più
ristrettive). E questa deve solo accettare richieste ssh, magari poi
sposterò la porta da quella di default a non standard.
Il fatto di aver messo a DROP la policy era dovuta la fatto che, oltra
alla mia non perfetta conoscenza delle materia, di evitare eventuali
dimenticanze nelle politiche.
REJECT dice che se nessuna regola è stata trovata rifiuta la
richiesta, giusto?
Per "ESTABLISHED e RELATED, " ancora ignoro il loro funzionamento.
Ti ringrazio molto...
Mr. Deckard


 iptables -A INPUT -p tcp -j LOG --log-level 6
Ottimo modo per autodossarsi!

Scusa ma non ho capito cosa intendi?
Grazie


> Ottimo modo per autodossarsi!
Hai la policy in drop. Per me ottimo.
Hai quella regola. Per me chiavica.
Ogni pacchetto che passa da li viene loggato.
Ci vogliono 3 secondi per saturarti l'HD con i log.
Usa -m limit se proprio vuoi usare quella regola (imho inutile perchč
andrebbe ristretta a ciň cheč NEW).
E userei anche la stateful inspection.
Max

 andrebbe ristretta a ciò cheè NEW).


 anche con altre sintassi... ma niente!
/usr/sbin/iptables -t filter -A INPUT -p tcp --dport ssh -j ACCEPT
-- 
Claudio
gc...@despammed.com

 E' giusto quello che dico?
Secondo me e' il contrario, se al mio SYN rispondi con un RST posso 
pensare che non ci sia nessun servizio in ascolto su quella porta, se 
droppi il pacchetto e non rispondi nulla comincio a pensare che ci sia 
un firewall che... ha droppato il pacchetto!
Con questo non voglio dire che il DROP sia male, personalmente lo uso 
anch'io.
ciao,
-- 
Claudio
gc...@despammed.com

 un firewall che... ha droppato il pacchetto!
peccato che ne' drop ne' reject rispondano con un rst

 peccato che ne' drop ne' reject rispondano con un rst
drop scarta il pacchetto e non risponde con nulla, in effetti la 
risposta di default di REJECT e' icmp-port-unreachable, ero convinto che 
il deault fosse rst.
Rimane il fatto IMHO che un pacchetto droppato fa supporre un firewal, 
mentre un reject magari configurato con --reject-with tcp-reset fa 
supporre semplicemente che non ci sia un servizio in ascolto sulla porta
...sto dicendo cazzate?
-- 
Claudio
gc...@despammed.com

 ...sto dicendo cazzate?
In teoria (non ho approfondito) se droppi il pacchetto, dall'altra parte
possono pensare anche che non ci sia un server in ascolto, mentre con
REJECT sanno che c'e` ma e` filtrato.
Se fanno un portscan vedono altre porte aperte, ma potrebbe essere un
firewall configurato per girare solo certe porte a server interni.
Bye.

 iptables -I INPUT 1 -s 
0.0.0.0/0
 --dport 22 -j ACCEPT
Se gli dai una porta devi specificare il protocollo. Ci sono protocolli
senza porte e iptables non puo` sapere a cosa ti riferisci.
Per favore, quota meglio.
Bye.


La mia situazione è di un server che chiude ogni accesso dall'esterno
su ogni porta, dunque un portscan non rileverebbe nessuna porta attiva,
perché il server in questione risulta ragggiungibile dall'esterno solo
esclusivamente da un server amico...
Ora sono un po' confuso... DROP può far intendere la presenza di un
firewall (io avevo inteso che non lo permette) o è meglio utilizzare
un REJECT per non far comprendere ciò? A me verrebbe da dire che
dovrei usare DROP, ma la mia scarsa padronanza in materia potrebbe
farmi dire uno sproposito...
Ancora grazie
Mr. Deckard

 un REJECT per non far comprendere ciò?
Nel tuo caso (sottolineo nel tuo caso) la scelta di DROP fa sì che, per un
IP non autorizzato) la macchina risulti equivalente ad un PC spento (visto
che non risponde indietro nulla).
C'è da dire che il DROP di default in ogni caso rallenta il lavoro di port
scanner et similia, che sono costretti, per ciascuna porta, ad attendere i
timeout (invece di passare alla successiva non appena arriva un RST o un
unreacheable).
Personalmente metto il default a DROP.
LG
-- 
Dott. Ing. Leandro Gelasi
LinuxHelp - Servizio supporto utenti Linux
Università di Roma "La Sapienza" - C.I.T.I.Co.R.D.
Email: gelasi(At)linuxhelp(punto)uniroma1(punto)it
Home Page: 
http://linuxhelp.uniroma1.it
Tel: 0649913828 - 23828 (int)

 un REJECT per non far comprendere ciò? 
Premesso che chiunque intenda buggarti la macchina ci proverà a
prescindere dal sistema, io adotterei REJECT con TCP-RST.
Inanzitutto in osservanza all'rfc che suggerisce :) un risposta di tipo
ICMP port unreachable in caso di porta chiusa e secondo per i motivi
gia' emersi.
Di contro:
1. con un sistema di fingerprinting inviare RST potrebbe fornire
informazioni sul OS utilizzato. Leggendo tra la documentazione di Nmap
mi pare di intuire che comunque non si tratta di una tecnica molto
precisa. Va da se che quest'ultimo non è l'unico scanner esistente...
2. DROP grava meno sul carico della macchina, ma non mi pare di certo
un problema.
Ciao
Beppe

 unreacheable).
Non proprio! Non ricordo la fonte ma tempo fa ho letto alcune
slide a riguardo. Non e' prassi comune per tutti gli scanner attendere
il timeout per spedire altri pacchetti e/o comunque e' possibile
modificare il modo di operare.
Ciao Beppe


Il drop non rallenta il lavoro di port scanner, per quello bisognerebbe
espandere iptables con altri moduli di Patch-O-Matic e inserire una
regola apposita per il freeze della connessione.
Per quanto riguarda il DROP o il REJECT  posso dire per esperienza che
il primo, se hai altri servizi che rispondono all'esterno diventa
inutile perchè è come un cartello che dice "FIREWALL"
Il secondo, applicato con un TCP-RST è altrettanto banale perchè
resettando la connessione il presunto attaccante può pensare ad un
firewall
Un reject con host-unreacheable aiuta il portscanner ad identificare le
porte aperte....
A quel punto per rendere "invisibile" il firewall si potrebbe ritardare
la risposta e mandare in timeout l'attaccante.
Per quanto riguarda il fingerprinting è un'altro discorso, per
evitarlo o falsi i pacchetti in uscita (TCP window size, e altre
menate) o in uscita non trasmetti nulla (DROP).
Bisogna poi decidere a cosa punti di più

 menate) o in uscita non trasmetti nulla (DROP).
Si crea un'artistica catena in cui infili tutti i pacchetti
NEW, salvo quelle che debbano raggiungere i servizi da esporre e ti
diverti col modulo random a mandare pacchetti di risposta variabili
a piacere. :)

 ma anche a quello si può ovviare.
Come?
Ciao.

 Come?
Agendo sul ttl dei rst generati. :)

 REJECT sanno che c'e` ma e` filtrato.
Non e' proprio cosi'.
A meno che non si sia in lan, se tenti di contattare un host spento 
dovresti ricevere un host unreachable dal router subito a monte. Se
non ricevi niente, in genere, vuole dire che l'host e' acceso ma e'
filtrato.
 
Fabio