Broadband Tech > Security > Security > Tiny + WebWasher Users

reply to Zhen-Xjell

Re: Tiny + WebWasher Users

said by Zhen-Xjell:

---

Yes, BigFix was trying to access 127.0.0.1 port 8080.

---

said by wiregauze:

---

. So, solution would be: when Tiny does not find MD5 checksum in its table, it pops up an allow/deny dialog box; yes, even if its ruleset permits. Obviously this requires an update from Tiny.

-- wiregauze

---

reply to wiregauze
Very interesting indeed is all this. I do not have the time to learn Tiny, but this does not mean I will never try it just to understand what all the talk is about.

However, it is a good thing this certain case has been caught. Yet again, ZAP is proven.

reply to wiregauze

lt.zip 11,045 bytes

What is the Loopback rule in my filter rules?
The default installation of TPF includes a few predefined filter rules for a more convenient administration. Although you are allowed to remove these rules, you must not remove the Loopback rule because it allows TPF to communicate with your operating system. By removing this rule you will no longer be able to access the administration.

Why can't I access the administration?
This can be caused by two reasons. If the engine is not active you cannot access the administration or status monitor. If you have modified or removed the loopback rule you may not be able to access the administration. If this is the case then you should restore the original configuration by removing the persfw.conf file.

This is from TPF's site, I have had no problems, Denying the loopback rule,but just incase someone does, Here are the warnings.
--
Companies would rather lose you as a customer than fix the problem
Vampirefo

Joke Page

said by Vampirefo:

---

What is the Loopback rule in my filter rules?
The default installation of TPF includes a few predefined filter rules for a more convenient administration. Although you are allowed to remove these rules, you must not remove the Loopback rule because it allows TPF to communicate with your operating system. By removing this rule you will no longer be able to access the administration.

Why can't I access the administration?
This can be caused by two reasons. If the engine is not active you cannot access the administration or status monitor. If you have modified or removed the loopback rule you may not be able to access the administration. If this is the case then you should restore the original configuration by removing the persfw.conf file.

This is from TPF's site, I have had no problems, Denying the loopback rule,but just incase someone does, Here are the warnings.

---

That sounds very good then! I'm glad Tiny has such a work around.
[text was edited by author 2001-05-25 14:08:45]

said by Zhen-Xjell:

---

That sounds very good then! I'm glad Tiny has such a work around.

---

reply to wiregauze
My problem with the whole thing is that this is a situation peculiar to running a proxy server on top of Tiny, not an everyday usage problem; it's by no means a bug or a flaw in the firewall. If the proxy can't be set up to filter things itself, then it's a far and away weaker security solution than Tiny, and using it weakens Tiny, because the rule allowing it allows everything that it processes... a good filtering proxy should be able to be configured to block traffic internally, but it won't work at the level Tiny (or zone alarm, or whatever) will... proxies are by nature more vulnerable than packet filters. Proxies are firewall tunnels, in almost every sense of the word, and that's just the way they work. They have to be carefully configured, themselves, or they can quickly and easily become a bigger problem than a solution.

The points, summarized, that I think are most important, are:

1. localhost is the local machine. Therefore, traffic TO localhost FROM local apps doesn't bother me a bit... only localhost or the app listening on it contacting outbound to another IP does, which is handled without error in the due processing order of a good ruleset. Localhost is not a security vulnerability in this context. (localhost to a foreign address is, but I think we understand that)

2. the apps do get fingerprinted, when they access the proxy through localhost for the first time, because they have to go through the firewall to do so. If the apps are changed, they should pop up just like any other app. Just deleting the MD5 won't cause a popup, though... it'll just recalculate the hash and store it again... only if an app turns up with a hash that doesn't match an existing entry in the database will it alert you... which makes total sense, since you have no known reference to compare with until you get a hash from the initial install.

3. All servers have to be accessed by ports and sockets, whether proxy, FTP, web, telnet, or mail... they MUST establish a connection and listen somewhere. The windows API is not an option. So they use "localhost," a virtual mapping back to the same machine, and open their connections there, when the access is from the local machine. You could set up the proxy to listen on the machine's assigned local IP, too. There are other security issues in doing so, but it works, if the server allows you to choose the interface to listen on. But that's the nature of this beast, and it has to use that IP...

All told, the problem's not Tiny. I don't want Tiny re-engineered to accomodate specific proxy configurations, myself. Those are problems to be worked out system by system... if they started adding features to anticipate every possible user configuration, this nice compact firewall would soon be bigger than MS Word, and would be dilluted as a firewall by becomming a multifunction security gateway.

However, if the filters in the proxy server can't be set up to block and allow applications, then re-engineering the proxy server might not be a bad option... however, as we all know, proxy servers are much more leak-prone than packet filters... much.

