Broadband Tech > Security > Security > Tiny + WebWasher Users

Tiny + WebWasher Users

Localhost still has to contact the site. If you examine the default rule closely, it allows only localhost to local machine communications. To get anywhere else, it has to go through the rest of the rules. A connection of "localhost to [any Ip but local IP] won't be a match to the localhost rule, and will continue down for more processing. I have, for instance, netbios blocked by a rule around 2 or 3 down the list; constantly, I find entries where "localhost" originates a connection from system on 137 local to 137 on a foreign machine (simply an NB name resolution request), but it's blocked quite effectively, without having to stop it's getting to localhost. I hope that makes sense, the way I explained it... the fact that it originates from [myip] or from localhost doesn't make a bit of difference to Tiny... it allows or blocks either one based on the applicable rules.

Now, in another realm... I refuse all access on 8080, as well as 1080, in my "filtered ports" deny rule, and at the router filters page. Why? Local 1080 and 8080 are socks and bridge server, respectively, and crackers look for those ports to find badly configured proxies and webservers to use as waystations, to hide their own true address behind yours. Without a server running, there's not much they can exploit, but I do run a few local servers now and then... no such thing as "too paranoid" when you do, after all!

Just wanted to assure, though, that there's no localhost "hole" in Tiny. Localhost is the local machine... it still has to get over the firewall, to get to any outside servers. If that positioning makes you feel comfortable, though, fine. It doesn't appear to conflict with any needed functionality I know of, and that's really what matters. I think I see what you're doing. Like I said, the packets still have to leave localhost, somewhere, to reach the web. The effect of this rule is that it doesn't even get to the firewall, in a manner of speaking. Contacting localhost is never a security risk. It's when local host passes it on to a foreign server. What I'm trying to say is this: Tiny won't allow a localhost to X connection anymore than it will allow a {myip} to X connection. The effect of your rule (if it works, hey, great... that's what matters, and there's more than one way to skin a cat... uh... sorry, tiggerstales... I meant "block a packet." ) is that only IE and BigFix can access port 8080 on localhost. Nothing else can use it at all, not just limited to webwasher... again, I've captured loads of localhost to x.x.x.x traffic, and the rules, in normal order, still block 'em just fine.

I'm quite impressed with Tiny, more every day. For one thing, it allows you to do things like this. For another, it's very secure, if you tweak it appropriately. Finally, it loads where a firewall's supposed to load... as low down as the OS will let it... as a device driver and a service. Meaning, you're protected even if you're logged off. And, as Martha might say it, "that's a good thing."
--
Man will occasionally stumble over the truth, but most times he will pick himself up and carry on. - Sir Winston Churchill

Yes I would agree that Tiny is prob. one of the best small firewall solutions out there. When the service loads so low that I'm getting alerts BEFORE I'm logged in that is a GOOD thing, as you and Martha say.

reply to gwion
[Edit:]
The following reasoning was INCORRECT!.
Read through the thread for more information.
[:Edit]

gwion, I found the problem. It was the cached temporary files that messed up all that.

When I installed bigfix, my 2 PCs were running WW. Till then, I apparently had been walking over bigfix sites for several days to see what the was about. My guess is (I could be wrong again, agrrr...) somehow those temp files were loaded whenever I hit "gather" button in bigfix. I never suspected because, from the start, bigfix showed it was accessing 127.0.0.1 for updates. I have no idea why bigfix tried 127.0.0.1 from the start, and not now. Anyway, after deleting temp files, now it displays correct server IPs.

I did redownload, un/reinstall Tiny and WW several times, rebooted my two machines, and even installed a couple of "calling-home" programs to see if Tiny really blocks them. Result: nothing could hide from Tiny... except bigfix.

All through this, I didn't even think about deleting temp files...

Sorry for those who might have been confused due to my incorrect post.

And, thanks gwion, without your assuring reply, I might have messed up my ruleset even further and possibly others, too .

-- wiregauze
[text was edited by author 2001-06-05 08:00:32]

reply to wiregauze
Hey, glad you got it cornered! It takes a while to get comfortable with any firewall, especially one where the rules are as good as your own logic, if you're like me. I haven't found any holes in Tiny, so far, but I've found one or two in my own logic, now and then... a connection to "localhost" is a "loopback" connection, and won't go anywhere except back to your machine. localhost should be mapped in your hosts file, too, to 127.0.0.1 - so calls to "localhost" will always resolve. Great little firewall, isn't it? I've been using it pretty much since it became available just last year, and it's under constant development.

Now, for a little side remark. Bigfix is reputedly a pretty good site, which I've never used, but which others seem to trust. That's a good thing ... because what it does is to load an activeX control on your computer to do its scan, and then run the control, ON YOUR MACHINE, to send the data back. Even with a good firewall, you still need to take care with ActiveX, Java and scripting. They can all operate on your machine, and cause a trusted application to send data out for them, or otherwise tamper with your system without anything actually being done "over the internet" except downloading the code in IE or Outlook. Someone else would understand just how bigfix works better than I, but I hope the other stuff's useful to someone... you still have to surf safe and virus scan, even with a good wall.

Again, for others, 127.0.0.1, or localhost, are "loopbacks." They loop right back to your own PC. Localhost can send outgoings to other addresses, but they'll be handled, in due order, the same way as any outgoing traffic by most good firewalls, including Tiny; the first rule only applies if it's FROM a local ip TO localhost. If it's from localhost TO another IP, it's passed down into processing. before it's allowed. In essence, the first rule never lets anything leave the local machine Tiny's running on, by itself.

Glad to be of help. With the growing number of Tiny users, it's good that these things are discussed and followed up. Thanks.
--
Man will occasionally stumble over the truth, but most times he will pick himself up and carry on. - Sir Winston Churchill

Do you have... OHHH webwasher... proxy server... yeah... I get it, now... I apologize, I missed the forest for the trees!

the connection to 127.0.0.1 is the client app (bigfix) connecting to your proxyserver, on your machine. That's normal and OK.

the connection alert is the proxy server asking permission to make access to the internet. Whatever goes through the proxy server will appear as "webwasher", not by name. Running a proxy with a firewall like Tiny is OK, but adds a complex dimension: whatever goes through it won't actually contact Tiny itself, it'll be "proxied" by webwasher.

Needless to say, that means you have to pay close attention to the filters you use IN WEB WASHER, because a rule allowing webwasher will allow EVERYTHING it proxies... this is going to be your call, but I personally decommissioned my own proxy server some time back, for largely this reason. Doesn't mean it can't be done, just that you have to be careful what you proxy.

Now, your problem... and I do apologize for missing this... there's nothing suspect or wrong with the 127.0.0.1 connection; leave those be.

You can do any of the following, now:

Allow or deny the connections on an individual basis (rather tedious)

Allow WebWasher by rule, (and every single app that uses it as a proxy, subject only to the filters in WW) to have access to the web; if you do this, of course, your ruleset might be pretty short... but you lose a lot of Tiny's versitility.

Allow (or deny, as you please) webwasher and go in and uncheck "use a proxy server" in the apps you want to go straight to the firewall, or don't use webwasher... suppsoedly a good product, though, so you probably do want it. Just pare off anything you want to deny, or deny it in webwasher, if that's possible. Here's an excerpt from the FAQ:

Q: I can no longer get onto the Internet without WebWasher.
A: It seems you have configured your browser and WebWasher manually. To make the browser run without WebWasher again, you will have to undo this manual configuration. Check whether the local proxy address of WebWasher is still entered in your browser. The address is "127.0.0.1" or "localhost" port "8080". Delete this, and replace it with the proxy address of your provider or indicate that you want a direct Internet connection.

We recommend the automatic configuration of WebWasher, because the browser can then establish connections to the Internet with or without WebWasher.

You may want it with IE, since that's where a filter proxy does it's best work, but that should give you the idea for any other app...

Not being familiar with WW, I hesitate to ell you to use it or not... that's your call, as is whether or not to allow the outbound connection to bigfix...

However, you can rest assured: contacting localhost (127.0.0.1) is how webwasher (and all local proxy servers, for the most part) works, and nothing ever leaves your machine on that address... it's a strict loopback address. Don't concentrate on that aspect. You have to concentrate on the interrelationship of the proxy and the firewall. It's Tiny that'll get the last word, though. Whatever rule you put in there will control whether and how web washer gets out... hope that was clear enough? Again, I apologize for the confusion... I kept suspecting bigfix... no, it's the proxy server... open 'n' shut! Wish I could help more, but it's really a decision on what to run through webwasher and what not to, which you'll just have to decide... keeping in mind that, if you do allow it without restrictions and run all traffic through it, ANY app connecting through webwasher will be "cloaked" by it at the firewall, and will be passed or denied without regard to what app sent it to webwasher... it just looks like webwasher to Tiny. Hope that helps...
--
Man will occasionally stumble over the truth, but most times he will pick himself up and carry on. - Sir Winston Churchill

said by gwion:

---

Do you have... OHHH webwasher... proxy server... yeah... I get it, now... I apologize, I missed the forest for the trees!

---

