Newsgroup: it.comp.os.linux.sys
Titolo: tabella FORWARD da sopra il gateway

(scusate il titolo).
Ho un gateway, con a valle di esso un gruppo di scimmie
poco addomesticate.
Hanno un problema a collegarsi in FTP, e so anche da cosa ï¿œ
causato il problema, ovvero dal conntrack.
Io posso lavorare solo sul firewall e non a valle di esso.
Dal firewall riesco a collegarmi perfettamente per cui il problema
potrebbe essere in un qualche filtro nella catena di FORWARD.
(anche se AFAIK basta questa riga:
iptables -A FORWARD -i $EXTIF -o $INTIF -m state --state 
ESTABLISHED,RELATED -j ACCEPT
abbinata al modulo nf_conntrack_ftp che ï¿œ giï¿œ caricato)
Posso, in qualche modo, instaurare una connessione FTP da sopra
il firewall simulando un nat? Ho la necessitï¿œ di passare per il
forward del firewall lavorandoci sopra e non a valle.
Il problema nasce dal fatto che le scimmie sono poco disponibili,
poco addomesticate, ed io ho terminato le banane da dargli in regalo
in cambio di un favore telefonico e adesso come adesso posso solo
andare a tentativi, fare una modifica, chiamarli, farmi mandare il log
di filezilla (ci ho messo 20 minuti a fargli fare copia-incolla su una
mail) e vedere perchï¿œ non funziona.
Avendo accesso, farei prima.
(no, installare software sui computer non ï¿œ possibile, non posso andare
piï¿œ sotto del firewall)

 abbinata al modulo nf_conntrack_ftp che è già caricato)
  Ci sono altre regole che permettono ai pacchetti NEW di passare la
catena FORWARD, che qui leggo sono presi in considerazione solamente
quelli RELATED e ESTABLISHED?
  Ciao,
-- 
Alessandro Selli 
http://alessandro.route-add.net
AVVERTENZA: i messaggi inviati a "trappola" non mi arriveranno.
WARNING: messages sent to "trappola" will never reach me.
Chiave PGP/GPG: EC885A8B

 quelli RELATED e ESTABLISHED?
(scusa il ritardo, son fuori tutti i giorni per un lavorone)
In ingresso no, in uscita si, certo.
La RELATED non dovrebbe permettere l'accesso a porte inerenti
una connessione esistente? Ad esempio permettere al server FTP (in
modalitï¿œ passiva) di connettersi ad una porta sul client solo nel caso
fosse presente una sessione FTP? Altrimenti, accettare i NEW non mi
pare una grande cosa, su di un firewall. Si accetterebbero anche tutte
le richieste create ex-novo non inerenti ad alcuna connessione.
(o piï¿œ probabilmente non ho capito a cosa ti riferisci e mi sto facendo
un gran viaggio)
iptables -A FORWARD -i $INTIF -o $EXTIF -s $LAN -p tcp -m multiport 
--dport $TCP_OUT_LAN -j ACCEPT
iptables -A FORWARD -i $INTIF -o $EXTIF -s $LAN -p udp -m multiport 
--dport $UDP_OUT_LAN -j ACCEPT
Ma la connessione al server avviene, son riuscito a farmi dare i log
di filezilla, ï¿œ il LIST che non viene effettuato correttamente, ne in
modalitï¿œ attiva, nï¿œ in passiva. Per questo credo sia un problema di
connection tracking, ma senza avere una macchina a valle del firewall
io non saprei come fare a simulare un nat e attraversare la forward.
Comando:         PASS ******
Risposta:        230 Accesso effettuato correttamente.
Comando:         SYST
Risposta:        215 UNIX Type: L8
Comando:         FEAT
Risposta:        211-Features:
Risposta:        MDTM
Risposta:        REST STREAM
Risposta:        SIZE
Risposta:        211 End
Stato:           Connesso
Stato:           Lettura elenco cartelle...
Comando:         PWD
Risposta:        257 "/" is current directory.
Comando:         TYPE I
Risposta:        200 Type set to I
Comando:         PASV
Risposta:        227 Entering Passive Mode (1,2,3,4,225,147).
Comando:         LIST
Errore:          Tempo scaduto per la connessione

 Errore:          Tempo scaduto per la connessione
