Child proofing...

Child proofing...

[Guillaume Marcais]

We have remote routers that we access with ssh. Sometime, I am 
not careful enough and I enter stupid routing information that not only 
leaves our clients connectionless but also prevents me from accessing the 
router. Then truck roll, long downtimes and angry customers... I am really a 
child sometimes :)

The idea was to be able to have access to ssh (almost) no matter what I do to 
the main routing table. Even something like: ip route del default. I thought 
of doing it with policy routing with something like the following:

(Let's assume the router has eth0 with 192.168.0.2/24 as its main gateway 
interface).

ip rule add fwmark 1 table sshtable
ip route add 192.168.0.0/24 dev eth0 table sshtable
ip route add default via 192.168.0.1 dev eth0 table sshtable
iptables -I PREROUTING -t mangle -p tcp -d 192.168.0.2 --destination-port ssh 
-j MARK --set-mark 1
iptables -I OUTPUT -t mangle -p tcp -s 192.168.0.2 --source-port ssh -j MARK 
--set-mark 1

Basically, the traffic to/from the ssh daemon uses a separate routing table, 
which I won't tamper with on a regurlar basis.

Alas, it doesn't work. If I do the following: 

ip route del 192.168.0.0/24 dev eth0

I cannot access ssh anymore. The netfilter Hacking howto tells us that: "The 
NF_IP_LOCAL_OUT [5] hook is called for packets that are created locally. Here 
you can see that routing occurs after this hook is called: in fact, the 
routing code is called first [...]". So the routing is called first, which 
fails with the main table and the packet is drop before being marked by 
netfilter and routed according to the sshtable...

Anybody has any idea on how to work aroung this?

Guillaume.

PS: in all fairness, the howto suggest to " alter the `skb->dst' field 
yourself, as is done in the NAT code". But I would like to avoid to write a 
kernel module if possible.

Re: Child proofing...

[Antony Stone]

On Thursday 07 November 2002 7:53 pm, Guillaume Marcais wrote:

> We have remote routers that we access with ssh. Sometime, I am
> not careful enough and I enter stupid routing information that not only
> leaves our clients connectionless but also prevents me from accessing the
> router. Then truck roll, long downtimes and angry customers... I am really
> a child sometimes :)

I recommend you set up an auto-answer modem connected to the serial port of 
the router.   If the router is a Linux box, installing an internal modem may 
be cheaper or more convenient.

Antony.

-- 

This email is intended for the use of the individual addressee(s) named above 
and may contain information that is confidential, privileged or unsuitable 
for overly sensitive persons with low self-esteem, no sense of humour, or 
irrational religious beliefs.

If you have received this email in error, you are required to shred it 
immediately, add some nutmeg, three egg whites and a dessertspoonful of 
caster sugar.   Whisk until soft peaks form, then place in a warm oven for 40 
minutes.   Remove promptly and let stand for 2 hours before adding some 
decorative kiwi fruit and cream.   Then notify me immediately by return email 
and eat the original message.

Re: Child proofing...

[Nick Drage]

On Sat, Nov 09, 2002 at 02:37:45PM +0000, Antony Stone wrote:
> On Thursday 07 November 2002 7:53 pm, Guillaume Marcais wrote:
> 
> > We have remote routers that we access with ssh. Sometime, I am not
> > careful enough and I enter stupid routing information that not only
> > leaves our clients connectionless but also prevents me from accessing
> > the router. Then truck roll, long downtimes and angry customers... I am
> > really a child sometimes :)
> 
> I recommend you set up an auto-answer modem connected to the serial port of 
> the router.   If the router is a Linux box, installing an internal modem may 
> be cheaper or more convenient.

Sorry to act like an echo, but seconded - as long as you've got some kind of
Caller Line Identification restrictions on the modem.

Or a "console server" or similar, a seperate host you can access regardless
of the changes to the router's configuration that gives you a serial
connection to the host.

Or have a working minimal configuration that permits you to have remote
access.  Then before you make a change use an "at" job or similar to bring
that working configuration up in five minutes unless you can ssh in and stop
it... that way you know you'll be able to get back into the router to have
another crack at the problem.

-- 
FunkyJesus System Administration Team