Advanced Security Question

Please forgive me if this is either a stupid question or will only be
available sometime in the late 24th century. Here goes...

Does anyone know how I would set a switched network to direct ALL
traffic through a linux box for authorisation, authentication, IDS and
logging. I could use RADIUS, but I've heard there are some flaws with
it.

Basically this box is going to check every packet on the network, log
it, check for "unwanted" activity and/or authorise it. It's going to
be acting in a super cop role, between clients, secure servers,
unsecure servers and Internet connection via firewall. Yes - it's a
firewall and DMZ, but to a greater extent.

I want any new machines to be denied access to anything until they are
authorised. I also want to stop all traffic between clients, unless
through the linux box.

Would IP tables on clients, servers and linux authentication box be
able to do this? Client Ip tables only allow traffic to
authentication server. Server Ip tables only allow traffic between
authorised servers and authentication server. Authentication server
only allow authorised traffic between itself and client/servers
(server traffic dependant upon server role). This sounds logical, but
could it be done?

Hammer

Hammer wrote:

>
> Does anyone know how I would set a switched network to direct ALL
> traffic through a linux box for authorisation, authentication, IDS and
> logging. I could use RADIUS, but I've heard there are some flaws with
> it.
>

No - that's *routing* not switching.

If your network is large enough to require switching, even if you could
monitor all the traffic, you'll have a problem dealing with the capacity
unless you have a whole bank of machines just listening for activity. If
you want to run packet sniffing across the network you'll need to tap every
segment.

For authorization/authentication is doesn't matter whether its
switched/routed/bradcast. Use what works / solves your problems / is
manageable by you.

C.

On 2004-08-12, Hammer <hammeraus001@yahoo.com> wrote:
> Please forgive me if this is either a stupid question or will only be
> available sometime in the late 24th century. Here goes...
>
well we all go through this phase....today is your turn :P

> Does anyone know how I would set a switched network to direct ALL
> traffic through a linux box for authorisation, authentication, IDS and
> logging. I could use RADIUS, but I've heard there are some flaws with
> it.
>
> Basically this box is going to check every packet on the network, log
> it, check for "unwanted" activity and/or authorise it. It's going to
> be acting in a super cop role, between clients, secure servers,
> unsecure servers and Internet connection via firewall. Yes - it's a
> firewall and DMZ, but to a greater extent.
>
Its already been mentioned that what you are after is _routing_ and not doing
things by just plugging things into a switch and hoping it all goes through
that.

In practice you have two options in a _switched_ environment, one takes a
passive role whilst the other takes the active one:

passive:
--------
if you have a fancy switch it probably will have something called a 'mirror'
port which more or less shunts all the traffic from the other ports in a hub
fashion down it, this would enable you to run snort and do monitoring of the
network however you would be unable to do anything 'active'

active:
-------
tricky to pull off but it called 'arp poisioning', you can get a rough idea
of it by using 'ettercap'. You corrupt the ARP tables of the remote machines
to pass the traffic to you and then your machine forwards the ethernet
packets after it has finished with them. This _will_ be a custom job, I only
know of man-in-the-middle versions of this (a la ettercap) and nothing that
would scale/work for more than a single host.

The one thing you are forgetting (again pointed out in the other posting) is
that you will need a box for every 'x' number of hosts affectively....which
obviously can get out of hand.

I guess another approach would be to make a switch out of linux with a bank
of ethernet cards (one NIC port for each host, hmmm quad cards anyone?) and
plug everyone into that with the linux central box in 'ethernet bridge mode'.

> I want any new machines to be denied access to anything until they are
> authorised. I also want to stop all traffic between clients, unless
> through the linux box.
>
All I can do to suggest is you VPN *every* machine to the central host (which
is going to do the monitoring/firewalling) and dish out certificates to each
machine to 'authorise' them. Any non-VPN traffic on *every* host is then

Not what I would call a difficult thing to pull off, just simply stupid :)

In summary, its a stupid thing to try and pull off. You have not given us
reasons why you need to do this (do you not trust the client machines being
plugged in?) for us to suggest a better, more scaliable and sensible
approach.

Have fun

Alex

Hammer dedi ki:

> Please forgive me if this is either a stupid question or will only be
> available sometime in the late 24th century. Here goes...
>
> Does anyone know how I would set a switched network to direct ALL
> traffic through a linux box for authorisation, authentication, IDS and
> logging. I could use RADIUS, but I've heard there are some flaws with
> it.
>
> Basically this box is going to check every packet on the network, log
> it, check for "unwanted" activity and/or authorise it. It's going to
> be acting in a super cop role, between clients, secure servers,
> unsecure servers and Internet connection via firewall. Yes - it's a
> firewall and DMZ, but to a greater extent.
>
> I want any new machines to be denied access to anything until they are
> authorised. I also want to stop all traffic between clients, unless
> through the linux box.

