Re: Authentication in a Firewall Question

Re: Authentication in a Firewall Question

[Cedric Blancher]

Le mer 25/08/2004 à 18:46, Hihn, Jason a écrit :
> I have devised the following acceptable scheme:
> A firewall that rejects all traffic to everyone, except for one port.
> This one port is used to authenticate an IP address through a
> challenge/response algorithm.
> If successful, the IP is then allowed through the firewall.

Si NuFW at http://www.nufw.org/. Theses guys have achieved quite
impressive work. You definitly must try this.


-- 
http://www.netexit.com/~sid/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help me spread!

RE: Authentication in a Firewall Question

[Daniel Chemko]

> A firewall that rejects all traffic to everyone, except for one port.
> This one port is used to authenticate an IP address through a
> challenge/response algorithm.
> If successful, the IP is then allowed through the firewall.
> After a period of idle time, the IP is removed from the allow table.

This one isn't well supported by many clients at this point. I was
looking into developing something to fix that, but it didn't happen.

> This seems like simple way to protect the box from script kiddies.
> Does anyone know of a product like this in existence?

pam_iptables is a nice tool, although it needs a little updating to
assign custom rules per/user, etc.. It requires that you have an open
out-of-band connection to a pam service on the firewall. This could be
SSH for instance. The plus is that installation is relatively straight
forward and you can use any authentication mechanism through PAM that
you see fit. The negative is that you're tied to keeping that pam
program open. Once the program is shutdown, the firewall rules close up.

Of course, Checkpoint has all of this integrated if you're willing to
spend serious cash for the functionality. Connect to telnet/etc.. type
username/password, then the rest is taken care of by daemons controlled
by the connection's policy. (Totalconnections, total bandwidth, timeout,
etc..)

RE: Authentication in a Firewall Question

[Eric Leblond]

On Wed, 2004-08-25 at 19:02, Daniel Chemko wrote:
> > A firewall that rejects all traffic to everyone, except for one port.
> This one port is used to authenticate an IP address through a
> 
> pam_iptables is a nice tool, although it needs a little updating to
> assign custom rules per/user, etc.. It requires that you have an open
> out-of-band connection to a pam service on the firewall.

NuFW is a PPL solution for Linux that provide out-of-band user
authentication. More informations available at :
	http://www.nufw.org

BR,
-- 
Eric Leblond <eric@inl.fr>
INL

Re: Authentication in a Firewall Question

[Nicolás Velásquez O.]

Hello there,

I'm trying to do something similar.

When an enduser tries to go to Internet, the browser is redirected to an 
authentication page, then the webserver that contains that page inserts 
a rule in the firewall to allow that computer to go to Internet.

It must be something like this, as no programs should be installed on 
the enduser's machine.

What I was trying to do (without success) was, set a redirector policy 
that applies to the unauthenticated traffic. The thing is that 
redirection and dynamic nat are defined on different rules (PREROUTING, 
POSTROUTING). This is if I'm working with nat, I haven't thought of a 
way to require authentication when just routing.

Some of the things I'm trying:
## redirector
$IPTABLES -t nat -A PREROUTING -i $LAN_IFACE -p TCP --destination-port 
80 -j REDIRECT --to-port 81 # The web server listens on port 81

## insert rule for each client
$IPTABLES -t nat -I POSTROUTING -o $INTERNET_IFACE -m mac --mac-source 
$CLIENT_MAC -j MASQUERADE


Any thoughts are welcome.


El Mié 25 Ago 2004 11:50, Cedric Blancher escribió:
> Le mer 25/08/2004 à 18:46, Hihn, Jason a écrit :
> > I have devised the following acceptable scheme:
> > A firewall that rejects all traffic to everyone, except for one
> > port. This one port is used to authenticate an IP address through a
> > challenge/response algorithm.
> > If successful, the IP is then allowed through the firewall.
>
> Si NuFW at http://www.nufw.org/. Theses guys have achieved quite
> impressive work. You definitly must try this.

-- 

Atentamente,
Nicolás Velásquez
Bogotá, Colombia

(^)   ASCII Ribbon Campaign
 X    NO HTML/RTF in e-mail
/ \   NO Word docs in e-mail

RE: Authentication in a Firewall Question

[Jason Opperisano]

> Hello there,
>
> I'm trying to do something similar.
>
> When an enduser tries to go to Internet, the browser is redirected to an
> authentication page, then the webserver that contains that page inserts
> a rule in the firewall to allow that computer to go to Internet.
>
> It must be something like this, as no programs should be installed on
> the enduser's machine.
>
> What I was trying to do (without success) was, set a redirector policy
> that applies to the unauthenticated traffic. The thing is that
> redirection and dynamic nat are defined on different rules (PREROUTING,
> POSTROUTING). This is if I'm working with nat, I haven't thought of a
> way to require authentication when just routing.
>
> Some of the things I'm trying:
> ## redirector
> $IPTABLES -t nat -A PREROUTING -i $LAN_IFACE -p TCP --destination-port
> 80 -j REDIRECT --to-port 81 # The web server listens on port 81
>
> ## insert rule for each client
> $IPTABLES -t nat -I POSTROUTING -o $INTERNET_IFACE -m mac --mac-source
> $CLIENT_MAC -j MASQUERADE
>
>
> Any thoughts are welcome.

i did this for a hotel:

  iptables -t nat -A PREROUTING -i $LAN_IFACE -p tcp --syn --dport 80 -j authenticated
  iptables -t nat -A PREROUTING -i $LAN_IFACE -p tcp --syn --dport 80 -j REDIRECT --to-port 81

  iptables -N authenticated

as people authenticate, add rules to the "authenticated" chain like:

  iptables -A authenticated -s x.y.w.z -j ACCEPT

the performance hit was that the initial SYN of an HTTP request of an authenticated client had to go through every single other authenticated IP before it matched (this example was a class C, so 253 other rules).  i tested it with 500 rules in the authenticated chain and didnt see much of any performance hit...YMMV.

-j