From: Tomas Bonnedahl <tomas@yes.nu>
To: lartc@vger.kernel.org
Subject: Re: [LARTC] full policy routing
Date: Wed, 19 Feb 2003 16:58:36 +0000 [thread overview]
Message-ID: <marc-lartc-104567401507895@msgid-missing> (raw)
In-Reply-To: <marc-lartc-104558134019449@msgid-missing>
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Þ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/
next prev parent reply other threads:[~2003-02-19 16:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2003-02-18 15:14 [LARTC] full policy routing Tomas Bonnedahl
2003-02-18 15:26 ` Martin A. Brown
2003-02-18 16:02 ` Tomas Bonnedahl
2003-02-18 16:46 ` Martin A. Brown
2003-02-18 21:01 ` Tomas Bonnedahl
2003-02-19 1:01 ` Martin A. Brown
2003-02-19 16:58 ` Tomas Bonnedahl [this message]
2003-02-20 4:43 ` Martin A. Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=marc-lartc-104567401507895@msgid-missing \
--to=tomas@yes.nu \
--cc=lartc@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.