Re: How safe for firewall rule using 127.0.0.0/8

From: Somebody. (somebody._at_spamout.russdoucet.com)
Date: 10/28/05 

Date: Fri, 28 Oct 2005 02:03:48 -0400

"Moe Trin" <ibuprofin@painkiller.example.tld> wrote in message
news:slrndm2c94.slt.ibuprofin@compton.phx.az.us...
> In the Usenet newsgroup comp.security.firewalls, in article
> <9jU7f.1035$43.44@nnrp.ca.mci.com!nnrp1.uunet.ca>, Somebody. wrote:
>>
>>"Moe Trin" <ibuprofin@painkiller.example.tld> 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
> in
> 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
> for
> 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
> because
> 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
> yourself,
> 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

Ok, thanks.

-Russ.

Relevant Pages

  • Re: How safe for firewall rule using 127.0.0.0/8
    ... above - and tell you to use a packet sniffer (any - even something like ... many business sites are so stupid as pull stunts. ... Our users do not have root privileges. ... network, the packet has a source address from this network, or alarms go ...
    (comp.security.firewalls)
  • RE: in-to-out security
    ... can monitor traffic flows on your network. ... A colleague of mine ... One of his clients is a person who is the CTO ... | told my colleague a written policy will protect the ...
    (Security-Basics)
  • Re: How safe for firewall rule using 127.0.0.0/8
    ... we have written policy in place - the results of violating it are ... > many business sites are so stupid as pull stunts. ... We're not running windoze, never mind Outlook or Internet Exploiter. ... Around here, the *products* run on windoze, and upper management loves ...
    (comp.security.firewalls)
  • Re: Why the insults? Re: Firefox or Opera? Evolution or T-bird?
    ... "The Rise of the Stupid Network was originally written during a single ... It was officially released onto the Internet by ... Mr. Isenberg is referring to IP based networks, ...
    (Fedora)
  • Re: SSH connection through a router applying NAT
    ... to start wireshark in my own network for developing purposes. ... As I said, there's no written policy. ... and the third-party machine connects the two in some way ...
    (comp.os.linux.networking)