Newsgroup: it.comp.os.linux.sys
Titolo: iptables configurazione...

ciao a tutti!
Ho "costruito" una rete di PC a casa con un firewall (linux) che filtra i
pacchetti non autorizzati.
Mi piacerebbe avere un web server accessibile dall'esterno su un PC della
rete privata (192.168.x.x) tramite port forwarding della porta 80.
ho provato di tutto ....qualcuno mi potrebbe dire cosa ho sbagliato??
Ecco lo script:
        INTIF=eth0
        EXTIF=ppp0
        TCP_SERVICES="21,22,113,80"
        PORT_REJECTED="8198,1214"
        modprobe ip_nat_ftp
        modprobe ip_conntrack_ftp
        echo 0 > /proc/sys/net/ipv4/tcp_syncookies
        echo 0 > /proc/sys/net/ipv4/ip_forward
        iptables -F INPUT
        iptables -F FORWARD
        iptables -F OUTPUT
        iptables -t nat -F PREROUTING
        iptables -t nat -F POSTROUTING
        iptables -P INPUT DROP
        #iptables -A INPUT -p tcp --dport 8198 -j REJECT
        iptables -A INPUT -p tcp -m multiport --dport $PORT_REJECTED -j
REJECT
        iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
        iptables -A INPUT -i $EXTIF -m state --state NEW -p tcp -m
multiport --dport $TCP_SERVICES -j ACCEPT
        iptables -A INPUT -i $INTIF -m state --state NEW -j ACCEPT
        iptables -A INPUT -i $EXTIF -s 
192.168.100.1/32
 -d 
224.0.0.1/32
 -j
ACCEPT
        iptables -A INPUT -i lo -m state --state NEW -j ACCEPT
        iptables -A INPUT -p tcp --dport 113 -j REJECT
        iptables -A INPUT -j LOG --log-level warn --log-prefix "FW_INPUT  "
        iptables -P FORWARD DROP
        iptables -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
        iptables -A FORWARD -i $EXTIF -m state --state
ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -p tcp -i ppp0 --dport 80 -j ACCEPT
        iptables -A FORWARD -j LOG --log-level warn --log-prefix "FW_FORWARD
"
        iptables -P OUTPUT ACCEPT
iptables -A PREROUTING -t nat -i $EXTIF -p tcp --dport 80 -j
DNAT --to-destination 
192.168.254.20:80
        iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
        # Kernel guard against SYN flooding enabled
        echo 1 > /proc/sys/net/ipv4/tcp_syncookies
        echo 1 > /proc/sys/net/ipv4/ip_forward
Ringrazio anticipatamente tutti coloro che mi vorranno aiutare!!!
SilVio

 DNAT --to-destination 
192.168.254.20:80
se la porta rimane quella, puoi indicare solo l'ip, senza la porta 
destinazione
il resto, mi pare ok...
-- 
+-------
| Paolo opg
|
| janickg ( at ) hotmail ( dot ) com
| (fake address in reply-to field!)
+-------

 wrote in message
news:br9v3c$tl7i$1...@ID-148035.news.uni-berlin.de...


 dall'interno della rete tramite browser...
Scusa non ho capito...
Coie' riesci a raggiungere il webserver da internet ma non dalla lan????
Spiega meglio.
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (
http://www.grisoft.com
).
Version: 6.0.550 / Virus Database: 342 - Release Date: 09/12/2003


accetto pacchetti destinati alla rete privata per poter navigare in rete.
SilVio

 Spiega meglio.
Infatti!
se caricola pagina  
http://213.45.1.xxx
 da  un PC della mia rete privata non
funziona,
mentre se lo faccio dall'esterno tutto funziona!

 funziona,
...ma quel 213.45.1.xxx e' l'indirizzo pubblico del webserver???
Dalla lan devi usare quello privato no?


 accetto pacchetti destinati alla rete privata per poter navigare in rete.
E che significa? Per navigare devi preoccuparti solo del maquerating... non
capisco!


 
sarebbe tutto regolare se li accettassi sull'interfaccia interna, ma 
siccome la regola indica come accettabili i pacchetti che arrivano 
sull'interfaccia esterna...
dall'esterno non possono e non devono arrivare pacchetti con ip privato, ne 
come sorgente, ne come destinazione.


 wrote in
news:bra1ce$12omi$
1...@ID-148035.news.uni-berlin.de
: 

