[Gllug] DHCP/Firewalls

[Alex Hudson]

On Thu, Aug 23, 2001 at 09:56:03PM +0200, Xander D Harkness wrote and Alex
snipped:
> Can we take this one stage further.
> 
> The Windows guys want to implement a firewall between the farm and the 
> rest of our network based on users and groups to keep our clients 
> outside the rest of our network. (Their thinking is that if they find an 
> 
> I would really like to solve this with Linux and I am sure that it is 
> possible, but I do not know enough about the information coming out of a 
> windows box.  ie does it give user or group info when running telnet?

Xander -that sounds pretty tough, and I would be amazed if there were a
linux solution (to do it properly). The nearest you might be able to get
would be some of the Citrix stuff - maybe they have something?

I think they key problem is recognising the user/group of the connection
(WTS isn't just telnet AFAIK ;). You have to either do this explicitly or
implicity. Explicitly will be damn tough - you will need something like a
WTS proxy server, running something like WinBIND, to get the appropriate
tokens for the user, and forward the connection based on the decision. I
know of no such software, I don't even know if WTS can be proxied.
Personally, though, I would say it's the 'correct' solution. Another
explicit method would be to make the user authenticate themselves in some
other way - i.e., a web page login - before they are able to access the
farm.

Implicit connections could be done a  number of ways. The goal is to tie the
client's user/group to a certain IP range, or something similar, so that by
running a simple firewall with the usual rules you are able to deduce user
and group. Perhaps the clients access the farm via a RAS server? The
authentication on the RAS could be used to select the IP address given to
their connection (NAT injection to network perhaps), and bingo, you can use
your standard tools (ipchains/tables, etc.). This would be a pretty good
solution too. 

On a slightly different topic: I personally lay out networks using large
ranges (depending on the network type, obviously - I'm not talking about
HANs here). The reasoning is to do with the various technology types. DHCP
is a core service, and not robust enough for my liking. Therefore, I
generally run a number of DHCP servers, on different platforms. Leases are
allocated long times, on large ranges, so that if a DHCP service fails it
doesn't need immediate attention: there are always plenty of leases
available. Obviously, each DHCP server needs a different lease range, and
generally I give them a class C-size each. Grouping these DHCP areas then,
gives roughly a class B network (you could be classless; harder math but
more efficient usage), and if you have a number of different networks
(geographically disparate offices in my case) you're routing between class
Bs, and may as well have a class A-size overall (10/8 for example). 

As for clashing: yep, that is something of a worry. However, it depends
which protocols you're using. FTP is obviously an arse, but most stuff will
work with a NAT network retarget. SMB/CIFS, dav, ssh, smtp, imap. Stuff
which doesn't work will proxy, as a rule. It sounds like hassle, but you
need a gateway to do the routing anyway, so you're only pushing the logic up
a few layers in the worst case (merging two networks). 

Cheers,

Alex.

--

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug