Newsgroup: it.comp.os.linux.sys
Titolo: iptables, sicuramente sbaglio qualcosa.

Ho registrato un host presso dyndns.
Il mio hostname pubblico risulta essere: ilmiohostname.
Su un server pubblico col servizio ssh attivo per avere accesso ho 
aggiunto una regola di questo tipo:
iptables -A INPUT -s ilmiohostname -p tcp --dport 22 -m state --state 
NEW -j ACCEPT
Ciononostante non mi fa entrare.
Se tolgo la regola invece e' tutto ok.
Come mai?

 Se tolgo la regola invece e' tutto ok.
Se postassi tutta la catena di INPUT, policy di catena compresa, magari
ti si potrebbe aiutare.

music ha scritto:



La butto li... Hai cambiato IP **DOPO** aver impostato la regola...
In tal caso, visto che IPTables memorizza l'IP e non il nome, avendo un IP
diverso ti sbatte la porta in faccia...
Se vuoi fare un "Firewall dinamico", devi tenere presente che, ogni tanto,
il Server deve controllare se l'IP e' cambiato e, nel caso, riscrivere la
regola con il nuovo IP!
Ciao
Luca Bertoncello
(
luca...@lucabert.de
)
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 iptables -A INPUT -s ilmiohostname -p tcp --dport 22 -m state --state NEW -j ACCEPT
Cosi` passa solo il primo pacchetto (a meno che tu non abbia un'altra 
regola che fa passare i successivi)!
Non ha senso chiedere che passi solo il primo pacchetto, modifica in:
iptables -A INPUT -s ilmiohostname -p tcp --dport 22 -j ACCEPT
Ciao
	Stefano

 diverso ti sbatte la porta in faccia...
Mi scuso se non ho postato tutte le regole, ce ne sono di altre ma 
fondamentalmente per il problema in oggetto quelle di interesse sono:
iptables -P INPUT DROP
iptables -A INPUT -s ilmiohostname -p tcp --dport 22 -m state --state
NEW -j ACCEPT
In effetti mi sono registrato su dyndns proprio per avere un riferimento 
fisso, in questo caso tramite un hostname, su internet, in quanto, 
avendo un adsl a casa, l'ip e' dinamico.
Quindi tu hai centrato il problema.
Devo quindi riscrivere la regola ogni volta?

Stefano Giuliano ha scritto:

E' lo stesso dubbio che avevo io.
A parte il fatto che il problema dovrebbe essere il fatto che il mio ip 
e' dinamico anche se l'hostname e' sempre lo stesso, ho notato che sia 
per il servizio ssh come anche per altri servizi, ad esempio LDAP, mi 
basta utilizzare --state NEW -j ACCEPT e questo e' sufficente, le 
connessioni vengono accettare regolarmente.

 vengono accettare regolarmente.
probabilemente perché hai la regola "--state established,related" in ACCEPT 
(che è praticamente d'obbligo per le policy di DROP) 

 Devo quindi riscrivere la regola ogni volta?
Per essere proprio precisi, ogni volta che scade il TTL del record
dns... 60 secondi o giù di lì. Ma dipende molto da quanto la tua
connessione cambia IP, da quanto vuoi caricare il tuo server, ecc.
Forse potresti trovare modi migliori per restringere l'accesso...
Enrico

 Devo quindi riscrivere la regola ogni volta?
Chiedersi il significato di ciò che si scrive può essere decisamente
più interessante.
Il primo pacchetto tcp che indirizzerai da ilmiohostname alla porta
22 della tua box, che sarà un SYN, se usi un client ssh, passerà.
Il secondo pacchetto che invierai in risposta al SYN ACK, sarà
giudicato in stato ESTABLISHED, così come tutti i successivi
che proverai ad inviare.
E tutti questi pacchetti, non avendo stato NEW, andranno
a finire nella policy di catena, DROP.
Quindi, o aggiungi in fondo alla catena
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
o togli quel riferimento allo state nell'unica regola della catena.

 Devo quindi riscrivere la regola ogni volta?
Immaginavo che fosse cosi'...
Anch'io ho un IP dinamico a casa e mi sono registrato su DynDNS proprio
per chiudere il Server, lasciandomi la possibilita' di loggarmi dal mio IP
attuale...
L'ideale e' fare uno script che ogni tanto (ogni minuto, ogni ora, vedi un
po' tu!) interroga dyndns e chiede che IP ha il tuo dominio. Poi lo
confronta con l'ultimo che aveva. Se sono differenti cancella la regola
attuale in IPTables (per non lasciare la porta aperta) e la riscrive,
questa volta con l'indirizzo corretto.
Quindi si salva l'IP da qualche parte per il prossimo controllo.
Io ho fatto cosi' e funziona alla perfezione da almeno 4 anni...


Ema ha scritto:

prendo pari pari la regola per l'accesso al servizio https.
iptables -P INPUT DROP
iptables -A INPUT -p tcp --dport 443 -m state --state NEW -j ACCEPT
funziona perfettamente pure non avendo established e related.
come lo spieghi.

 come lo spieghi.
dimenticavo queste anche se non centrano nulla:
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

 iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
In fondo o in testa? Io l'ho sempre messa in cima...
-- 
http://bofhskull.wordpress.com/

 come lo spieghi.
Ma la regola con established e related non viene mai eseguita? nemmeno in un 
altro script o in fondo allo stesso?
No perchè il fatto che tu abbia riscritto la regola della policy mi fa 
pensare che tu creda che le regole sono scritte "a gruppi" e quindi se la 
serie di regole per ssh non contiene quella con established,related, questa 
non è presente.
Per togliere ogni dubbio faresti meglio ad incollare un bel "# iptables -L" 
se non è troppo lungo... 

 In fondo o in testa? Io l'ho sempre messa in cima...
Beh, in testa è meglio, senza dubbio, ma io mi riferivo alla sua catena. :)

 wrote in message
news:49425658$0$40309$4faf...@reader5.news.tin.it...

Per me manca qualche cosa. Hai detto che togliendo la regola della porta 22
tutto ti funziona.
Se la tua catena interessata dal traffico che stai analizzando fosse
realmente circoscritta alle due regole sopra, togliendo la regola di ACCEPT
ti andrebbe necessariamente in DROP della policy.
Come ho detto, per me stai postando e guardando solo una parte della catena
coinvolta.
Ciao
  Nameci

 se non  troppo lungo... 
iptables -vnL
darebbe qualche info in più... IMHO non si sa mai.
Enrico

Enrico Bassetti ha scritto:

Eccolo qui:
Chain INPUT (policy DROP 1 packets, 229 bytes)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 ACCEPT     0    --  lo     *       
0.0.0.0/0
 
0.0.0.0/0
     0     0 LOG        0    --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           state INVALID LOG flags 0 level 6 prefix `INVALID:'
     0     0 DROP       0    --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           state INVALID
     0     0 LOG        0    -f  *      *       
