How safe for firewall rule using 127.0.0.0/8

snipped-for-privacy@asia.com wrote in news:1130223645.713308.28390 @z14g2000cwz.googlegroups.com:

127.0.0.0 is the Loopback IP and Internet applications such as IE or others will go to the Loopback IP keeping themselves in the ready state. The Loopback IP is also known as LocalHost (your machine). You can download Active Ports (free) start it and start IE or any browser and do nothing let it set for a while and watch the browser start using the Loopback IP. Use Google to find more information about the Loopback IP.

Some personal FW(s) know how to deal with the Loopback IP automatically and some do not know and rules must be set.

Duane :)

Many SSL VPN clints use IPs within that subnet as a local IP. It may be that if you block that port, you prevent such tunnels, and by allowing it with a blanket rule, you are exempting them from your firewall scrutiny. I've never tested it that way though.

I'm assuming a software firewall here of course.

-Russ.

Which interface? Every computer knows that 127.0.0.1 is "me". Some operating systems understand that _any_ address between 127.0.0.0 and

127.255.255.254 should also be "this" computer. It's used to allow one application to talk to another on this computer.

There can not be a valid packets OF ANY KIND with that source address on ANY network. ISP's who have their head out of their ass should be dropping packets with that address (see RFC2827) anywhere they are seen on a network. The smart firewall administrator also blocks these packets ON THE NETWORK INTERFACES. You appear to be using windoze, which tries to hide technical details, but if you open a dos box (Start/Run.../cmd), and enter "route print" - you will see two (or sometimes more) interfaces, one of which is 127.0.0.1, and _that_ interface should be permitted.

Denial of service attacks - trying to waste bandwidth. If a packet arrives over the network with a "source" address of 127.0.0.1, your computer doesn't know what to do with it, and may get confused.

Old guy

Particularly, if you can send a packet with the source address of 127.0.0.1, and the source and destination ports matching some kind of "echo server", you may be able to persuade the receiving system to keep echoing packets around and around to itself, exhausting memory, processor resources, etc. In a few cases, such attacks have escalated to causing GPFs, blue-screens, etc.

ISPs should be doing egress and ingress filtering to prevent this sort of thing, but are they? Are they heck.

Alun. ~~~~ [Please don't email posters, if a Usenet response is appropriate.]

If you don't trust your localhost, you're in deep trouble ;-)

Juergen Nieveler

But the traffic would be from inside the VPN then, wouldn't it?

VPN-traffic should be a bit more trustworthy than normal Internet traffic, though of course I agree that it's not 100% trustworthy, especially in large corporate networks.

Juergen Nieveler

Consider a nefarious VPN client, installed by a web site, that tunnels out using SSL into a foreign network and dumps your registry and copies of all your excel files. Such clients often use 127.0.0.x as a local source address.

I'm just advancing it as something to think about; again, I've not tested blocking such a one.

-Russ.

Hey Moe, how about my SSL VPN client example? What do you think?

-Russ.

As noted above, ISP's who have their head out of their ass should be dropping packets with that address (see RFC2827) anywhere they are seen on a network. The smart firewall administrator also blocks these packets ON THE NETWORK INTERFACES."

RFC2827 is a "BEST CURRENT PRACTICE", which is defined in RFC2026 in section 5. No RFC has the force of law, though a number of them are such that only a fool disregards them. Unfortunately, there seems to be quite a large number of fools out there.

[compton ~]$ zgrep -c '^[0-9]' rfcs/rfc-index.10.14.05.txt.gz 4176 [compton ~]$ zgrep -A1 Status rfcs/rfc-index.10.14.05.txt.gz | tr -s ' ' '\\n' | tr '\\n' ' ' | tr ')' '\\n' | grep 'Status: [A-Z]' | sed s'/.*(//' | sort | uniq -c | column 112 Status: BEST CURRENT PRACTICE 1269 Status: INFORMATIONAL 116 Status: DRAFT STANDARD 1220 Status: PROPOSED STANDARD 241 Status: EXPERIMENTAL 86 Status: STANDARD 145 Status: HISTORIC 909 Status: UNKNOWN [compton ~]$ zgrep -c '^[0-9]* Not Issued' rfcs/rfc-index.10.14.05.txt.gz 78 [compton ~]$

(In case you can't follow the commands above - first one says there are

4176 RFCs. The second strips out the status term and counts them - the last notes that 78 were not issued.)

RFC3330 lists all "current" special use address space. You can also look at

to see what space may be valid (listed by /8 or 255.0.0.0 increments). If you look at the listings by Regional Internet Registry (RIR), you'd find they had 69303 assignments totalling 2.19934e+09 IPv4 addresses (out of a total of

4,294,967,296 - or just over half).

As a user (or even as a firewall administrator), it's difficult to keep up with what addresses may be valid, and what aren't. IANA is handing out new address blocks to the RIRs, and they then allocate/assign space within those blocks.

[compton ~]$ zgrep ' 05 ' rfcs/ipv4-address-space.06.30.05.gz | sed s'/ .*//' | column 041/8 Apr 05 AfriNIC 091/8 Jun 05 RIPE NCC 073/8 Mar 05 ARIN 124/8 Jan 05 APNIC 074/8 Jun 05 ARIN 125/8 Jan 05 APNIC 075/8 Jun 05 ARIN 126/8 Jan 05 APNIC 076/8 Jun 05 ARIN 189/8 Jun 05 LACNIC 089/8 Jun 05 RIPE NCC 190/8 Jun 05 LACNIC 090/8 Jun 05 RIPE NCC [compton ~]$

Old guy

If you don't know what's inside that VPN, you have a problem that basic firewalls shouldn't have to deal with. 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.

In your 23:48:00 UTC response to Juergen Nieveler, you are concerned about a "nefarious VPN client, installed by a web site". Why the f*ck would you allow that to be installed in the first place? Crap like that does not get installed by magic - it gets installed by untrained users who are using incompetently configured software.

Old guy

Well that can certainly be true in many cases. But let's look at it this way. Take a fully patched, updated, secure computer, running a decent local firewall. Let's say the user sometimes does https, common enough of course, so 443 is open. The user is pretty literate. The user connects to a website running an ssl vpn server, even though he doesn't realise it. The server offers to him to download the vpn client plugin by tricking him to think it's something else. But it's a garden variety ssl vpn client by a major manufacturer, not some peice of malware. So, spybot, adware, symantec, mcafee, whatever, nobody notices or objects to it. It doesn't knock down his AV or his firewall, or do anything else nefarious like that. Then it runs a peice of code over this vpn tunnel sending stuff out from it's source address of 127.0.0.55 to the remote server. Since the local firewall has been configured to permit 127.0.0.0/8, it goes out without being questioned.

Just a thought.

-Russ.

^^^^^^^^^^^^^^^^^^^^^^^

There's the problem - if the user installs malware (a website doesn't install anything - the user had to do it), all bets are off, a desktop firewall is useless in that situation anyway.

Juergen Nieveler

For this example, your "no vpns policy" would have to include blocking 443. Are you prepared to do that? Even if you are, most people cannot, as this blocks all secure browsing activities. Furthermore, if you are scanning traffic on this port, all you can see is that it's encrypted. So, short of an authoritative white list for 443 (which you might be willing to take on, but many would not, certainly outside the scope of the OP's capabilites), nothing on the network core or permiter can detect/stop this activity in any useful way. It looks like very ordinary https traffic.

All it takes is a single click "OK" and a few prompts that most people are used to sailing through. These clients are designed for completely central administration and low client PC footprint, with automatic distribution from a web server. There's no big setup wizard and install program, it's just a plugin. Lots of people can be tricked into installing that, very easily, thinking it's something else. I agree, untrained users, etc etc. That's my point in the example. So you have this user that installs something he shouldn't -- how often does that happen? Pretty often. So, now what. 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. OR, they use something in a normal private range that's much easier to detect, so we won't worry about those cases. 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.