As an addition to Alexander's arp solution, it might also be possible to
setup clients so that they won't respond to arp queries. Then you could
manually build the arp table, in init-scripts, of the "cop" server
inserting all clients in it. And additionally you setup the server to
proxy-arp all clients. The result is, all arp queries would be replied
(proxied) by server, pointing to its own mac address, then incoming
traffic would be processed through by iptables (with your "cop" programs
in the chain), and then would be forwarded to the real destination client.
The trick is, how to implement an arp table (on server) so that it will
advertise its own mac address e.g. for an arp query of client
192.168.100.100 and then use the real mac address of that client when it
comes to forward the processed packet: In the former case your server's
arp table should be associating 192.168.100.100 (destination client) with
its own mac address, but in the latter case the same arp table should be
associating 192.168.100.100 with the destination client's real mac
address. Unless you can find a solution to this, I guess this suggestion
of mine is no more than a fantasy.

There might be another way not mentionaed so far: Setup your DHCP server
so that all the clients are given a different subnet each, while the "cop"
routing server is on an umbrella network that comprises of all those
subnets. Then, no client will be on the same subnet with each other, but
all of them will be on the same network with the routing server. So they
cannot talk to each other directly, but only through routing by the server.

Example:
Routing server : 10.1.x.1/8 (N aliased host addresses for N clients) or,
10.1.x.1/24 (N aliased net addresses for N clients)
Clients: 10.1.x.100/24 (different x for each client)

Could be it possible to devise a solution that doesn't need a lot of
aliases on the routing server? Maybe, I don't know.

--
Abdullah | aramazan@ |
Ramazanoglu | myrealbox |
________________| D-O-T cöm |

Abdullah Ramazanoglu dedi ki:
> Hammer dedi ki:

--8<--

> The trick is, how to implement an arp table (on server) so that it will
> advertise its own mac address e.g. for an arp query of client
> 192.168.100.100 and then use the real mac address of that client when it
> comes to forward the processed packet: In the former case your server's
> arp table should be associating 192.168.100.100 (destination client) with
> its own mac address, but in the latter case the same arp table should be
> associating 192.168.100.100 with the destination client's real mac
> address. Unless you can find a solution to this, I guess this suggestion
> of mine is no more than a fantasy.

Eureka! (well, sort of :)
It is the "-i" (interface) option to arp command. Use two NICs on the
routing server, one to proxy-arp, associating client IP addresses with the
mac address of this NIC, which will receive incoming traffic from clients.
The other NIC is for outgoing traffic to clients, with arp table entries
associating each client with their real mac addresses. If you use a 3rd
NIC for internet / DMZ etc, then a single default route won't suffice, and
you would also need to setup a static -network- route for the clients.

Does "arp -i" provide for the same -client- IP address appear twice in the
arp table, based on different interfaces? I think it should. Worth a try.

--
Abdullah | aramazan@ |
Ramazanoglu | myrealbox |
________________| D-O-T cöm |

On 11 Aug 2004 18:20:52 -0700, Hammer <hammeraus001@yahoo.com> wrote:
> Please forgive me if this is either a stupid question or will only be
> available sometime in the late 24th century. Here goes...

> Does anyone know how I would set a switched network to direct ALL
> traffic through a linux box for authorisation, authentication, IDS and
> logging. I could use RADIUS, but I've heard there are some flaws with
> it.

> Basically this box is going to check every packet on the network, log
> it, check for "unwanted" activity and/or authorise it. It's going to
> be acting in a super cop role, between clients, secure servers,
> unsecure servers and Internet connection via firewall. Yes - it's a
> firewall and DMZ, but to a greater extent.

> I want any new machines to be denied access to anything until they are
> authorised. I also want to stop all traffic between clients, unless
> through the linux box.

> Would IP tables on clients, servers and linux authentication box be
> able to do this? Client Ip tables only allow traffic to
> authentication server. Server Ip tables only allow traffic between
> authorised servers and authentication server. Authentication server
> only allow authorised traffic between itself and client/servers
> (server traffic dependant upon server role). This sounds logical, but
> could it be done?

One way to do this: get rid of the network switch and use a linux
system as the switch. It would have to have as many ethernet ports as
the original switch, and you'd need a specialized iptables and other
software, but it could be done.

Alternatively, get a network switch that allows all of what you need.
Perhaps some high-end Cisco or HP Procurve switch? Or perhaps a
WatchGuard or other firewall/vpn/security switch?