non ci sono cazzi.
prima di tutto verifica che gli established e i related siano tra i primi
nelle catene e non ci siano drop prima.
In secondo luogo, posso capire eventuali problemi di FTP in modalit�
attiva, ma col passivo non ci sono peni. Deve funzionare.
Gli unici problemi che ho avuto in passato con la modalit� passiva erano su
una macchina winblows con un FTP Server ad-minchiam ed il firewall
attivato.
Se hai dietro il nat una macchina winblows, disattiva il FW visto che non �
stateful (almeno mi sembra).
Consiglio: prova da un PC esterno alla tua rete, bypassando le scimmie,
perch� per esperienza il problema pu� essere anche dal loro lato.
max
-- 
A: Because we read from top to bottom, left to right.
Q: Why should i start my reply below the quoted text?

 modalità attiva, nè in passiva.
  Beh, le uniche volte che ho avuto di tali comportamenti era sempre con
il client FTP in modalità attiva e il firewall che gestiva la sola
modalità passiva.  Ora, il modulo NF_CONNTRACK_FTP serve proprio per la
connessione attiva, altrimenti il protocollo FTP è visto e gestito come
qualsiasi altro e non avrebbe bisogno di un trattamento speciale.  Non so
che cosa succeda in fase di listing del contenuto del server (un bel
tcpdump?), ma siccome leggo nel kernel 2.6.29 che:
	CONFIG_NF_CONNTRACK_FTP:
	[...]
	This is FTP support on Layer 3 independent connection tracking.
	Layer 3 independent connection tracking is experimental scheme
	which generalize ip_conntrack to support other layer 3 protocols.
proverei, visto che i client usano tutti la modalità passiva, di
permettere solamente quella e quindi di NON caricare il modulo
NF_CONNTRACK_FTP e rilanciare il firewall, per vedere di nascosto
l'effetto che fa (cit.).  Che effettivamente, se non ci sono altre regole
strane a metterci lo zampino in altre parti del firewall, non ci sono falli.


 perchè per esperienza il problema può essere anche dal loro lato.
Dalla mia rete verso il mio ftp funziona.
Però io devo sistemare il problema del loro firewall verso il mio ftp.
Si, so che è un problema della loro rete e devo appunto risolverlo ma
senza aver modo di simulare un nat posso solo andare a tentativi e far
fare dei test al cliente, e non è il massimo come professionalità.


quindi in modalità passiva non mi server quel modulo, ok, ma devo
aprire
un range di porte sul mio server ftp e comunicare al server ftp quali
porte usare
per la modalità passiva.
Ok, già fatto, ed infatti io mi collego sia in passiva che in attiva.
Il problema è solo con la rete del cliente, il mio firewall blocca
troppo, e non so
come risolvere, di certo non posso andare a tentativi con il cliente
al telefono
dicendo: ok prova adesso? -non va- Riprova ora? -non va- e così via.
Non c'è proprio modo di passare per la forward da sopra il firewall?
Così avrei modo di fare gli opportuni test senza rompere i cojones al
cliente.

 wrote:
'zzo che quotatura che ho fatto prima.
scusate.

 l'effetto che fa (cit.).  Che effettivamente, se non ci sono altre regole
 > strane a metterci lo zampino in altre parti del firewall, non ci sono 
falli.
Posto alcune parti salienti:
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT
modprobe nf_conntrack
modprobe nf_conntrack_netlink
modprobe nf_conntrack_ftp
iptables -A INPUT -i lo -j ACCEPT
iptables -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
iptables -A INPUT -i $EXTIF -j DROP
iptables -A FORWARD -i $EXTIF -o $INTIF -m state --state 
ESTABLISHED,RELATED -j ACCEPT
iptables -A FORWARD -i $EXTIF -o $INTIF -j DROP
iptables -A FORWARD -i $INTIF -o $EXTIF -s $LAN -p icmp -j ACCEPT
iptables -A FORWARD -i $INTIF -o $EXTIF -s $LAN -p tcp -m multiport 
--dport 20,21,25,110,143,443 -j ACCEPT
iptables -t mangle -A FORWARD -j NFQUEUE --queue-num 3
iptables -t filter -A FORWARD -m mark --mark 9 -j DROP
iptables -t nat -A POSTROUTING -o $EXTIF -s $LAN -j MASQUERADE
iptables -t nat -A PREROUTING -i $INTIF -s $LAN -p tcp --dport 80 -j 
DNAT --to $PROXY_IP:3128
echo 1 > /proc/sys/net/ipv4/ip_forward

 echo 1 > /proc/sys/net/ipv4/ip_forward