0.0.0.0/0
 
0.0.0.0/0
           LOG flags 0 level 6 prefix `FRAGMENTS:'
     0     0 DROP       0    -f  *      *       
0.0.0.0/0
 
0.0.0.0/0
     6   429 ACCEPT     0    --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           state RELATED,ESTABLISHED
     0     0 ACCEPT     icmp --  *      *       
192.168.0.0/16
 
0.0.0.0/0
           icmp type 8 state NEW,RELATED,ESTABLISHED
     0     0 ACCEPT     icmp --  *      *       
172.16.10.0/24
 
0.0.0.0/0
           icmp type 8 state NEW,RELATED,ESTABLISHED
     0     0 ACCEPT     tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           tcp dpt:443 state NEW
     0     0 ACCEPT     tcp  --  *      *       192.168.4.88 
0.0.0.0/0
           tcp dpt:80 state NEW
     0     0 ACCEPT     tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           tcp dpt:25 state NEW
     0     0 ACCEPT     tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           tcp dpt:995 state NEW
     0     0 ACCEPT     tcp  --  *      *       172.16.10.2 
0.0.0.0/0
           tcp dpt:143 state NEW
     0     0 ACCEPT     tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           tcp dpt:143 state NEW
     0     0 ACCEPT     tcp  --  *      *       172.16.10.2 
0.0.0.0/0
           tcp dpt:993 state NEW
     0     0 ACCEPT     tcp  --  *      *       
0.0.0.0/0
 
0.0.0.0/0
           tcp dpt:993 state NEW
     0     0 ACCEPT     tcp  --  *      *       
192.168.4.0/24
 
0.0.0.0/0
           tcp dpt:22 state NEW
     0     0 ACCEPT     tcp  --  *      *       
192.168.5.0/24
 
0.0.0.0/0
           tcp dpt:22 state NEW
     0     0 ACCEPT     tcp  --  *      *       172.16.10.120 
0.0.0.0/0
           tcp dpt:22 state NEW
     0     0 ACCEPT     tcp  --  *      *       xx.xx.xx.xx 
0.0.0.0/0
           tcp dpt:22 state NEW
     0     0 ACCEPT     tcp  --  *      *       192.168.4.88 
0.0.0.0/0
           tcp dpt:389 state NEW
     0     0 ACCEPT     tcp  --  *      *       192.168.4.7 
0.0.0.0/0
           tcp dpt:389 state NEW
     0     0 ACCEPT     tcp  --  *      *       172.16.10.15 
0.0.0.0/0
           tcp dpt:389 state NEW
     0     0 ACCEPT     tcp  --  *      *       172.16.10.13 
0.0.0.0/0
           tcp dpt:389 state NEW
     0     0 ACCEPT     tcp  --  *      *       172.16.10.2 
0.0.0.0/0
           tcp dpt:389 state NEW
Chain FORWARD (policy DROP 0 packets, 0 bytes)
  pkts bytes target     prot opt in     out     source 
destination
Chain OUTPUT (policy ACCEPT 31M packets, 25G bytes)
  pkts bytes target     prot opt in     out     source 
destination
     0     0 ACCEPT     0    --  *      lo      
0.0.0.0/0
 
0.0.0.0/0
xx.xx.xx.xx sarebbe l'ip pubblico corrispondente all'hostname 
ilmiohostname registrato su dyndns.
Potete notare che non c'e' nessuna regola estabished o related eppure 
tutti i servizi indicati accettano le connessioni e rispondono senza 
problemi.

 Potete notare che non c'e' nessuna regola estabished o related
6 429 ACCEPT 0 --  * * 
0.0.0.0/0
 
0.0.0.0/0
 state RELATED,ESTABLISHED
La regola, come ti è stato detto, ci doveva essere, altrimenti nulla
avrebbe funzionato.
A questo punto, può essere solo un problema legato alla non corrispondenza
tra il xx.xx.xx.xx e l'indirizzo reale nel momento in cui ti connetti.
Quello che proprio non capisco è la regola in cui droppi i frammenti: se
usi il conntrack, quella regola non dovrebbe avere *mai* alcun match.

 usi il conntrack, quella regola non dovrebbe avere *mai* alcun match.
Mi ero copiato pari pari un esempio preso dalla rete, adesso non ricordo 
pu' dove.