Newsgroup: it.comp.sicurezza.varie
Titolo: Cut-Through Proxy

"cut-through proxy" dei Cisco PIX, e' proprio cosi'?
Mah, mi vergogno a dire di non averne mai sentito parlare; mi sono
documentato un po' trovando una manciata di pagine e questo:
: Cut-through proxy is the process where the first packet in a
: session is checked as in any proxy server, but all subsequent
: packets are passed through. This technique allows the PIX
: to transfer packets extremely efficiently
...che, a dire la verita', mi ricorda iptables :-?
Leonardo
-- 
"Se e' vero che Linux in se' e' gratis, non lo sono le indispensabili
interfacce grafiche (X, KDE ecc.) che consentono alle persone normali
di utilizzarlo."                    -- Jason Matusow, Microsoft Corp.

 ...che, a dire la verita', mi ricorda iptables :-?
in effetti, quello che mi pareva (ma probabilmente mi sbaglio) un po'
diverso era l'accenno alla richiesta di username e password (da
confrontare con quelle di un database della rete interna):
"Cut-through proxy is the capability of the PIX firewall to control which
users have access to the system. It does this by requiring a username and
password authentication for users who want to use HTTP, Telnet, or FTP
across the firewall. The authentication occurs only once, making the
process extremely fast and efficient, especially when compared to the same
type of technologies available on application proxies that authenticate
every packet. If you need to support other
 protocols that fall out of the HTTP, Telnet, or FTP realm, you can use a
 echnology named Virtual Telnet. This is covered in a later chapter."
il problema e' che a leggere la documentazione che ho trovato sembrerebbe
che invece lo potesse fare per *ogni*  syn tcp, non solo sulle le porte di
cui sopra. Il che mi pare un po' strano, perche' immagino che per richiedermi
una login ed una password lui debba in qualche modo riconoscere il tipo di
servizio che sto richiedendo; quindi, per fare l'esempio che mi interessa
piu' specificatamente, se invio una richiesta ssh ad un server ssh della
rete interna, il firewall deve capire che si tratta di un pacchetto ssh e
non per esempio ftp, mandare al mio clinet ssh una richiesta di login e
password, ed a quel punto farmi accedere alla rete interna (e in teoria
una volta superato questo step dovro' digitare un'altra login e password
per accedere al vero e proprio server ssh, ma questo mi va pure bene). E
questo, sempre se fosse vero il 
http://www.kmj.com/cisco/pix.html
:
"User Authentication and Authorization with Cut-Through Proxy---The Cisco
Secure PIX Firewall series gains further dramatic performance advantages
through cut-through proxy, a patent-pending method of transparently
verifying the identity of users at the firewall and permitting or denying
access to *any* TCP- or UDP-based application. This method eliminates the
price/performance impact that UNIX system-based firewalls impose in
similar configurations, and leverages the authentication and authorization
services of the CiscoSecure Access Control Server. "
dovrebbe valere per un qualsiasi protocollo di comunicazione non solo per
ssh.
Oppure forse intendono che uno
cerca di collegarsi via web o ftp o telnet, digita la login e password per
accedere alla rete interna, ed a quel punto il suo ip viene autenticato e
puo' collegarsi con qualsiasi protocollo, anche diverso da quei tre (mah).
Insomma alla fine in linea di principio l'utente potrebbe collegarsi con
suo ssh client, o cvs client, o quel che gli pare, autenticarsi, e venire
"proxato" senza minimamente dover configurare niente sulla sua macchina.
Mi pare un po' troppo bello per essere vero.
Grazie mille per la risposta.
b.
 
 
 

Mi pare un po' troppo bello per essere vero.
Be', si puo' fare con iptables, non vedo perche' non si possa farlo a
colpi di Pix.


 piccolo script di autenticazione magari basato su database.
cercando e ricercando, e pure ciattando con un tizio nel canale cisco,  mi
e' parso di capire che il "virtual telnet" funziona esattamente come da te
descritto. Non ho capito se la stessa cosa, con un pix, si possa fare con una
connessione http invece che telnet (che dal punto di vista della sicurezza
e'  la stessa cosa, ma col browser sembra faccia piu' fine e  certi si
sentono piu' sicuri), ma quel che so comunque dovrebbe bastare.
Ancora grazie,
b.

 colpi di Pix.
Aggiungo la splendente interazione tra ssh (con tutte le sue
autenticazioni) e PF su OBSD...
Hola...
-- 
wash the blood from your hands
bury your secrets in the sand
and forget

 Gia': una simile feature sarebbe molto gradita con iptables/netfilter :)
Cosa fanno di bello pf e ssh insieme, su obsd?
Fabio


:Provate a guardare gli ingredienti del famoso Labello che si usa per
:le labbra screpolate: Butirrospermum Parkii (sperma di maiale).

 
http://www.openbsd.org/faq/pf/authpf.html
Aggeggio molto simpatico... pf ha della robetta molto interessante.
In questo caso, a prima vista, non mi sembrerebbe troppo difficile
fare una cosa simile anche usando netfilter, o no? Magari usando il
medesimo principio della shell di login che aggiunge una direttiva.
Per lo meno, mi sembra piu' semplice che implementare delle feature
tipo pfsync in netfilter :-)
Fabio invidioso

Interessantissimo anzicchenno.
Be', ma mi sembra si possa fare tranquillamente a colpi di roncola e
rule di iptables (pochissime le rule).
Questo se non mi sono bevuto il cervello.


 (devo averne aprlato anche su sikurezza, se non ricordo male)
Si, mi ricordo... gli avevo dato un'occhiata in seguito al tuo post e mi era
sembrato che fosse una feature molto specifica per LVS per garantire non gia
la ridondanza dei firewall, ma quella dei server dietro il master (o come si
chiama in LVS) usando una sola macchina come fw e come master. In pratica ti
consente di avere le gestione stateful delle connessioni anche quando il tuo
server "reale" cade ed un altro ne prende le veci (ma avevo dato uno sguardo
veloce e, in piu', non conosco bene LVS). 
Fabio

sentono piu' sicuri), ma quel che so comunque dovrebbe bastare.
Con un Pix non lo so, pero' con iptables si puo' fare -- anche usando
l'autenticazione Digest, cosi' le password non viaggiano in chiaro, o
(forse, penso di si' - se non si infuria coi certificati) SSL+Digest.