I think you'll find it difficult to control the entire network's
traffic unless you do it at the switch.

--
Dale Dellutri <ddelQQQlutr@panQQQix.com> (lose the Q's)

On 11 Aug 2004 18:20:52 -0700, Hammer <hammeraus001@yahoo.com> wrote:
> Would IP tables on clients, servers and linux authentication box be
> able to do this? Client Ip tables only allow traffic to
> authentication server. Server Ip tables only allow traffic between
> authorised servers and authentication server. Authentication server
> only allow authorised traffic between itself and client/servers
> (server traffic dependant upon server role). This sounds logical, but
> could it be done?

We do something like this. I work at a small college, and we have all the
student network traffic copied and sent to a mirrored port on our core
Extreme BlackDiamond, which is plugged into a Linux machine with Etherape
running. We can then do packet captures when we have network problems, and
track down the hosts that are spewing ung*dly amounts of network traffic
(as is inevitably the case). It works pretty well, although we're moving to
a solution involving NetSquid, which will interface with the Dell
PowerConnects in the dorms so we can get a look at traffic even closer to
the source. We're still in the prototyping stage for NetSquid, so I can't
say much about other than it looks cool.

--
-- Skylar Thompson (skylar@os2.dhs.org)
-- http://www.os2.dhs.org/~skylar/

Alexander,

We are a hospital in the process of planning an upgrade of the
network. The upgrade will probably include thin clients (getting
linux image by TFTP) and wireless.

So basically, what we want to do is reduce the risk (as far as
possible) of any unauthorised interaction between any clients/servers.
We want to control all of the traffic on the network to the point and
only allow certain traffic from source to destination.

I know it sounds bizarre, but in terms of security & healthcare, you
can't go too far.

Thanks to everyone who has posted responses, I'll look further into
them.

Hammer

Alexander Clouter <alex@digriz.junk-this.org.uk> wrote in message news:<411d068d$1_2@127.0.0.1>...
> On 2004-08-12, Hammer <hammeraus001@yahoo.com> wrote:
> > Please forgive me if this is either a stupid question or will only be
> > available sometime in the late 24th century. Here goes...
> >
> well we all go through this phase....today is your turn :P
>
> > Does anyone know how I would set a switched network to direct ALL
> > traffic through a linux box for authorisation, authentication, IDS and
> > logging. I could use RADIUS, but I've heard there are some flaws with
> > it.
> >
> > Basically this box is going to check every packet on the network, log
> > it, check for "unwanted" activity and/or authorise it. It's going to
> > be acting in a super cop role, between clients, secure servers,
> > unsecure servers and Internet connection via firewall. Yes - it's a
> > firewall and DMZ, but to a greater extent.
> >
> Its already been mentioned that what you are after is _routing_ and not doing
> things by just plugging things into a switch and hoping it all goes through
> that.
>
> In practice you have two options in a _switched_ environment, one takes a
> passive role whilst the other takes the active one:
>
> passive:
> --------
> if you have a fancy switch it probably will have something called a 'mirror'
> port which more or less shunts all the traffic from the other ports in a hub
> fashion down it, this would enable you to run snort and do monitoring of the
> network however you would be unable to do anything 'active'
>
> active:
> -------
> tricky to pull off but it called 'arp poisioning', you can get a rough idea
> of it by using 'ettercap'. You corrupt the ARP tables of the remote machines
> to pass the traffic to you and then your machine forwards the ethernet
> packets after it has finished with them. This _will_ be a custom job, I only
> know of man-in-the-middle versions of this (a la ettercap) and nothing that
> would scale/work for more than a single host.
>
> The one thing you are forgetting (again pointed out in the other posting) is
> that you will need a box for every 'x' number of hosts affectively....which
> obviously can get out of hand.

>
> I guess another approach would be to make a switch out of linux with a bank
> of ethernet cards (one NIC port for each host, hmmm quad cards anyone?) and
> plug everyone into that with the linux central box in 'ethernet bridge mode'.
>
> > I want any new machines to be denied access to anything until they are
> > authorised. I also want to stop all traffic between clients, unless
> > through the linux box.
> >
> All I can do to suggest is you VPN *every* machine to the central host (which
> is going to do the monitoring/firewalling) and dish out certificates to each
> machine to 'authorise' them. Any non-VPN traffic on *every* host is then
>
> Not what I would call a difficult thing to pull off, just simply stupid :)
>
> In summary, its a stupid thing to try and pull off. You have not given us
> reasons why you need to do this (do you not trust the client machines being
> plugged in?) for us to suggest a better, more scaliable and sensible
> approach.
>
> Have fun
>
> Alex