a parte il fatto che si tratta del normale funzionamento di tutti i fw 
che conosco...
l'unico modo che hai per aggirare questo problema, č mettere una regola 
ad hoc in prerouting che rediriga tutti i pacchetti in ingresso 
(sull'interfaccia interna) con destinati al tuo ip pubblico, all'ip 
privato del tuo server.


Il giorno Thu, 11 Dec 2003, SilVio così ha scritto:
|ciao a tutti!
|Ho "costruito" una rete di PC a casa con un firewall (linux) che filtra i
|pacchetti non autorizzati.
|Mi piacerebbe avere un web server accessibile dall'esterno su un PC della
|rete privata (192.168.x.x) tramite port forwarding della porta 80.
|
|ho provato di tutto ....qualcuno mi potrebbe dire cosa ho sbagliato??
|
|Ecco lo script:
|
|        INTIF=eth0
|        EXTIF=ppp0
|        TCP_SERVICES="21,22,113,80"
|        PORT_REJECTED="8198,1214"
|
|        modprobe ip_nat_ftp
|        modprobe ip_conntrack_ftp
|
|        echo 0 > /proc/sys/net/ipv4/tcp_syncookies
|        echo 0 > /proc/sys/net/ipv4/ip_forward
|
|        iptables -F INPUT
|        iptables -F FORWARD
|        iptables -F OUTPUT
|        iptables -t nat -F PREROUTING
|        iptables -t nat -F POSTROUTING
  Aggiungici pure: iptables -t nat -F OUTPUT
|        iptables -P INPUT DROP
  Ottimo.  Sono uno di quelli che pensano che il migliore firewall è quello
che funziona quando ha tutte le "POLICY" impostate su "DROP".
|        #iptables -A INPUT -p tcp --dport 8198 -j REJECT
|        iptables -A INPUT -p tcp -m multiport --dport $PORT_REJECTED -j
|REJECT
|        iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
|        iptables -A INPUT -i $EXTIF -m state --state NEW -p tcp -m
|multiport --dport $TCP_SERVICES -j ACCEPT
|        iptables -A INPUT -i $INTIF -m state --state NEW -j ACCEPT
|        iptables -A INPUT -i $EXTIF -s 
192.168.100.1/32
 -d 
224.0.0.1/32
 -j
|ACCEPT
  Qui accetti i pacchetti provenienti dall'interfaccia "ppp0" aperta su
internet con IP di provenienza uguale a "192.168.100.1" e IP di destinazione
uguale a "224.0.0.1".  Non è possibile che da internet ti provengano pacchetti
con IP privati "192.168.*.*".  Se "224.0.0.1" è il tuo IP pubblico, ti basta
togliere la parte "-s 
192.168.100.1/32
" della tua regola, così ammetti i
pacchetti in ingresso su "ppp0" con qualsiasi IP di provenienza.
|        iptables -A INPUT -i lo -m state --state NEW -j ACCEPT
  Limitare i pacchetti generati dalla macchina locale è sempre un rischio
difficilmente giustificabile.
|        iptables -A INPUT -p tcp --dport 113 -j REJECT
|
|        iptables -A INPUT -j LOG --log-level warn --log-prefix "FW_INPUT  "
|
|        iptables -P FORWARD DROP
|        iptables -A FORWARD -i $INTIF -o $EXTIF -j ACCEPT
|
|        iptables -A FORWARD -i $EXTIF -m state --state
|ESTABLISHED,RELATED -j ACCEPT
  Manca il "NEW".  Se non consenti al forwarding di un pacchetto che apre una
nuova connessione, non avrai mai connessioni che siano "ESTABLISHED,RELATED".
|iptables -A FORWARD -p tcp -i ppp0 --dport 80 -j ACCEPT
|        iptables -A FORWARD -j LOG --log-level warn --log-prefix "FW_FORWARD
|"
|
|        iptables -P OUTPUT ACCEPT
|
|iptables -A PREROUTING -t nat -i $EXTIF -p tcp --dport 80 -j
|DNAT --to-destination 
192.168.254.20:80
|        iptables -t nat -A POSTROUTING -o $EXTIF -j MASQUERADE
|
|        # Kernel guard against SYN flooding enabled
|        echo 1 > /proc/sys/net/ipv4/tcp_syncookies
|        echo 1 > /proc/sys/net/ipv4/ip_forward
  Beh, ti mancano le regole che effettuino il NAT perché dall'esterno si possa
raggiungere un tuo server nella LAN con solo un IP privato.  Questo server ha
IP "192.168.100.1", suppongo che il firewall abbia come suo IP sulla LAN
privata "192.168.100.100" e come IP pubblico "224.0.0.1", quindi puoi mettere:
iptables --table nat --append PREROUTING --destination 
224.0.0.1/32
 \
--protocol tcp --destination-port 80 --jump DNAT --to-destination 192.168.100.1
# I pacchetti diretti all'IP pubblico del firewall alla porta 80 hanno
# modificato l'IP di destinazione all'IP del web server sulla LAN interna appena
# il pacchetto entra nella macchina, prima che se ne effettui l'instradamento
iptables --table nat --append POSTROUTING --destination 192.168.100.1 \
--protocol tcp --destination-port 80 --jump SNAT --to-source 192.168.100.100
# Dopo l'instradamento del pacchetto con IP di destinazione alterato, se ne
# altera l'IP di provenienza perché sia uguale a quello del firewall nella LAN
# privata, così che il web server risponda direttamente al firewall con un
# pacchetto diretto all'IP privato del firewall invece di quello pubblico del
# richiedente originale.  Il firewall (iptables) provvederà poi a rifare al
# contrario gli aggiustamenti di IP necessari perché il pacchetto giunga all'IP
# pubblico di origine iniziale.
  Spero di averla detta giusta.
  Sandro
-- 
Bellum se ipsum alet
       La guerra nutre se stessa
Livio, Ab urbe condita, XXXIV,9

 privato del tuo server.
Si... ma continuo (scusa l'ottusaggine) a non capire proprio qul'e' il
problema! Perche' dalla lan dovrebbe contattare l'indirizzo pubblico di un
web server che sta *dentro* la lan stessa????? Forse del problema del nostro
amico non ci ho capito un tubo!!


 
:-)
non discuto sull'opportunità o meno di una scelta del genere, riporto 
solo un caso (che mi è capitato...).
prova a pensare al capo, anzi, no al Capo che vuole visitare il sito 
aziendale, digitando direttamente 
www.azienda.it
.
siccome il sito è su un server in lan (no, niente dmz...), il Capo non ci 
riesce e quindi ti rompe i maroni.
a me, vengono in mente solo due soluzioni che non portino a spese 
aggiuntive (ovviamente cassate dal Capo...) e al mio immediato 
siluramento:
-file hosts
-regola sul fw
tu quale useresti?
;-P


 tu quale useresti?
eheheh... io ho accontentato il capo  con un CNAME di bind tipo "www   IN
CNAME   linux" dato che il dominio della mia lan l'ho chiamato uguale al
dominio internet e la macchina che fa da webserver si chiama linux nella lan
^__^


 con IP privati "192.168.*.*".  Se "224.0.0.1" è il tuo IP pubblico, ti basta
Non e' del tutto vero, 192.168.100.1 e' il gateway della telecom per le
connessioni adsl, se da una connessione adsl di tin/virgilio fai un
traceroute, troverai che il primo router dopo del tuo modem e' proprio
192.168.100.
Loro dicono che usano un indirizzo del genere per questioni di
sicurezza. Se ne e' discusso spesso, se cerchi nell'archivio di google
trovi un sacco di post.
Il 224.0.0.1 e' dedicato al multicast
cya
Banana

 192.168.100.
Si ma questo e' proprio un caso limite, un "accrocchio" del Telecom come al
solito, non so per quale motivo forse per risparmiare indirizzi pubblici?
Fatto sta che di norma una situazione del genere non dovrebbe verificarsi,
non trovi?
Ciao.


 non trovi?
In effetti e' una decisione quantomeno opinabile
cya
Banana

 A quel punto ti resta solo la autoflagellazionetesticolare
beh... effettivamente :p


Il giorno Thu, 11 Dec 2003, Banana così ha scritto:
|Io non la penso cosi, ma non volgio flammare, quindi non mi dilungo nei
|dettagli.
  Grazie!  :-)