Loggare no, eh? :-P
Dicono che aiuti a capire quando si fa qualche cazzata...
Partiamo.
:iptables -P FORWARD DROP 
E ok...
:iptables -A FORWARD -i $EXTIF -o $INTIF -m state --state \
:ESTABLISHED,RELATED -j ACCEPT
E ok...
:iptables -A FORWARD -i $EXTIF -o $INTIF -j DROP
Non ne vedo il senso, visto che hai la policy a DROP.
:iptables -A FORWARD -i $INTIF -o $EXTIF -s $LAN -p icmp -j ACCEPT
E ok...
:iptables -A FORWARD -i $INTIF -o $EXTIF -s $LAN -p tcp -m multiport \ 
:--dport 20,21,25,110,143,443 -j ACCEPT
Hai presente come funziona ftp in passive mode?
ftp> passive
Passive mode on.
ftp> ls
---> PASV
227 Entering Passive Mode (192,132,34,17,215,236)
---> LIST
I primi quattro numeri rappresentano l'ip di destinazione, 192.132.34.17
(
ftp.unina.it
), mentre gli ultimi due sono la porta *destinazione* alla quale
mi sto per connettere per aprire la sessione dati, con porta=n5*256+n6 ovvero, nel
caso in esame, dport=55276.
E' chiaro perchè i client ftp non vanno, dietro il tuo firewall, no? :-P

 E' chiaro perchè i client ftp non vanno, dietro il tuo firewall, no? :-P
Ecco l'inghippo.
:-)
Ho il cervello da riprogrammare, ho sempre bisogno di ferie.
Ma almeno in active dovrebbe funzionare no?
Eppure....

 Eppure....
Secondo me, una ripassatina su come funziona non ti farebbe male...
Max


 Secondo me, una ripassatina su come funziona non ti farebbe male...
A su questo non c'� dubbio.
Per�, in active:
1) Il client effettua la richiesta al server verso la porta 21.
2) Il server risponde dalla control-port (21) verso la porta del client.
3) Il server apre una nuova connessione dalla data-port (20) verso una
porta del client
4) Il client risponde.
Il terzo passaggio � mal visto dal firewall, in quanto il server
cerca di instaurare una connessione su una porta inesistente, ma
il modulo di conntrack dovrebbe riconoscere che si sta parlando
di una sessione FTP per cui dovrebbe autorizzare il traffico verso
tale porta.
Non � cos�?
In passivo invece � sempre il client che apre delle connessioni in
uscita, verso porte altissime (40k-65k) sul server, tant'� che sul
server ho autorizzato in ingresso il traffico verso tali porte.
ed il passivo dovrebbe essere amico dei firewall aziendali, in quanto
c'� solo traffico in uscita, nessuna porta in ingresso va aperta.

 Secondo me, una ripassatina su come funziona non ti farebbe male...
Beh...
:iptables -A FORWARD -i $EXTIF -o $INTIF -m state --state \
:ESTABLISHED,RELATED -j ACCEPT
:iptables -A FORWARD -i $INTIF -o $EXTIF -s $LAN -p tcp -m multiport \ 
:--dport 20,21,25,110,143,443 -j ACCEPT
La prima dovrebbe consentire il passaggio del primo SYN proveniente
dal server, porta 20, se il modulo di conntrack ftp è caricato e
la seconda dovrebbe consentire il traffico il traffico di ritorno
verso la porta 20 del server, o è venerdì anche per me?
Ad ogni buon conto, "ESTABLISHED, RELATED" è il migliore amico dell'uomo
e non vedo perchè non usarlo anche per il traffico proveniente da 
$INTIF, questo sì...

 $INTIF, questo sì...
Personalmente non ho mai messo ESTABLISHED,RELATED in forward da
INT a EXT.
Ho sempre fatto solo da EXT a INT