Re: [LARTC] full policy routing

["Martin A. Brown" <mabrown-lartc@securepipe.com>]

 : what i have is an internal router that transports data from ten
 : different defined networks and of course "internet traffic". one of
 : these defined networks is our lan 192.168.1/24.
 :
 : the utopia that im trying to reach is that there is a routing table for
 : each and every one of these defined networks. these routing tables will
 : pretty much only say "192.168.1/24 is on eth1. drop all other traffic
 : that is not destined for 192.168.1/24". of course the table for
 : 192.168.1/24 will have routes for all of these networks plus a default
 : route to the internet. i then use rules for directing "from network x,
 : use table x". the main table will just have one route, to 192.168.1/24
 : so that "internet traffic" can get through.

I guess I can see why you'd want this, although I wouldn't recommend
relying on routing to enforce your security.  It can't hurt as an
additional measure, though.

I think you could make good use of the prohibit route.  In the example
script I just cooked up (see below), I have used a table whose sole
purpose is to return a prohibit route.  This way, you can use the RPDB to
perform a lookup for any route to any other network.  I'm not great at
algorithms, so I'm sure somebody else out there will have a better
suggestion for how to cheaply achieve the same end.  That said, you should
be able to define your networks in the $CONFIG file and have a bunch of
rules entered saying--you can't go here from there.

I think the big benefit here is that you are specifically "DENY"ing
traffic based on source and destination pairings.  This means you only
have to manage two routing tables, not number-of-networks tables.  The
main routing table is still used by all hosts, unless the RPDB suggests
looking up in table prohibit-table.

 : this is just for security, that a ipsec defined network cannot reach
 : the voIP network and so on, every network should just be able to reach
 : the lan.
 :
 : should this work? perhaps that was what you meant when you talked about
 : RPDB?

Yes.  Most definitely.

 : btw, seems like trouble shooting with policy routing isnt the easiest
 : ;x

Indeed.  It takes a bit of patience, tcpdump, printing out all of the
routing tables and the RPDB, and some patience.  But by remembering that
it's just a big stateless mechanism, you ease your burden.

Did I mention that it requires patience?

-Martin

# cat destinations
172.16.0.0/24          ipsec
172.17.108.0/24        voip
192.168.132.0/24       modempool
10.251.8.0/24          serverfarm
172.195.44.0/24        turnip
192.168.12.0/24        internal
10.49.85.0/24          ldapnet



#! /bin/bash
#
# -- populate some tables

CONFIGÞstinations

ALLNETS=$( awk '{print $1 }' $CONFIG )

ip rule show | grep -Ev '^(0|32766|32767):|iif lo' \
  | while read PRIO RULE; do
  ip rule del prio ${PRIO%%:*} $( echo $RULE | sed 's|all|0/0|' )
done

TABLES=/etc/iproute2/rt_tables

grep -q prohibit-table $TABLES || echo  249 prohibit-table >> $TABLES
ip route add prohibit default table prohibit-table

while read NETADDR NETNAME GARBAGE ; do
  #
  # -- cycle through all of the networks, adding prohibit routes
  #ot@piggles bonnedahl]#  ./maketables.sh
  for DEST in $ALLNETS ; do

    test $DEST = $NETADDR && continue
    ip rule add from $NETADDR to $DEST lookup prohibit-table

  done

done < $CONFIG

-- 
Martin A. Brown --- SecurePipe, Inc. --- mabrown@securepipe.com

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/