Shorewall users - Jul 2003 - Using shorewall in conjunction with NoCatAuth

I am going to attempt to implement the NoCatAuth authentication system
for wireless networks (and other public networks) on the same machine
running shorewall. Before I attempt this, I was wondering if anyone had
already attempted this and either succeeded or failed? As NoCatAuth
seems to enjoy being in control of the firewall rules, I can see this
being challenging. Any ideas?

John

On Wed, 2003-07-09 at 15:23, John Laur wrote:
> I am going to attempt to implement the NoCatAuth authentication system
> for wireless networks (and other public networks) on the same machine
> running shorewall. Before I attempt this, I was wondering if anyone had
> already attempted this and either succeeded or failed? As NoCatAuth
> seems to enjoy being in control of the firewall rules, I can see this
> being challenging. Any ideas?
> 
I suspect that NoCatAuth will blindly want to add/delete rules from the
filter table''s FORWARD chain. That will bypass a lot of
Shorewall''s
capabilities.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

On Wed, 2003-07-09 at 15:41, Tom Eastep wrote:
> > 
> 
> I suspect that NoCatAuth will blindly want to add/delete rules from the
> filter table''s FORWARD chain. That will bypass a lot of
Shorewall''s
> capabilities.
John,

A google search of Shorewall+NocatAuth turns up a cached page describing
the installation of a person in Singapore that is using Shorewall
together with NoCatAuth.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

> A google search of Shorewall+NocatAuth turns up a cached page
describing
> the installation of a person in Singapore that is using Shorewall
> together with NoCatAuth.
Yeah, I had seen that but unfortunately it didn''t really have details.
Anyway, at least I know it was going to be possible, so I started
working on it.
> > I suspect that NoCatAuth will blindly want to add/delete rules from
the
> > filter table''s FORWARD chain. That will bypass a lot of
Shorewall''s
> > capabilities.
It does. It''s designed to manage the whole firewall configuration. The
commands are configurable though, so you can change all the firewall
hooks by just writing replacements. I have most of NoCat''s
functionality
working via a combination of a few shorewall rules and a new simple
shorewall.fw command for NoCatAuth. It was really easier than I
expected, and I know a lot more about Linux IP tables and chains than I
did this afternoon! Once I can get some more of the things implemented,
I''ll put together a HOWTO.

Here is my current problem (before I figure out how to implement
NoCat''s
account classes with shorewall):

I can''t figure out how to kill any connections left open after logging
out of NoCatAuth.. IE if I boot my wireless client, log in via
NoCatAuth, ssh somewhere, then log out, my ssh will continue to work.
The connection is still tracked (I can see it with `shorewall show
connections`). Is there a command that basically says "abort all
connections with this source IP?"

John

Here I go replying to myself again, but I have made some progress...
> I can''t figure out how to kill any connections left open after
logging
> out of NoCatAuth.. IE if I boot my wireless client, log in via
> NoCatAuth, ssh somewhere, then log out, my ssh will continue to work.
> The connection is still tracked (I can see it with `shorewall show
> connections`). Is there a command that basically says "abort all
> connections with this source IP?"
I found the utility ''cutter'' at http://www.lowth.com/cutter/
that does
exactly this - properly! I am surprised it''s not already part of
NoCatAuth or otherwise distributed with the standard firewall tools. It
is highly useful for this purpose and it works VERY well. It can match
by source ip, destination ip, port, or a combination of any.

Now I am on to packet marking for the different NoCatAuth user classes
(Owner, Member, Public) - and I am trying to figure out how best to
integrate it with shorewall.  NoCatAuth sets a MARK on authenticated
users packets in its own "NoCat" mangle chain. It marks with different
values based on the user type. I can use the same marking technique to
integrate with shorewall, but which chain behind the scenes should get
the rules? Would you suggest using tcpre or pretos or creating a new
chain entirely for these rules and add it to PREROUTING?

I would like to be able to set rules for policy based routing based on
the MARK value other than traffic shaping (IE allowing port 25 to
Members but not Public or allowing access to my wired subnet to Owners
but not Members or Public, etc.) Is there a facility to do this in the
current shorewall implementation or would the rules have to be crafted
manually?

If I can get this last thing working right, then I can chalk this one up
and get the HOWTO written :)

Thanks,
John

On Wed, 9 Jul 2003 22:04:00 -0500, John Laur <johnl@blurbco.com> wrote:

>
> Here is my current problem (before I figure out how to implement
NoCat''s
> account classes with shorewall):
>
> I can''t figure out how to kill any connections left open after
logging
> out of NoCatAuth.. IE if I boot my wireless client, log in via
> NoCatAuth, ssh somewhere, then log out, my ssh will continue to work.
> The connection is still tracked (I can see it with `shorewall show
> connections`). Is there a command that basically says "abort all
> connections with this source IP?"
>
No, although there has been much discussion in this area on the Netfilter 
lists.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://www.shorewall.net
Washington USA  \ teastep@shorewall.net

> > Here is my current problem (before I figure out how to implement
NoCat''s
> > account classes with shorewall):
> >
> > I can''t figure out how to kill any connections left open
after
logging
> > out of NoCatAuth.. IE if I boot my wireless client, log in via
> > NoCatAuth, ssh somewhere, then log out, my ssh will continue to
work.
> > The connection is still tracked (I can see it with `shorewall show
> > connections`). Is there a command that basically says "abort all
> > connections with this source IP?"
> 
> No, although there has been much discussion in this area on the
Netfilter
> lists.
I replied to myself on this last night -- I don''t know if it got to the
list properly though as I never got a copy back.. Anyway, here it is
again (sorry if this is a dupe post)