reply to wiregauze
If you remove the loopback rule, it won't do anything except prevent wallwasher (and tiny) from working at all. It seems what I'm trying to say is the one thing you're having trouble getting --- 127.0.0.1 is your own machine.

THERE IS NOTHING AT ALL DANGEROUS ABOUT 127.0.0.1!!! IT IS A LOOPBACK TO LOCALHOST.

It's where it goes afterwards. I'm sorry if I shouted... But that's the single thing I wanted to make clear... and the one thing we're not quite clicking on... LOCALHOST IS THE COMPUTER SITTING IN FRONT OF YOU; the IP localhost resolves to is 127.0.0.1, and they're the same.

The connection request you showed is the one that you either allow or deny. NOT the localhost connection. If you disable localhost, Tiny will block itself.

Are you using the filters in the proxy at all? Tiny could be used to block spyware,too. Most critically, you can set filters in WW, and/or use webwasher selectively. I'm sorry if this isn't translating - getting a little frustrating... how do I make this clear? There's nothing to "worry" about with a locahost connection. It's wallwasher and tiny working correctly. The MD5 will get checked, by the way (when it contacts localhost to reach wallwasher, it goes through Tiny on the way).

If you want to keep the individual apps from working at all, then you need a localhost deny rule for the specific ports/IP's you want to kill, like you were trying in the first place... removing localhost entirely will cause you problems. It will cripple your connectivity. Honestly, preventing access to localhost accomplishes nothing, except keeping apps from reaching the proxy server or the firewall, both of which have to use that address to be part of your IP connection and work.

If you must keep appX from reaching localhost at all, try this:

Deny any protocol, any port, any IP, from application [big fix] - you could say "big fix (or whatever) is never allowed to contact localhost... if you do, it can't contact wallwasher, and can't get out... unless you configure it to bypass the proxy (just remove the use proxy settings in that app)...

and put that above localhost. The only good putting it above localhost will do is make you feel better, in this case. But... why not just remove that app, instead, if it bothers you that much?