If I were in this position, myself, I would either reconfigure the proxy to accomodate the firewall, or dump the proxy server and get a good cookie management tool and such in its place. I haven't seen a proxy yet that I would consider better than any firewall if I had an either - or choice of only one. If the proxy can't be set up to filter the programs, that's who I would personally say should re-engineer their product, not just for firewall users, but because that's simple, basic filtering proxy functionality that should be in there.

Tiny is a great firewall, and I welcome new features... but I don't want them dilluting it by trying to anticipate all of the possible configurations and adding special functions and potential points of failure and miles of new code to a product that works so well, as it is, doing one thing and doing it quite well. Proxies of the type we run at localhost, as opposed to those run to share connections, by definition, filter, and a good one should be able to implement application filters inside the proxy, so as not to pass unwanted requests to the firewall as outgoing at all... if they can't, they're not complete and top notch filtering proxy servers.

I see no problem at all with the way Tiny handles localhost traffic, myself... the problem here is how to get proxy traffic over the firewall, but still retain the identity of the originating app at the firewall... or, more poetically, how to have our cake and eat it, too. The simple answer is there is no simple answer. You either have to filter localhost to retain originating identity, or rely on the proxy to filter the traffic it carries. If you don't or can't trust the filtering proxy to filter, then it behooves me why it would be running at all. A good set of proxy server filters and some careful decisions about what apps benefit by going through proxy and which are better off going straight to firewall should be more than adequate. Myself, I ran only IE and other browser type apps through a proxy, for quite a while, but I sent everything else direct, straight to the wall, so I could adjust filters appropriately there, where security's the tightest. I've since abandoned the proxy entirely except for troubleshooting or tunnelling, simply because it wasn't worth its own overhead, once I got my ruleset tuned up.

Just take out the localhost rule, to filter what goes to the proxy, but you'll also have to manually allow/deny anything else that uses localhost for support, including firewall stats and such.

________PS:
I learned a great lesson, by the way, this morning, and pass along a WARNING!!! I set my TPF to log localhost rule... forgot I have a syslog daemon running on the same machine. As soon as tiny made one, just ONE, log entry, syslog used localhost to log it, which created an event on rule 1, which logged, which created another event, ahhhh ... you programmers understand what I'm saying... I got a beautiful loop, and a 9 MB log file within a few minutes... so... moral? Be careful while testing things... it's so easy to overlook an obvious detail like that.
--
Man will occasionally stumble over the truth, but most times he will pick himself up and carry on. - Sir Winston Churchill

reply to wiregauze
While using WW,Rather than remove the loopback rule, I just uncheck it, by removing the check mark, it disables the rule, and all works well, If I am not using WW, I recheck the rule. I will spend some time on this problem, This weekend and see if I can come up with a set of rules to work well with WW.

That's a great thought... cool. Yeah, I was upset when they briefly removed the checkboxes from Tiny. I had become so used to running a pair of rules (before they added the dandy little ZA type "cut me off" function) that could be checked when I left my machine to effectively do just that... but, without checkboxes, they became perfectly useless as "emergency rules," much less for the original purpose. One of the nice features about Tiny... you can have special case rules at your fingertips in the task bar. Great tip.
--
Man will occasionally stumble over the truth, but most times he will pick himself up and carry on. - Sir Winston Churchill

reply to Vampirefo

said by Vampirefo:

---

While using WW,Rather than remove the loopback rule, I just uncheck it, by removing the check mark, it disables the rule, and all works well, If I am not using WW, I recheck the rule.

---

I don't guess that something like that would be too heavy, but could create a stream of popups, be mindful. Just because an app registers an MD5 doesn't mean it's accessing the internet. ALL the MD5 does is ensure that an app isn't replaced by a trojan, or that one with a similar name doesn't slip by through an app specific rule.

One problem Tiny does have, for new users, is that lets the user see so much of the process. Zone Alarm is handling proxies pretty much the same way, but it isn't as obvious what's going on. If ZA doesn't have a default allow for localhost, then, of course, it's prompting on every loopback... as Tiny will if you remove loopback. I don't consider that a big security issue, though, as stated above. Knowing, as we do now, that a proxy is a natural firewall tunnel, though, is vitally important, and you couldn't be more right that new users need to understand how that is, and why it can be bad. Thanks for the ongoing discussion... I learn something everytime I take on a problem like this, and this is no exception... sometimes, I look at Tiny from the viewpoint of someone who's used it for several months, and I forget how it felt looking at a new firewall for the first time... yes, there are a lot of things that a new user has to get comfortable with, before we can say that we fully trust any firewall, and feel articulate working with it. Wish you lots of luck, and safe surfin'... pleasure discussing this with all... good sailing!
--
Man will occasionally stumble over the truth, but most times he will pick himself up and carry on. - Sir Winston Churchill