Mailing List Archive

The normal apologies for the noobie-type question...

We have IPCop nicely segregating our orange (DMZ) and green (blocked) LANs.
As time has gone on, I've realized that I'd like many more of our services
to be on the orange or red networks so they can be easily reached by
customers/consultants who may not have fixed IPs. Many of our users are not
SSH savvy and might not want us installing a tunneling client on their
systems.

Most of these services that I want to expose have some form of
authentication but some of that is not terribly robust (mediawiki, mysql,
bugzilla). Some are targets for DoS (SQL Server) or other attacks.

My thoughts are to have a strong challenge/response login from a client to
the firewall. This could be done via https to a non-standard port on the
firewall. If this login succeeded, all (or configurable) ports would be
available from the client to services inside the firewall as long as the
'session' was active. The session would be based on the client's IP and
would have an inactivity time-out. The original https login would not need
to stay active.

Valid user logins could be either via statically configured tables on the
firewall or via LDAP, etc.

I think I remember a scheme like this when I was using the Wingate proxy
server. Is this available using iptables?

On 8/27/2007 9:45 AM, quesera2 wrote:
> My thoughts are to have a strong challenge/response login from a
> client to the firewall. This could be done via https to a
> non-standard port on the firewall. If this login succeeded, all (or
> configurable) ports would be available from the client to services
> inside the firewall as long as the 'session' was active. The session
> would be based on the client's IP and would have an inactivity
> time-out. The original https login would not need to stay active.

Ok, seems close to reasonable enough. I'm not sure that the web page
needs to be on a standard port or that it even should be if you are
trying to make this idiot proof. I personally do not see any reason why
the page(s) in question can not be on standard port 80. You may or may
not want to use HTAccess or the likes to protect the login page its
self. This would provide a two factor login with HTAccess and your
authentication page(s).

> Valid user logins could be either via statically configured tables on
> the firewall or via LDAP, etc.

I'd say that you would want to use a combination of both and / or one
derived from the other. Here are some things that I could consider if
designing such a system.
- Jump to a sub-chain to do the conditional checks.
- Possibly have a sub-chain for each authenticating user.
- Use a match extension that will react based on time.
- Time match extension from Patch-O-Matic-NG
- Recent match extension
- Use the comment match extension to put a label in rules.

I don't think I would have the authentication page(s) edit your firewall
directly, just think what could happen if someone managed to find an
exploit in your authentication page(s). Rather I would have the
authentication page(s) queue change requests that include authenticating
party's credentials, requested change(s), authentication page /
mechanism credentials that is requesting the change(s) on behalf of the
authenticating party, and last but not least, a checksum. I would
probably be tempted to encrypt the request as well. There is no reason
that the authentication page(s) can not validate the credentials and the
requested change to report feedback to the requesting party immediately.
However I would double check any and all queued change requests for
obvious security reasons. I might even make the change requests only
good for a specific length of time. That is to say that a change
request is only valid for a few minutes (queue cycle), even if the
requested change would be valid for longer than that. This should help
prevent replay attacks with your queued change requests.

With the above security out of the way the problem is now down to what
option(s) do you want the page(s) to present to the authenticating party.

> I think I remember a scheme like this when I was using the Wingate
> proxy server. Is this available using iptables?

IPTables is a low level filtering structure, not a higher level
management system. You can easily create a management system around /
on top of IPTables though.



Grant. . . .

On 8/28/2007 11:59 PM, Grant Taylor wrote:
> - Use the comment match extension to put a label in rules.

The comment match extension will allow you to put a machine parse able
tag with in the body of each rule so that you could fairly easily have a
machine parse the (sub)chain and identify rules that needed to be
deleted so that your (sub)chain would not grow to be unwieldy.



Grant. . . .