Re: Resolved: locking oneself out, unroutable addresses

[Daniel Pittman <daniel@rimspace.net>]

gcrimp@vcn.bc.ca writes:
> On Mon, Jan 23, 2006 at 04:06:26PM +1100, Daniel Pittman wrote:
>> gcrimp@vcn.bc.ca writes:
>> > On Mon, Jan 23, 2006 at 01:02:16PM +1100, Daniel Pittman wrote:
>> >> gcrimp@vcn.bc.ca writes:
>> >> 
>
> Well, the local lock out question, at least, is resolved ....
>
> [snip]
>
>> >> That warning, presumably, is (badly worded, and) about locking your self
>> >> out if you use SSH or something to access the server.  The local,
>> >> physically connected keyboard does *not* touch the network at all.
>> >
>> > I'm not so sure about that.  
>> 
>> Really, trust me here: the keyboard input layer is not connected to the
>> network layer in any way...

[...]

> I have had a reply from the writer of the quote.  The situation he
> described was not a result of iptables alone.  But, with remote
> (login) authentication, if the ip packets are not getting through as a
> result of an iptables rule, one is effectively locked out.  

Ah!  Excellent.  I had not considered that situation and, yes, it could
certainly lead to your directory service being unavailable and, hence,
your inability to authenticate against the server.

> Sorry if this is not entirely accurate.  Any inaccuracies in this
> description are entirely my own.

I think the original could do with being expanded, because this is a
non-trivial issue, and one that (obviously) it is quite possible to
overlook when you think about firewall risks.

Thank you for letting us know the outcome of the discussion.

> So, can anyone suggest what I should do with packets that have a
> source address of 0.0.0.0?

Junk them -- they have no real business on your network, as 0.0.0.0
isn't a valid assigned address on the live Internet.

In the extremely unlikely event that it actually pops up in your logs as
blocked, work out why and tell us (well, me, anyway) what generated
'em. :)

         Daniel