hello again martin, i sat down and kind of figured it out, all i have
to do now is to write some flashy bash script like you did ;)
this is what i got:
routing tables
main: all routes
prohibit: prohibit 0/0
rules
from defined1 -> 192.168.1/24 lookup main
from defined2 -> 192.168.1/24 lookup main
...
from definedN -> 192.168.1/24 lookup main
from 192.168.1/24 -> x lookup main
from x -> 192.168.1/24 lookup main
from x -> x lookup prohibit
where x here is an undefined network.
the thing is now to really get it straigh with the prio in the rules.
if you are able to, i would like a comment on it.
thanks,
tomas
On Tue, Feb 18, 2003 at 07:01:52PM -0600, Martin A. Brown wrote:
> : 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=destinations
>
> 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@xxxxxxx 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@xxxxxxxxxxxxxx
>
>