-Russ.

443 outbound? Blocking outbound ports is futile anywhere...

We'll see...

So he's not that literate. Why would he need to download a software to access an SSL-protected webpage?

It doesn't need to. Even IF it would be blocked, it could simply ask the user "Open port $FOO for me to work", and the user would do it - after all, he downloaded it, so he wants to use it, so he'll do what it takes to install it properly.

Still, the user has noone to blame but himself. He got a gift from a Greek, and he accepted it... remember, the original concept of a trojan horse was something that you WANT to install, that might even DO something usefull, only it does something bad behind your back as well.

A desktop firewall cannot protect you against that threat - after all, if you get fooled to install the malware, you'll make the necessary config changes as well, you might even log in as admin to install the malware.

Take premium rate dialers as an example: Laws governing those dialers are pretty tough in Germany, they have to state the cost explicitly, in a given font size, and you have to enter the actual letters "O" and "K"

3 times before installing the dialer, each time in a window full of warning messages. Still people "catch" one of those dialers and claim that it installed itself without their knowledge... when in reality the promise of allowing them to download p*rn made them blind to the warnings.

Juergen Nieveler

Alright, he's an idiot, etc etc, and at the moment SSL VPN boxes are very expensive and not likely to be used by a hacker. Just for the sake of discussion though, if you blocked the rest of 127.0.0.0/8 do you agree or disagree that it could stop this type of activity? If you have explicit denys in the firewall policy for this range it won't prompt you any more, and so the user could be protected.

*OR*...

You could potentially *prevent* all users from installing SSL VPN clients by enforcing a block on this range by policy, when there is really not much else you can do to prevent an SSL VPN from being established inside your network.

-Russ.

Fine, agreed, they shouldn't install stuff. Won't anyone speak to the network/firewall issue I'm trying to bring up?

It's a lot easier to put a software firewall with enforced policies and make users live with it, than it is to prevent them from installing browser plugins and the like completely.

-Russ.

Somebody. wrote on Wed, 26 Oct 2005 19:29:03 -0400:

Or you prevent users from installing/running anything on their PCs that isn't sanctioned, which in a work environment is a sensible requirement anyway. Then the VPN software doesn't get on the machine in the first place.

Dan

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.

Then perhaps you need experience and more training.

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

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.

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.

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.

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

2827 Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing. P. Ferguson, D. Senie. May 2000. (Format: TXT=21258 bytes) (Obsoletes RFC2267) (Updated by RFC3704) (Also BCP0038) (Status: BEST CURRENT PRACTICE) 3330 Special-Use IPv4 Addresses. IANA. September 2002. (Format: TXT=16200 bytes) (Status: INFORMATIONAL) 3704 Ingress Filtering for Multihomed Networks. F. Baker, P. Savola. March 2004. (Format: TXT=35942 bytes) (Updates RFC2827) (Also BCP0084) (Status: BEST CURRENT PRACTICE)

No - it's easier to stop them from installing the crap by not giving them access to the privileged account needed to do so.

But I think you're missing a point. We're talking about a firewall blocking 127.0.0.0/8 - you should be blocking that in and out on the NETWORK interfaces. Blocking 127.0.0.0/8 on the loopback is not going to work, because there are applications that need to use the interface (and almost certainly using 127.0.0.1). Please look at your 'netstat' output. What might be useful is blocking specific ports, but that is a much more difficult to define.

A much more useful technique is to find out WHY are people visiting those sites that want to install mal-ware. Is this part of their job. If so, those sites are being hosted by vendors that you really don't want to be doing business with. Are the sites "personal" but otherwise legit? By this, I mean sites like banks, Amazon (and the like), car rentals, air line ticketing services, etc. We provide several systems in employee break areas that are not connected to our network for "personal" use (that's how I'm posting this article), and these systems actually run off of Read Only media (an internally mounted CD) - there is NO hard disk, no removable media drives accessible to the user, and the users have minimal privileges needed to run simple clients only.

Old guy