Outpost Firewall Pro 2009 Testing and Optimization Thread

good to see you over in these parts of the interweb Manny

 

Hi Manny and Stem:

I removed the bank ip's from my excluded list, ie I not longer told OP I trusted those sites.

Then I logged back on to the https bank site it worked fine so the client # and psw were packeted okay!

Thus I can confirm what you guys probably already already knew that this OP feature only works in the clear as Manny has indicated.

As far as a comment on the value of the feature it does prevent private data from going to non secure sites so that indicates it has some value.

But now I'm thinking why put any sites in the OP excluded or white site list? They would probably all be https anyway.

Anybody? Having a mind freeze again.

 

Good question and I don't know, but I've never used the exclusions list anyways. Also, thank you for testing the blocked content feature; you've shed some valuable light on the feature

 

Always glad to help a fellow citizen! Testing is how we get rid of opinions.
But only if the testing is correct and the tester is willing to accept his own results. I was and am better off. Some may say well we already knew this or it was in the documentation. But the thread is about testing!

 

True, but testing can result in opinions based on facts, rather than conjecture or emotions, and that's a good thing. We need more threads like this

 

Exactly, like in high school science lab, Purpose, Method (testing) , Observation, Conclusions. No emotion, just a theory being tested. If the results are a surprise, improve the theory.

Couldn't help but think of the quote :

" .... don't confuse me with facts my minds made up!"

anyway, let's move on to a new test. any suggestions?

 

Thank you. For some reason I usually have to be given a little shove to come over to this nice place. Too many other things going on I guess.

The ID Block feature, although not entirely useless, is of limited utility really. It does do what it says - block any data sent in the clear and does nothing for encrypted data - but most of you don't really keep important data that's easily accessible on your machine. Almost all places that need a password are HTTPS and data is going out encrypted so nothing happens with ID block.

With the exclusion list you can block data from being sent to anywhere except specific site. But you got to train it and where is this useful? Say for a forum like this say, I don't really care if somebody gets my password. I mean who would bother anyway?

I guess for me, the bottom line is that if I don't want for somebody to know something important, like say a bank password, I just don't keep it on my machine. Nobody can get it like that no matter how infected my machine gets. Then when I need to use it, I want it to be sent not blocked. Consequently, I don't use this feature but if somebody finds it useful well then, it's a good thing.

 

Hi Manny:

This post may be OT in my own thread and probably should be in the privacy forum.

I agree partially, on my set up and no doubt yours, the key data is not easily accessible. My bank codes are on an encrypted stick removed physically from PC until needed.

But many of the people I try to help, (not members of security forums) do keep key private data in the clear. PSW's account numbers, wife's name the list goes on. So for them the feature could help if they use it.

Maybe I should just set them up with an encrypted HD and forget all the work they resent doing to secure themselves. These nice folks don't change the oil on their cars either and then wonder why the car breaks down.

 

On ID block feature, I have placed my SW product license numbers into the table to be protected. Yes yes I know in the clear. Then I proceeded to initiate updates for them. They all update in the clear!

Interesting! a SW product a register utility did ask for the licence code before updating , OP blocked the packet and the vendor disallowed the update.

So again I entered their ip into the excluded list, then tried again. The update succeeded.

Observations:

1) some vendors use these licence codes only to install the product at first then never use it again.
2) some vendors request the code at update time and even though the packet is blocked, allow the user to update anyway
3) some vendors block the update completely unless the code is fed back prior to update.

Comment

If I was a vendor (I'm not) and I was complaining about piracy I would adopt policy 3.

A Design flaw (IMHO) in OP is once I enter an ip in the exclude list it would allow any licence number or any other protected information in my set including credit card numbers to be fed to any of the sites listed there.

I would like to make it selective, just that license number to that site.

But once again I don't expect many users will care.

 

Re: Hardening my Nod32 update rule

As many of you know, Nod32 uses 26 different sites/ip address to carry out it's signature updates. They recommend setting it on choose automatically. In earlier 3 rd party FW's, I was not happy with 26 different sites for updates as some of those were in blocked countries. Why would I want security updates from a blocked country? (don't answer that!) So I had to choose 1 site to get my updates from.

So what I have done now with OP Pro FW is to place a subset of 4 acceptable sites into the NOD32KRN.EXE rule set in OP FW pro yet still left the Nod32 update setting on automatic.

Attached are 2 images,

1) The translation of Nod32's sites into addys showing countries and networks
2) The OP rule for Nod32krn.exe with my 4 addy's.

