how-to block ads
|
|
Share Topic
 |
 |
|
|
|
 Zhen-XjellProlific BunnyPremium,VIP,ExMod 2001-04
join:2000-10-08
Bordentown, NJ
| reply to wiregauze
Re: Tiny + WebWasher Users 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] | |
 gwionwild colonial boyPremium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1
| 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] | |
| said by gwion:
"1. Deny application bigfix - any IP, any remote port, any local port."
2.the localhost rule
3~~~~~~
4~~~~~~
~~~~~
gwion, I see your point, and I appreciate your continuing replies  . What I am worried is not bigfix itself. What I'm worried is what if I have a spyware that I don't know about. Clearly, I don't have rules for the spyware, and it will just use the proxy (WebWasher) to access the Net. And, Tiny doesn't know about it at all! Therefore, setting rules as the above really doesn't make sense to me.
I am NOT saying Tiny has a hole; in fact, by setting up a proxy, it is I who is deliberately piercing a hole in Tiny. However, as a greedy user , I want to have the same level of security as if I didn't have WW, if possible at all. Put it another way, I want to have the same level of security even with WW.
Now, you mentioned setting WW to allow only certain applications to connect to WW. Ideally that would do, but WW lacks such functionality. In fact, if WW has such functionality, then WW, too, has to have MD5 checking to see whether a certain application is modified or not, just like Tiny.
Since WW, or any other widely used proxies do NOT have such checking, I want to setup rules for Tiny to do the job -- this is essentially my original solution. As you said and I wholeheartedly agree that it is a tedious job...
Now if a novice user who feels safe just because he has Tiny. He later installs WW and gladly allows it to access to the Net. What he may not know is that any application can talk to WW and in turn access the Net without getting caught.
This is my concern. No one (maybe except you, gwion) I've seen talk about this problem so far, and certainly not understood clearly enough even if anyone did.
gwion, I hope you agree with me on these:
Does Tiny have a hole? NO.
Does WW have problem? Possibly.
Does Tiny and WW creates a hole? YES!
So, what do we do about this? Easiest way I think is to remove the default loopback rule. This might mean tedious mouse clicks for a while, but it's easy enough to Tom and Jane keep themselves secure.
The easiest solution is to make Tiny alert when a new application tries to make a connection for the first time (even loopback!) even if rulesets allow. But, for that we need to talk to tinysoftware...
Again, this may or may not be a problem in ZA. If ZA has default rules to allow loopback traffic, I guess it is a problem, too.
I'm glad Zhen-Xjell joined here . Z-X, does ZA alert when a new appl makes a local connection for the 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?
gwion, like you, I consider myself a Tiny fan. The reason I keep searching for an effective solution for this is I do not want Tiny to be seen as more vulnerable compared to ZA (it is not!).
Regards,
-- wiregauze | |
Zhen-XjellProlific BunnyPremium,VIP,ExMod 2001-04
join:2000-10-08
Bordentown, NJ | 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.
Did ZAP say bigfix was trying to access 127.0.0.1 or some other IP?
-- wiregauze | |
Zhen-XjellProlific BunnyPremium,VIP,ExMod 2001-04
join:2000-10-08
Bordentown, NJ | Yes, BigFix was trying to access 127.0.0.1 port 8080. | | |
|
 ethics$Premium