I found the utility ''cutter'' at http://www.lowth.com/cutter/
that does
exactly this - properly! I am surprised it''s not already part of
NoCatAuth or otherwise distributed with the standard firewall tools. It
is highly useful for this purpose and it works VERY well. It can match
by source ip, destination ip, port, or a combination of any.

Now I am on to packet marking for the different NoCatAuth user classes
(Owner, Member, Public) - and I am trying to figure out how best to
integrate it with shorewall.  NoCatAuth sets a MARK on authenticated
users packets in its own "NoCat" mangle chain. It marks with different
values based on the user type. I can use the same marking technique to
integrate with shorewall, but which chain behind the scenes should get
the rules? Would you suggest using tcpre or pretos or creating a new
chain entirely for these rules and add it to PREROUTING?

I would like to be able to set rules for policy based routing based on
the MARK value other than traffic shaping (IE allowing port 25 to
Members but not Public or allowing access to my wired subnet to Owners
but not Members or Public, etc.) Is there a facility to do this in the
current shorewall implementation or would the rules have to be crafted
manually?

The tcrules file has this little bit that got my hopes up:
#       Entries in this file cause packets to be marked as a means of
#       classifying them for traffic control or policy routing.

If there is no method to actually define policy based rules, perhaps I
could institute some ''fake'' zones for the user classes - I am
thinking
that this could cause shorewall to create the rule chains but never use
them. I could then have NoCatAuth add rules that sent a users packets
into the other zones chains for rule processing rather than using MARK
and matching packets (plus iptables wouldn''t be doing double duty on
the
packets) Would this be a better approach? - or does shorewall have a
rule definition capable of doing the equivalent of dynamically changing
a packet''s source zone?

If I can get this last thing working right, then I can chalk this one up
and get the HOWTO written :)

John

On Thu, 2003-07-10 at 12:12, John Laur wrote:
> 
> Now I am on to packet marking for the different NoCatAuth user classes
> (Owner, Member, Public) - and I am trying to figure out how best to
> integrate it with shorewall.  NoCatAuth sets a MARK on authenticated
> users packets in its own "NoCat" mangle chain. It marks with
different
> values based on the user type. I can use the same marking technique to
> integrate with shorewall, but which chain behind the scenes should get
> the rules? Would you suggest using tcpre or pretos or creating a new
> chain entirely for these rules and add it to PREROUTING?
My recommendation would actually be to use dynamic zones and to add
users dynamically to the zone with they authenticate. Not sure if this
integrates will with ''cutter'' however.

The reason that I like dynamic zones is that the zone membership is
automatically restored by shorewall during a "shorewall restart"; with
any other scheme, you have to take responsibility for re-establishing
all of your dynamic rules yourself.
> 
> I would like to be able to set rules for policy based routing based on
> the MARK value other than traffic shaping (IE allowing port 25 to
> Members but not Public or allowing access to my wired subnet to Owners
> but not Members or Public, etc.) Is there a facility to do this in the
> current shorewall implementation or would the rules have to be crafted
> manually?
> 
> The tcrules file has this little bit that got my hopes up:
> #       Entries in this file cause packets to be marked as a means of
> #       classifying them for traffic control or policy routing.
> 
> If there is no method to actually define policy based rules, perhaps I
> could institute some ''fake'' zones for the user classes -
I am thinking
> that this could cause shorewall to create the rule chains but never use
> them. I could then have NoCatAuth add rules that sent a users packets
> into the other zones chains for rule processing rather than using MARK
> and matching packets (plus iptables wouldn''t be doing double duty
on the
> packets) Would this be a better approach? - or does shorewall have a
> rule definition capable of doing the equivalent of dynamically changing
> a packet''s source zone?
> 
Again, Dynamic zones do that for you. They were created to be used for
different classes of IPSEC roadwarriors and are therefore described in
the IPSEC Shorewall documentation. They should also work fine for
different classes of authenticated wireless clients.

-Tom
-- 
Tom Eastep    \ Shorewall - iptables made easy
Shoreline,     \ http://shorewall.net
Washington USA  \ teastep@shorewall.net

> My recommendation would actually be to use dynamic zones and to add
> users dynamically to the zone with they authenticate. Not sure if this
> integrates will with ''cutter'' however.
''cutter'' doesn''t care about this -- it just looks at
the ip_conntrack
table for matching IP''s or ports based on what you want to terminate
and
then sends RST packets both ways using raw packets and thus bypassing
all iptables rules. After I found it and tested it yesterday, I have
already put it out on five of my firewalls where it would have been
enormously useful in the past. We''ll see how the mileage gets out of it
> The reason that I like dynamic zones is that the zone membership is
> automatically restored by shorewall during a "shorewall restart";
with
> any other scheme, you have to take responsibility for re-establishing
> all of your dynamic rules yourself.
Cool! This is a feature that NoCatAuth doesn''t even provide internally
and I was wondering if it might be possible.
> Again, Dynamic zones do that for you. They were created to be used for
> different classes of IPSEC roadwarriors and are therefore described in
> the IPSEC Shorewall documentation. They should also work fine for
> different classes of authenticated wireless clients.
I will definitely look at this. I guess I missed it because I never
looked at the IPSEC stuff.. It will greatly simplify the entire process
as I can just create four zones to handle different user types and not
have to set any iptables rules with NoCatAuth itself!

1) Users not yet authenticated
2) Guest users (restricted access via authentication or tos
click-through)
3) Member users (authenticated via authentication)
4) Owner/Admin users (full, unrestricted priority access)

Thanks again!

John