On 2002-03-18 at 10:51 -0800, Harry Putnam wrote:
> > On 2002-03-17 at 18:06 -0800, Harry Putnam wrote:
> >> It seems one would want to limit exsposer of local private addresses for
> >> security reasons too... yes?
> >
> > It depends. How are the internal addresses reachable? The NAT box
> > _does_ prevent source-routing, yes?
>
> I don't really know what source-routing is. Maybe a description of
> what I see happen will provide enough clues for you to tell.
In this context, loose source routing, as described in RFC 791. The
originating machine sends packets to your private addresses, specifying
a route of your gateway box. If enough systems pass this on unmolested
for the packet to reach you, and your gateway box supports this, then
the gateway would then pass the packet onto your internal machine,
despite there not being a route to that box on the general internet.
In this day and age, simply don't accept any source-routed packets.
Much safer. Your kernel will have some means of checking. If Linux,
it's something under /proc. If derived from BSD4.4, then a sysctl
variable.
Hopefully, your vendor is clued enough to have disabled it. But since
you're being paranoid, your paranoia is better spent double-checking
these things than worrying about RFC1918 addresses inside Received:
headers. Trust me on this, I'm a paranoid. ;^)
> > Otherwise, reaching the internal addresses means compromising the
> > gateway; at which point, the attacker _knows_ what your internal
> > addresses are.
>
> OK, I see your point here. If the attacker breaches the firewall all
> bets are off.
True, succinct and very valid, but not quite what I meant. I meant that
for the information which you're leaking (RFC1918 addresses in headers)
to be of use to an attacker, then either your gateway box needs
tightening (see above discussion re source routing) or your gateway box
has been compromised. If the latter, a compromise, then they can get
the information anyway. If the former, then you've messed up at a
fundamental level.
> Thanks... I like the texi format best but it appears spec.txt is a
> separate critter.
Uhm, my understanding is that they're roughly equivalent. The same
information should be in spec.txt and the texi doc available separately
on the website.
> But am I correct in thinking that If all I do is
> set primary_hostname = adsl-66.51.210.228.dslextreme.com, as you've
> indicated further along, that my mail setup would be acceptable and
> not present any undue security risks.
That would be my analysis, yes. You'll be presenting a correct hostname
in EHLO and in the Received: headers for the gateway; noone else should
worry about your local Received: headers. Personally, I don't feel that
the local Received: headers aren't anything for you to worry about.
Different people, different perceptions of "undue security risk", so I
can't provide it as an absolute. However, I'm regarded by some of my
colleagues as particularly paranoid, I do quite a bit of security stuff,
both locally more broadly within the company I work for. I do not feel
that there are any undue security risks here.
If you're dealing with a system carrying officially classified data,
then the rules change and my analysis might well not be acceptible. If
this applies, then a public mailing-list isn't the place to be asking.
:^)
> Using the $received_header_text posted will be sufficient?
(Uhm, AFAIK $received_header_text isn't a variable.
"received_header_text" is an Exim configuration command, but the results
aren't available as a variable. Or did this change with Exim 4?)
Unless you report to someone else, only you can decide what should truly
be allowed to leak out in Received: headers. If the default setting is
not acceptable, snip things out until it is. I personally trim some
stuff like ident, relying upon logs to recover that instead of
broadcasting _very_ loudly what users are locally valid. And a few
other minor tweaks. I should probably get around to fixing the
information leak of "for multiple recipients" when I Bcc: someone yet
there's only one apparent header. :^)
Look at "exim -C /dev/null -bP received_header_text" to see the default
(or read the Specification, where it's given in a more readable format).
Look at the results of expansion on various test messages. Read chapter
9 of the Specification very thoroughly. 9.5 gives you the variables
available, earlier sections the ways that these variables can be
massaged.
> Showing the true depths of my ignorance here, but what does `reverse
> DNS' really mean? Just getting alphabetical name from number?
Loosely, "yes". More strictly, note that DNS is not confined to
alphabetical names; some applications such as SMTP, for email, restrict
the character set available. But making assumptions like "only
alphabetical data can occur" is the sort of thing which leads to
security holes.
There's nothing wrong, technically, with providing reverse DNS for some
IP which points to a name containing ANSI escape sequences, to reprogram
common terminals if they view the results raw. As long as I don't ask
for mail to be sendable to a mail-domain containing such characters, I'm
okay. Others might ruefully, and correctly, use a number of very rude
terms to describe me, my parentage and some of my personal habits. But
that's because they were making unwarranted assumptions and got bitten.
Given an IP of 1.2.3.4, getting the reverse DNS involves asking, in the
normal way, for a PTR record for the name 4.3.2.1.in-addr.arpa. [1]
This can get complicated, if people do weird things with delegation
boundaries. Don't worry about it. Just don't assume that because it
doesn't look like I described it here, it's wrong. Go read the RFCs.
> Seems to be fairly common around here. I've had two that did in the last
> year. (One went out of business). These are not big interstate
> operators though.
*nods* Thanks.
[1] Allegedly, Network Solutions very recently tried to bill ARIN for
the in-addr.arpa. domain. I didn't realise that they were allowed
to bill for anything other than .com/.net/.org; can we say "postal
fraud"?
--
Note to self: High-fiving is dangerous in a zero-G environment.
-- Riff, Sluggy Freelance <http://sluggy.com/daily.php?date=010722>