|> uguale a "224.0.0.1".  Non è possibile che da internet ti provengano pacchetti
|> con IP privati "192.168.*.*".  Se "224.0.0.1" è il tuo IP pubblico, ti basta
|
|Non e' del tutto vero, 192.168.100.1 e' il gateway della telecom per le
|connessioni adsl,
[...]
  Ottimo, nessun pentimento allora per aver evitato la tele(com).



Ma tu, sapendolo, ti premunisci inserendo un cron job che ad intervalli
regolari ti riattivi l'accesso ssh aprendolo al mondo intero :)
Ciaotutti,
*

 regolari ti riattivi l'accesso ssh aprendolo al mondo intero :)
gia' fatto, gira ogni 5 min e si chiama "/usr/sbin/salvachiappe"
Pero' le policy stanno cmq ad accept :-)
Banana

 wrote in
news:brcfg1$1rrqs$
1...@ID-146122.news.uni-berlin.de
: 

io trovo più pratico un:
./IPTablesRuleSet ; sleep 15 ; ./SalvaChiappe
se tutto va come deve, in 15 sec mando un ctrl C, altrimenti le regole si 
resettano.
non mi piace l'idea di uno script che modifica il firewall periodicamente, 
anche se solo durante il testing...



Esatto...     ;-)    A me questo noto "problema" (se cosi' lo vogliamo 
chiamare...) non mi si presenta , in quanto dai miei clienti il server 
sta sempre in dmz, e posso contatarlo indifferentemente con l'ip privato 
o pubblico. Poiche' pero' molto spesso sul firewall piazzo lo squid 
(specie quando le linee si pagano a traffico...), il problema si 
presenta in un'altra forma, costringendomi a istruire ogni browser nella 
sezione proxy a non passare per il proxy per quell'indirizzo/nome dominio...
Any iptables suggestion?         :-)
bye G.L.
-- 
- Renaissance, aka Gian Luca Sole -
Cit. « E' assolutamente evidente che l'arte del cinema
 si ispira alla vita, mentre la vita si ispira alla TV »
                                        (Woody Allen)