As readers will see I choose the 4 ip's from Eset's own network and left to others the remaining sites for others to use.

This shows how one user (me), used OP to harden / optimize my settings.
Making updates ip specific reduces risk.

This is not a learning thread or is this post a general recommendation, users need to think through their own needs based on their policies.

 

Hi Stem.

In the application rules for OP FW Pro, it shows activate stateful inspection at the application level.

This is new to me.

Somewhere I read that global application of stateful inspection is not a good idea thus this application by application option. If this is the feature that lists expected incoming packets as the outbound is sent out then I think I get this notion. But how then do I choose which to tick and which to leave blank? Or do I just let OP generate these choices for me during learning mode based on the assumption that the OP developers know what they were/are doing?

If this is OT becuase it isn't a LT then feel free to split it off as with the ARP posts.

 

Hello Thread posters and readers:

One feature that continues to interest me is the content blocker. Now based on what the experts have told us https is secured via encryption so the OP SW can't read it to *** fill it or block the outgoing packet but that is fine as if you are going to your OLB you need to send the account # and password anyway to carry out your personal business, https and encryption is exactly what we want.

Now as some know I've been working on some tests where I put SW license numbers in the list of numbers to block and this works well as I have found these updates work in the clear! ie http.

All I can tell you guys is that the results are very interesting, I put all mine in and then reviewed the logs to see which vendors ask for my licence numbers or other information in the id block list.

1) Some don't ask
2) Some do get blocked via the content blocker yet update anyway
3) Some ask for the licence #, the cpu id, the hddp0 id etc yet still allow the product update
4) One denied the update and forced my product back to the demo version as if I never paid for it!

On number 4 I removed the product an cancelled any future renewals. No it wasn't OP.

I won't post the names as each can do their own tests. PM me if you need more info and I have posted some information at the OP forum.

Once again we see that trusting vendors is a buyer beware situation.

I have no complaint that vendors ask for my licence number to protect themselves from piracy BUT I don't like the way they send it in the clear!

Why don't they treat updates as https.

 

IMO Probably they want to avoid threads or accusations like: "product X is calling home with encrypted personal information" There will be then no way for users to cross-check this information or control the type of information that is sent.

This is why products like PREVX send everything in clear (unless they changed it recently), with a sniffer you are able to see exactly what information has been sent.

So, more transparency but with some drawbacks

Fax

 

Re: Outpost Firewall Pro 2009 KeyLogger Tested Live

Observation:

I subscribe to PC World electronically. Just downloaded the July issue the other day. Today when I went to access the new issue I got a pop up from OP FW Pro 2009 paid version indicating the attempted use of a KL via direct access: Here is the log record of the block. It had zero effect on my ability to read the magazine. I will now check the FW rules for this exe and block as required. The magazine in digital form has imbeded links to many sw vendor sites.


5:06:57 PM Block ZINIOREADER.EXE: 1440 keylogger Access through DirectInput technology

Please don't use this post to blast my choice of reading material


Sorry to be slow but I did finally have time to review the rules for this and for now I just blocked it from having any www access in or out.

 

Re: Outpost Firewall Pro 2009 KeyLogger Tested Live

hehehe whoa!!
dont worry Es-man I get the same issue sometimes with Penthouse

 

Re: Outpost Firewall Pro 2009 Optimization Thread

In the hope of rule improvement or optimization, I've attached my rules for SVCHOST. I make no claim of perfection for these just hoping for some professional peer review ( remember those days?)

My only caveat here is I would prefer not to deal with posts saying "remove all these block rules as not required" since OP automatically takes care of them". I say this for several reasons:

1) I'm not prepared to assume that OP does these blocks since my own testing is incomplete. I'm not saying OP doesn't block with no allow rule specified I'm just not assuming them away.

