OutPost learning thread

content filtering isnt necessarily web site focused, but it does aim at filtering content that comes in through the web. any process that you have content filtering enabled for, outpost will try to filter it, so its up to you to use it in the right way. you can use it to block ads in messaging clients, email clients, and of course browsers. if you were to use an adtracking hosts file, in conjunction with properly configured content filtering, theres little chance youll see any ads

 

Thanks for this!

 

no troubles mate

 

Hi guys,

Recently I had noticed my service that belongs to my AV has been blocked all the time in the log under blocked content even though there is rules made so I disabled content filtering and blocked raw socket access and viola the entry dissappeared in the log.

 

Hmmm a blocked site ? Or was the filtering finding something content wise in the updates and just dropped the packet(s)?

This option to content filter should be withheld from guys like us that may not see consequences of taking the tweak option from a vendor.

 

Could be. I would like to know exactly what it's filtering. I have had trouble with windows update recently (it's the first time since OP has been installed) it took three reboots after and it would loop and not go into windows so I had to do a hard reset each time and finally the last time it configured the updates afterwards.

Next time I'm going to disable the content filtering and raw socket and see what happens. That will probably be on the next installation of windows.

 

You will face some problems, not only due to the printer possibly changing IP but also with how the printer is found on the LAN, probably by netB or uPnP.

Most vendors in that situation would simply advise setting the LAN as trusted(or similar) which then causes some concern for security, be it from possible unwanted connections to other nodes, or possible intrusion into the wi-fi network.

- Stem

 

I have not tested to see what packets are filtered or how accurate the filtering is. I will see if I have time over the weekend to run some tests.


- Stem

 

Stem:

Yes, the hard wired gaming PC has complained of finding the router "busy" with same ip assigned! This condition seems related to the notebook coming out of hibernation or sleep mode.

The wi-fi network is wpa2 personal with a 63 position random password. So you need to crack that to access.

The Canon multifunction wireless device prints and scans also has been given the same password via loading that via USB stick

The 198.xxx.yyy.n lan is set in OP to accept file/printer sharing to from this network. I have it set as untrusted.

What are your thoughts? Changes?


I could move to a mac id setup so only those devices can connect, but I understand that has it's own issues.

 

As this is a learning thread (LT) I thought I'd paste the order rules from OP's Knowledge base. Note where applications rules come! If an allow or a block occurs prior, the applications rules will never be reached. These are ordered top to bottom.

The assumption is that OP is implemented the same as the documentation.

[SIZE=+1][/SIZE]

 

I don't remember seeing it mentioned, but what is your opinion about the svchost.exe rules (two of them) for windows time?

The rules are something like.

UDP; 37, 123; Allow (This is outbound, despite not specifically mentioned)
TCP; Outbound ; 13, 37, 123; Allow

Port 13 is for Daytime service.
Port 37 is for Time protocol.
Port 123 is for Network Time Protocol.

Have you left them as it is, or restricted it a bit more?

 

Definatly restrict this monster!

I don't need the PC to go outbound to know the time of day!

 

What for? It's harmlessly connecting to a time server to synchronize the clock to it.

 

The policy I use is different. Deny by default allow by exception. I don't known what time server the post is asking about one is M$, another was the federal government... I'll just pass on it.

 

Heck, you got me scared for a brief moment with the monster.

My only doubt was if Outpost was, once again, only being too generous with the allowing rules, to embrace a larger target (users). There are a lot of unneeded rules, which are only there to make things easier for everybody's tastes.

Monsters aside, would all 3 connections be required for it, or not at all?

 

I also follow that policy, but only to a limit. At least, for stuff I'm not sure if it's 100% fine to just block straight away.

 

UDP, inbound/outbound, remote port 123 should be fine.

 

Yes, that's the rule I already had added. Wasn't sure about the other two.

It would be a lot easier if Outpost had rules by colors: red for those that, indeed, are needed; green for being there for the general purpose (every users needs).

On the other hand, it does make one dig for more information about stuff that should or shouldn't be allowed.

 

That's what they're doing, making it easier for those who don't have the expertise to customize the rules themselves, which the majority of the user base falls into, I'm sure.

 

One general rule users can follow is just untick a rule they suspect is NOT needed. Set it to report. Run for a day or so if it doesn't nag you or appear in the log/report as needed, delete the rule.

One by one you can shrink all the "monsters". Must be near the great pumkin day!

 

Escalader,
Please do not dismiss so fast the need for time servers.
When the clock battery dies, at least in laptops, you have to buy a whole motherboard just to have the clock running ... speaking from experience

Use port 123 both local and remote, as wat0114 says in post#142. You can add these IPs with masks if you wish since Outpost permits masks.
time-a.nist.gov 129.6.0.0/255.255.128.0
time.nist.gov 192.43.244.0/255.255.255.0
time.windows.com 207.46.128.0/255.255.128.255

If your firewall permits use of IP groups, one rule does the job. UDP both directions, local port 123, remote port 123, remote IP time servers group

 

That's a great idea, indeed.

Not sure if you could shed some lights on a few doubts I have about some rules?
The doubt I'm having is related to some rules like system-wide rules like so:

That's a default block rule. Now, the doubt is: Incoming out outgoing traffic? Or is it for both, actually?

And, what about low-level rules:

I'm guessing low-level rules are also for both incoming and outgoing. Am I correct?

I'm 99% sure they are, but the 1% of doubt is "killing" me.

 

Block the incoming period. UDP is often seen as direction-less which is very confusing to us the common user guys. So I add direction to UDP only allowing outgoing connections. Unless you are running a server incoming UDP makes no sense at least to me. Stem could weigh in here if I'm off base.

On these other lower rules you are suffering doubt, just disable and report as discussed earlier.

When the log says Blocked it is just reporting that the FW is doing it's job.

 

Hi:

Interesting. On your motherboard burn up how can users know that the time services being ON would have saved your motherboard? Motherboards do burn up but usually from a hardware / chip failure, heat, accidentally dropping coke on it etc etc.

If there is a link to a technical source on the absolute need to use these time links I for one would like to check it out.

As to constraining the outbounds via ip addy's and masks absolutely a must do for all outbound links.

 

When you mention both directions, do you mean one inbound and one outbound rule? Or one outbound rule?