None of my suggestions involve removing loopback. Just not allowing webwasher (by it's own rule, which Tiny is suggesting in your illustration) out after it "leaves" localhost. Spyware will show up, if its running, in the connected IP's... as anything but 127.0.0.1...

127.0.0.1 IS YOUR OWN MACHINE ! Worry about where it goes AFTER that!!!

Well, I do hope all ends well for you... what's important is that you visualize the concept mentally:

bigfix >>> contacts wallwasher on 127.0.0.1 >>> wallwasher filters and >>> contacts 127.0.0.1 again (Tiny, this one doesn't show) >>> TINY receives the packet and applies its own filters >>> if the filters allow the packet >>> it goes out of your machine; if not >>> it goes to never-never land (the bit bucket) and dies. Everything is working perfectly. You need to work on your rules in webwasher, if you want to keep ww... and you need to consider whether wallwasher is needed for every app you run or not (having run a proxy, myself, for ages, along with a firewall, and the combination makes a powerful barrier, but requires careful setups of both tools. Again, there's nothing to worry about because an app connects back to 127.0.0.1... IT ISN'T A REAL MACHINE, it's your machine receiving network packets from itself! Disable that connection, and, at minimum, wallwasher stops working at all, and Tiny blocks itself from the internet... and boy, you're secure... nothing as secure as a machine that can't get to the internet at all...
--
Man will occasionally stumble over the truth, but most times he will pick himself up and carry on. - Sir Winston Churchill

reply to wiregauze
Here's a rule:

"1. Deny application bigfix - any IP, any remote port, any local port."

2.the localhost rule
3~~~~~~
4~~~~~~
~~~~~

This should work. I don't recommend it, in general, as explained above, but it should work.... It would be better to filter it at wallwasher, then it will still go to localhost, but, if wallwasher's a filtering proxy worth its salt, it should be able to be set to block the connection from going through it to Tiny at all.

PS:

You may want to join this thread... they're discussing webwasher at:
»WebWasher the BIG Test
--
Man will occasionally stumble over the truth, but most times he will pick himself up and carry on. - Sir Winston Churchill
[text was edited by author 2001-05-24 13:17:24]

reply to wiregauze
Gwion you've hit the nail on the head pretty well in your explanation. The only thing I may add is, ZAP monitors internet access at the application level. If you wish to continue using WW, my suggestion is to use ZA to monitor which applications try to access the net (which would in essence be going through WW).

Not familiar with Tiny, but it appears Tiny does not monitor at the app level, instead if it listens at the port level. In this case, it will not stop any apps from accessing the net via WW. And WW does not have any settings to control which apps may use it.

Catch 22.
[text was edited by author 2001-05-24 12:53:39]

No, by operating at the lowest possible level, it stops ANYTHING AT ALL, even itself, from accessing. WW is going through Tiny, after it goes to localhost. The illustration wiregauze supplied is a graphic illustration of how it does that.

By operating at the lowest level, as a device driver and a service, Tiny loads before any app that might bypass it (like WW), and binds the ports FIRST. Nothing can bind a port that's already bound, which is why "enterprise grade" walls ALWAYS load as drivers and services. We're all familiar, I think, with the trojans that can "load at next boot," to try to get in below the firewall or proxy server... loading at such a low level, a firewall like Tiny gets there first, and the trojan has to try to go through it to reach a port.

That's my whole point: in wiregauze's scenario, the connection, to 127.0.0.1, is NOT a remote machine, it's wallwasher itself. The popup in his screenshot is Tiny trying to determine whether or not to let it through to go out to the internet. Perhaps what you mean is this, and you're correct, if so: If you ALLOW wallwasher, any port, any app, any remote host, Tiny won't see the app that asked the proxy to make the connect, it'll see the proxy server, which is allowed, so it won't discriminate - it will either allow or deny strictly based on the rule applied to wallwasher, and any further filtering will have to be done in wallwasher, because the originating app is "proxied" by wallwasher... carried in and out under it alone, with no reference back to the originating program except inside of wallwasher. By the way, I thought it out, and Tiny WILL see the hash fingerprint of the app when it goes to get to localhost, so it will detect a change, at that stage...

Deleting a hash from the table will NOT deny an app. It will just get the hash again next time the app hits Tiny. The only time that will stop the connection is if it HAS a hash, and the requesting app's hash doesn't match it (it was replaced); THEN, and only then, it will stop everything and ask if you accept or reject the changes before it passes the packets... for example, I upgraded a scanner, recently, and the very first time the new .exe component tried to get out, a warning told me that the file was changed (of course... I replaced the old one with the upgrade), and asked whether it was OK or not. However, blocking apps by application name isn't done with the hash table, it's done in the rules.

The rule I suggested above would stop a local app from proxying through WW at all, by preventing the localhost connect, so a rule like that could be used to selectively filter what is and isn't allowed hrough WW... but it would be a whole lot easier to set up filters in wallwatcher, in this unique case, and let the connections go through to it, wouldn't it? Of course, that assumes wallwatcher is a trusted application in your estimation... doing it one proggie at a time above localhost is awfully tedious, and runs a risk of blocking localhost connectivity to an unintended app... like all your wallwatcher traffic in gross, or Tiny, for instance... which will block itself if it can't get a 127.0.0.1 connection... either of which will simply block you from the web...
--
Man will occasionally stumble over the truth, but most times he will pick himself up and carry on. - Sir Winston Churchill
[text was edited by author 2001-05-24 13:41:45]

reply to wiregauze

Does this help?

Well, like I said, I have never touched Tiny.

That's OK... what we really need here is some wallwasher advice, anyway. The way I see this, what's needed is PROXY filters to stop wallwasher from letting out, for example, big fix, without stopping, say, Internet explorer. Whether through Tiny or ZA, or any ther firewall. Wiregauze wants his proxy, and his firewall, so his real problem is how to run WW and not automatically allow it as a "tunnel" through the firewall... way I see it, the most efficient way would be to make some sort of deny filter in the PROXY, but keep in mind tha a proxy - ANY proxy - is not as secure as a good firewall --- but can do things with cookies and content a firewall can't --- so we have a real balancing act... hmmm catch-a-tweneetoo, indeed...
--
Man will occasionally stumble over the truth, but most times he will pick himself up and carry on. - Sir Winston Churchill

reply to gwion

Re: Tiny + WebWasher Users

said by gwion:

---

"1. Deny application bigfix - any IP, any remote port, any local port."

2.the localhost rule
3~~~~~~
4~~~~~~
~~~~~

---

first time? Could you confirm if it does? (I know you are a big fan of WW ) Could you try running bigfix after starting WW?


I just tested it. I denied BigFix access to the net within ZAP, and BigFix was unable to access the net, even though I use WW. Hence, ZAP does stop applications from accessing the net, even if you use WW.

said by Zhen-Xjell:

---

I just tested it. I denied BigFix access to the net within ZAP, and BigFix was unable to access the net, even though I use WW. Hence, ZAP does stop applications from accessing the net, even if you use WW.

---

Yes, BigFix was trying to access 127.0.0.1 port 8080.

reply to wiregauze

ZAP.zip 41,325 bytes (ZAP.bmp)