Mi sa che alla fine la flame si dovra' aprire...  ;-)   Uno dei motivi 
per cui si sceglie di mettere tutto in DROP, anziche' in ACCEPT, e' il 
fatto che e' piu' semplice e breve decidere cosa deve passare, piuttosto 
che decidere cosa fermare. E ti toglie anche molti dubbi su cosa ti puoi 
essere dimenticato aperto (anche se, e' vero, per quello c'e' nmap & 
company...). Invece a me rimangono sempre dubbi su cosa mi possa essere 
dimenticato chiuso...
E mi pare anche che il metodo si agganci meglio al fatto che iptables e' 
stateful.
Il fatto che ti sia capitato di esserti "bruciato" la connessione 
remota, e' IMHO in seguito risolvibile *non* cambiando il modo di 
costruire il firewall (che mi sembra simile al rovesciare la macchina 
per svuotare il portacenere...  ;-), ma facendo attenzione a quello che 
fa lo script di comandi iptables ogni volta che lo lanci, e testandolo 
prima di tutto da un pc della rete del cliente.    :-)
Sono due anni che modifico spesso le regole gli script iptables 
remotamente, ed ancora - dirai fortunatamente - non mi e' capitato 
niente.     :-)
Anche perche' io non lancio mai singoli comandi, ma sempre l'intero 
script dopo averlo modificato.
Ed anche perche', benche' lo script spazzi via tutte le regole e 
reimposti le policy della catene e le regole, cio' che c'e' nella 
tabella di connection tracking rimane come prima.    :-)


 prima di tutto da un pc della rete del cliente.    :-)
bhe' naturale, sono mica un kanikaze :-)
cya
Banana


Beh... non ci ho pensato: allora in tal caso e' equivalente al metodo 
delle default policy in drop. Con la differenza che in effetti ti 
salva... dai flush accidentali.     :-)
A parte qualche eccezione, tipo richieste ident che rallentano di molto 
l'accesso a determinati servizi in certi host, il metodo reject di 
solito non lo uso (eccetto che nella catena output, e magari in forward 
solo per il traffico riguardante la lan), perche' considero che il 
pacchetto icmp-port-unreachable che il firewall ritorna al mittente, 
oltre a poter rendere possibile il riconoscimento del sistema operativo, 
facilita di molto il port scanning.


 Any iptables suggestion?         :-)
Aggiungo: a parte un problema di routing, un'altro problema e' che squid 
apre il socket con l'indirizzo sorgente uguale all'alias pubblico del 
web server (invece che usare come ip sorgente l'ip pubblico del 
firewall), verso lo stesso alias, porta 80!    :-)
Comunque, ho gia' risolto impostando un URL redirector in perl su 
squid.   :-)


 Any iptables suggestion?         :-)
Risolto con URL redirection in squid.   :-)


 anche se solo durante il testing...
bhe' lo script non fa altro che fare iptables -I INPUT -p tcp --dport 22
-j ACCEPT, non e' che sconvolge le regole del firewall. Cmq anche qui
degustibus (se si scrive cosi), l'importante e' non chiudersi fuori. :-P
Banana

Grazie a tutti!!!
SilVio