Re: How safe for firewall rule using 127.0.0.0/8

From: Moe Trin (ibuprofin_at_painkiller.example.tld)
Date: 10/27/05


Date: Thu, 27 Oct 2005 14:57:24 -0500

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.

>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.)

--------------------
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



Relevant Pages

  • 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. ... > network, the packet has a source address from this network, or alarms go ... > privileges, it doesn't make a bit of difference what you do. ...
    (comp.security.firewalls)
  • alt.2600 FAQ Revision .014 (2/4)
    ... One type of firewall is the packet filtering firewall. ... Dropping packets instead of rejecting them greatly increases the time required to scan your network. ... Port scanning UDP ports is much slower than port scanning TCP ports. ... Chartreuse Use the electricity from your phone line Cheese Connect two phones to create a diverter Chrome Manipulate Traffic Signals by Remote Control ...
    (alt.2600)
  • Re: UDP timers
    ... In one application (network multimedia tank), ... the event that a packet is dropped or lost in the ether. ... waiting *seconds* for an acknowledgement would necessitate a very ... The client doesn't need the ...
    (comp.arch.embedded)
  • Re: Setting up Airport Express
    ... It is usually referred to as a "MAC Address", ... System Preferences> Network, select the appropriate network interface, ... When your computer sends a data packet out over an Ethernet (Airport ... The destination address needs to be known in advance. ...
    (uk.comp.sys.mac)
  • Re: UDP timers
    ... So you don't want TCP, but you want 80% of what TCP provides? ... What is the nature of the network? ... Are you using a financial cost per packet communications ... sure (at least in your desired generic solution) the packet was received. ...
    (comp.arch.embedded)