[ot] internal ip address

[mikea]

On Thu, Feb 07, 2008 at 09:52:10PM +0100, Glenn Steen wrote:
> On 07/02/2008, Matt Kettler <mkettler at evi-inc.com> wrote:
> > Glenn Steen wrote:
> > >  For the
> > > vast majority of organizations, this is a very minor threat, not worth
> > > breaking RFC...
> >
> > Like.. gmail?
> :-)
> 
> > Received: by wa-out-1112.google.com with SMTP id m16so1283782waf.14
> >
> > Actually, AFAIK, that doesn't actually violate the RFCs.. you MUST add a
> > Received: header, but I don't see anything in 2821/2822/1123 requiring you to
> > add a from clause.
> Ah, but the "breakage" is in _removing_ a Received line added by
> another SMTP server, be that internal or not... Hm, maybe I'm an
> idiot, and the original question was just about the Received line
> added by the MS gw... Sigh. Just goes to show one shouldn't try to do
> more than three things simultaneously (I got my new DB servers today,
> or rather the storage and racks... as a surprise "here we are, four
> workdays early.... Where should we put them?" kind of thing, on a busy
> day...). Sorry, might've be me typing without much afterthought.
> 
> > > I'm not saying you're wrong, just that it is ... really minor...
> > > compared to a lot of other email-related threats:-)... Yes, you can
> > > counter with "your generalization is bigger than mine"... I know I do
> > > it too...:-)
> > >
> > > On the whole, I see very little _real possibility_ of damages from this.
> > > It is a leakage, yes.... but negligible in most cases. that's MHO ate least:-).

If it is _Vital_ to keep the shape of the internal network hidden, 
then the leakage is a problem. Otherwise, it's just another piece of
the puzzle to be tacked up on the wall. Intelligence organizations 
make their livings by putting together such puzzles. You have to make
a decision about how much of the puzzle you're comfortable having on 
the wall. It almost always is more than you know is on the wall.

> > I would agree in most cases it is very minor or negligible. I never said this
> > applied to most, or even very many people.
> See above, me reading too fast:-).
> I tend to react to "security by obscurity" or "the auditor said this
> is bad for everyone" kind of arguments, where one hasn't done any form
> of risk assessment...  so that was probably what got me going:-).

I lost absolutely all respect for the external auditors hired by our
internal auditing group for an IT audit when one of them:
o	handed me a CDROM and told me to "boot" our very large IBM 
	mainframe computer from it; and then
o	refused to believe that I couldn't "open" the NETBEUI port on the 
	mainframe for him. 
The IBM mainframe doesn't "boot" from CDROM, but from very large disk.
There is not an IBM-supplied listener for NETBEUI, and we don't run 
one. 

These, unfortunately, are the sorts of things that one gets from
the run-of-the-mill auditors, who download a checklist and run down
it, one question at a time, one size fits all. 

> > My only point was the "if it's unroutable, you can't hack it" argument isn't a
> > very complete view of network security.
> Quite true.  As usual,I find we're in violent agreement (of a
> sorts:-). I truly value your comments.

OTOH, if you don't route it, they can't get to it directly, which may 
satisfy your needs. Preventing information leaks, whether direct or 
indirect, overt or covert, is a *much* knottier problem, and one that
is in the general case insoluble. An air-gap firewall and TEMPEST 
shielding to NACSIM 5100A or better is -- or so the government hopes 
-- at least a good start. 

-- 
Mike Andrews, W5EGO
mikea at mikea.ath.cx
Tired old sysadmin