join:2000-12-27
Brooklyn, NY | reply to wiregauze
Just starting reading this thread and ran a similar test with WW on with proxy configured and tried to start up my Punkbuster. It came up with the correct name (PB.exe) as to what was trying to access the internet.
--
Folding can save a life!
| |
| reply to Zhen-Xjell
said by Zhen-Xjell:
Yes, BigFix was trying to access 127.0.0.1 port 8080.
Thanks Z-X, and same to ethics13 for captured images. Looks like ZA (at least ZAP) seems to block even local traffics by default. That's good .
So, so far the problem is confined to Tiny (I don't know about other firewalls, though).
For more than a day, I have been running Tiny without its default allow-loopback rule, and so far the number of applications/services that require loopback connections seem to be very limited. There could be more because I don't use any NFS/ICS/NetBIOS/etc, though.
For about a week, I tried several configurations, and I think for now there is only one option that is simple enough for average users: remove the default loopback rule. This will effectively catch any applications that tries to WW.
More fundamental solution I think should come from Tiny Software. While leaving the default loopback rule intact, Tiny needs to fire up an allow/deny box whenever new application tries to connect to any port even when Tiny rule permits. This will effectively block spyware trying to reach its home through a proxy. 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 | |
ethics$Premium
join:2000-12-27
Brooklyn, NY | 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
I am actually surprised that with the flexibility that Tiny has, ZAP was able to pull one over it.
BTW, I will probably try Tiny in the near future. I'd like to see if it's applicable to my network at home more than ZAP.
I am sure this problem this thread has addressed *will* be fixed.
--
Folding can save a life!
| |
Zhen-XjellProlific BunnyPremium,VIP,ExMod 2001-04
join:2000-10-08
Bordentown, NJ | 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. | |
 VampirefoPremium,MVM
join:2000-12-11
Huntington, WV
kudos:1
| reply to wiregauze
edit
[text was edited by author 2001-05-25 11:55:36] | |
VampirefoPremium,MVM
join:2000-12-11
Huntington, WV
kudos:1 | 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.
This is yet another example how crude I am in reaching to a conclusion  . Thanks, I never looked at that that page of Tiny web site. Obviously, if it can cause a problem for someone, it shouldn't be advertised as general solution.
Then, what options do Tiny users have... It comes back to the solution in my original post of the thread. It's very tedious one, so I guess it's not easy/simple enough for average users.
Looks like the easiest way is update from Tiny. In short:
Even if the ruleset already permits, alert the user whenever a new program tries to connect any port for the first time. Alternatively said, alert the user whenever the application's MD5 is not found in the table, regardless of what the ruleset says.
I'll try to talk to guys at Tiny.
-- wiregauze | |
Zhen-XjellProlific BunnyPremium,VIP,ExMod 2001-04
join:2000-10-08
Bordentown, NJ
| 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.
I'm sorry, in case I didn't misunderstand, the possible workarounds are not for general mass (not simple enough), as far as I think.
And the easiest fix, the "update" from Tiny is not there yet. We need to ask Tiny to include the update in the future release
I sent them an e-mail including a link over here. I'll wait and see if all these make sense to them .
-- wiregauze | |
VampirefoPremium,MVM
join:2000-12-11
Huntington, WV
kudos:1 | 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. | |
gwionwild colonial boyPremium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1 | 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.
That's great, too. As gwion restated several times, that's the power of Tiny -- flexibility.
We all agree it is not that Tiny has an inherent problem. The problem is average users may not know the fact that setting up a proxy means putting a hole in your firewall. Many times, users do not even know they are setting up a proxy. People just download, install, and go.
ZA/ZAP seem to block even local traffics by default, one might say "hey, ZA caught this! Why Tiny can't?!" As more and more users use firewall and some type of filtering tools, accumulation of such incorrect (bad?) reputation is good to no one.
Again, I'm open to any simple solution, such as the one Vampirefo suggested.
But, I'm still hoping to see what Tiny Software wants to say, because the change I suggested is neither confined to a specific third party application, nor difficult to implement (I think). Indeed, all I'm suggesting (well, at least at this point ) is to raise an alert box whenever a new application tries to run regardless of what ruleset says. This will effectively make Tiny work like ZA for this matter, thereby alleviating possible negative reputations or critics. (Of course, good for me, too  )
-- wiregauze | |
gwionwild colonial boyPremium,ExMod 2001-08
join:2000-12-28
Pittsburgh, PA
kudos:1 | 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 | |
|