2) For a improvement leaving these rules visible is needed

3) I have added certain ports for special attention 5000, 1900 and 135.

Now my questions,

1. How can these rules be strengthened? Provide a rationale please.
2. How can these rules be corrected or simplified? Provide a rationale please.

Please post your own OP rule set just as I have to show us your own example, it's work I know but then again no pain no......

 

Hi Escalader

No svchost rules seen for the time updater or any icmp rules (just tcp and udp only).
I am guessing the dhcp client service is disabled in windows, hence the lack of dhcp rules for the svchost.

 

Certain services settings are on others off:

1. DHCP is started as I get address translation that way
2. DNS of course is disabled in favour of 1
3. Windows time is disabled
4. ICMP rules are in OP but as network rules not application rules

 

Here is a screen shot showing the default settings for ICMP in Outpost Firewall Pro 2009.

What is good in this table design is it shows both directions clearly and doesn't leave the user guessing about how the unlisted message types are handled.

I have made only 1 change to the defaults on my own set up.

 

Hello Thread:

FYI there is a new version out of OP Pro 2009 and as I have upgraded to it the thread will continue with the new version. Here is the link:

http://www.outpostfirewall.com/forum/showthread.php?t=24372&page=3

 

One test I do with 3rd party FW's is their handling of the windows FW when the third party FW is installed and then again when it is disabled or exited manually by the user.

Right clicking the OP FW Pro icon offers users the ability to:

1) Disable
2) Disable self protection
3) Suspend Protection
4) Exit

So it seems the designers anticipated that there was a need for these 4 "off" options.

Now when OP FW Pro in installed and activated with the windows FW 'on" OP FW Pro correctly (IMHO) automatatically turns windows FW off. This is good.

However, when I tested the 4th option Exit I found that the Windows FW was not turned back on automatically. IMHO this is not good practice.

I have reported this to OP but it seems that at the moment it is viewed as normal behaviour.

So this post is a warning to readers that if for whatever reason you use the Exit option don't assume that Windows FW is turned on for you. It must be done manually.

I hope OP alters this in the future.

 

I certainly would hope not and would vigorously oppose the suggestion to turn on anything behind my back when I turn off the firewall. If I turn off a firewall I want it off and all others as well. That, as far as I'm concerned, is good practice.

 

In https://www.wilderssecurity.com/showpost.php?p=1507379&postcount=44

I showed the thread the OP defaults for ICMP.

The only change I made was destination unreachable in v4. Cleared the box for outbound only. Left the acceptance of the inbound.

This idea is in suggested OP documentation and I claim no credit/blame for it as to how it will work in your setup.

If you are a P2P user this change should probably be avoided during that activity.

 

Hello Thread:

For about a month I have been running okay with explorer blocked from www access. It can run so I use it to open folders as per usual but as IMHO it doesn't need www access I used OP FW Pro 2009 to block it.

Attached is the rule set I have for it.

Again this works for me but others will have:

1) Different views of the wisdom of doing this, that is expected in a forum
2) Different results from doing it.

This demonstrates the ease of rule creation as well that can be used on any executable the user wants to constrain.

 

When I had Outpost 2009 Trial Installed the Ruleset for Windows Explorer was:

Where the Portocol is: TCP
and the Direction is: Outbound
and Remote Address is: 192.168.1.0/255.255.255.0
Allow

Where the Protocol is: TCP
and the Direction is: Inbound
and Remote Address is: 192.168.1.0/255.255.255.0
Allow

Where the Portocol is: UDP
and the Direction is: Outbound
and Remote Address is: 192.168.1.0/255.255.255.0
Allow

Where the Portocol is: UDP
and the Direction is: Inbound
and Remote Address is: 192.168.1.0/255.255.255.0
Allow

Where the Portocol is: TCP
and the Direction is: Outbound
Block

Where the Portocol is: TCP
and the Direction is: Inbound
Block

Where the Portocol is: UDP
and the Direction is: Outbound
Block

Where the Portocol is: UDP
and the Direction is: Inbound
Block


HKEY1952