Re: How safe for firewall rule using 127.0.0.0/8
From: Somebody. (somebody._at_spamout.russdoucet.com)
Date: Fri, 28 Oct 2005 02:03:48 -0400
"Moe Trin" <firstname.lastname@example.org> wrote in message
> In the Usenet newsgroup comp.security.firewalls, in article
> <9jU7f.email@example.com!nnrp1.uunet.ca>, Somebody. wrote:
>>"Moe Trin" <firstname.lastname@example.org> wrote
>>> At work, the solution is quite simple - no VPNs period. I know what
>>> my "normal" network traffic looks like, and when I see something out
>>> of the ordinary, I investigate.
>> For this example, your "no vpns policy" would have to include blocking
>> 443. Are you prepared to do that?
> No, we have written policy in place - the results of violating it are
> well known to the users and harsh. We don't have a problem with this, as
> our users are not stupid. But let me point you back at the last sentence
> above - and tell you to use a packet sniffer (any - even something like
> ethereal) and notice the difference between Alice checking her bank
> balance (which is prohibited here, but less likely to trigger disiplinary
> action), and Bob using a tunnel for surfing pr0n or mailing the company
> secrets to a competitor.
>>nothing on the network core or permiter can detect/stop this activity in
>>any useful way. It looks like very ordinary https traffic.
> Then perhaps you need experience and more training.
I said that in an example, of course you can look at whitelisted
destinations only. This is intended to be a discussion about a concept, not
a roadmap for a total security package.
>>All it takes is a single click "OK" and a few prompts that most people are
>>used to sailing through.
> Train your users. See that your users are not operating as a privileged
> user - if you can't get their applications to run without needing that,
> get someone who can. Do not use known broken applications because they are
> included in the desktop or what-ever, and it's the only thing your users
> are capable of running. (Back in the early 1980s, my wife was using a
> spread-sheet as a word processor, database tool, and who knows what else
> addition to it's primary use as a spread-sheet, because that was the only
> thing her company thought to buy - but then, it was one of 2 PCs in a 40
> person accounting department. Let me assure you that things changed over
> time when they started noting massive productivity gains, even given that
> an IBM PC-XT was a _substantial_ chunk of coin at the time.)
>>Lots of people can be tricked into installing that, very easily,
>>thinking it's something else. I agree, untrained users, etc etc.
> Why are your users visiting such sites? It is required as part of their
> job? (If so, I'd start by asking to disqualify those vendors.)
There are huge, huge companies using SSL VPN servers for remote access. IE,
7-figure projects with tens of thousands of users. That's the client that
I'm talking about. So I'm imagining a nefarious use of the same technology.
> It just so happens that the most frequently used vector to date is that of
> user stupidity (why is it that we laugh at the cartoon animal who falls
> the "stand here and press this button" gag, but so many of us seem content
> to "click here and be amazed"?) (Alun Jones in c.s.f)
> [Remember that one Alun?]
> Social Engineering - Because there is no patch for human stupidity.
> Uncrackable computers are already available. It's uncrackable users that
> are in short supply.
> Really - training makes a HUGE difference.
>>So you have this user that installs something he shouldn't -- how
>>often does that happen? Pretty often.
> Very infrequently - for six reasons.
> 1. We've trained our users.
> 2. Corporate policy prohibits personal use of company computers, and not
> many business sites are so stupid as pull stunts.
> 3. We're not running windoze, never mind Outlook or Internet Exploiter.
> 4. Our users use an appropriate tool other than some crappy browser
> it's they only piece of software they can (sorta) use.
> 5. Our users do not have root (admin) privileges.
> 6. Our user home directories are network mounted from a file server, and
> most are mounted 'noexec' meaning you can't even create a shell script
> (the *nix equivalent of a batch file) - never mind install shit.
>>I'm thinking, if you block most of 127.0.0.0/8 except for those addresses
>>that are absolutely required, you would stop these programs since they
>>use an address within that cloud as their local adaptor.
> 127.0.0.0/8 means "this computer" - many O/S don't differentiate between
> IP addresses within that range. In _most_ cases, that address is
> and if you don't trust yourself, there's not a whole lot anyone can do.
> From a network standpoint - the answer is relatively easy - filtering
> on the routers between subnets and at your perimeter. No packet passes
> our routers unless the addresses make sense - if it's coming from "this"
> network, the packet has a source address from this network, or alarms go
> off. Packets coming in to "this" network don't have a source address that
> claim to be "this" network or they are dropped and alarms go off. The
> 127.0.0.0/8 fits that last rule too.
>>So we're left with the question, does 'unblocking' all of 127.0.0.0/8
>>open up any more exposures, and I'm thinking that yes, it does, to
>>garden-variety SSL VPN clients.
> Unblocking 127.0.0.0 through 127.255.255.255 on the loopback isn't going
> to make a bit of difference. 127.0.0.0/8 should never be seen in OR out
> on a network interface - copper, fiber, or wireless. Some may want to
> block specific ports or protocols on the loopback - if you don't trust
> your users AND THEY DON'T HAVE THE PRIVILEGES TO REMOVE YOUR BLOCK, that
> may serve some useful purpose. On the other hand, if they have those
> privileges, it doesn't make a bit of difference what you do.
> Old guy