OutPost learning thread

What I verified works for me:

Protocol=UDP
Direction=Outbound
Local port=123
Remote port=123
Remote ip=Network time server (eg:time.nist.gov)

Only outbound is needed, though you could include inbound as well.

 

That was my doubt. But, since UDP is connectionless, only outbound stating a local and remote port suffices. Am I right in this assumption?

I'm guessing same would go for DHCP as well?

Same with this one, I think:

UDP; Remote Port 1701; Local Port 1701; Allow/Block (It's for L2TP - Layer Two Tunneling Protocol)

Whenever Outpost a rule like one of those two, where there is UDP and both local and remote port, then it means it's an outbound rule. At least, I'm leaning to think this way.

If anyone could clarify it a bit further, I'd appreciate.

I'm in a learning process. For too long I've not cared about firewall rules, at all. Time to care and to understand them better. Also, because I do need it. lol

 

I'm not completely sure about this, but afaik for DNS it is essential to specify both directions, or its functionality will be crippled.

Yes, but, from what I've seen, two separate rules are needed:

DHCP Request from local port 68 to remote port 67

DHCP Reply from remote port 67 to local port 68

That one I don't know about. Maybe I'll find something on it sooner than later.

 

Okay, here's how the Win 7 fw has this set in the defaults:

Outbound Rule

Application=System
Protocol=UDP
Direction=Outbound
Local Port=Any
Remote Port=1701

Inbound Rule Rule

Application=System
Protocol=UDP
Direction=inbound
Local Port=1701
Remote Port=Any
Advanced: Block edge traversal (from router)

Remember that Win fw rules separates the outbound rules from the inbound rules, so it seems reasonable for software firewalls that only one rule could be created as:

Outbound/Inbound

Application=System
Protocol=UDP
Direction=inbound & Outbound
Local Port=1701
Remote Port=1701

 

Yes, indeed.

Both rules I mentioned, and one more

which Outpost treats as a low-level rule are for remote access. So, if one disables remote access, which I have that way, then Windows firewall rules allowing that traffic become disabled.

 

Here is an excerpt from preset.lst from Outpost v2 I believe regarding svchost. This was used on XP Pro, so I don't know what might be different in win7. I haven't messed with firewalls in win7 much.

Later I made a generic DNS rule something like this. When a process requested DNS and I trusted/knew about it, I would apply this to the process.

and this was applied to things requesting DNS that I did not know about.

I used to build lots of rules for every application, and each rule had a DNS value in it. The process was to apply a rule to everything that went out. Some things were flatly denied, and very few were implicitly trusted. 99% of items had a rule assigned. I was using Proxomitron back then, so you see that reflected here. This was the K-Meleon rule from my preset.lst. When I reinstalled, I put this file in place, then when K-Meleon was run the first time, I chose this rule instead of one for a generic browser.

Later, as I tired of managing every process, I made global rules that allowed communication to only my 3 DNS servers on those ports, and denied any other activity on those ports. The method of allowing/denying DNS per application is definately raising security, but is a lot of work.

As time went by, and I desired less and less to micro-manage issues that were never present, I started using the above svchost rule with this as the only other rules

When it came to the Time service, I always set it to manual. If I want to update the time for some reason, I could manually enable it by using this in run box: sc start w32time - OR - net start w32Time. TBH though, I have never had a need to use that service in all the time I have been using a computer. The bios stores it, so if you reboot it remains. If it resets on a power outage etc, it is time for a new battery on the motherboard.

Sul.

 

What I noticed so far is that Outpost only has an UDP outbound rule for DNS, and inbound traffic is blocked.
Windows firewall also only has an UDP DNS outbound rule.

Regarding DHCP, I believe the Outpost rule is for both Inbound/Outbound. Same as Windows firewall; except that the latter works with separate rules, while Outpost mixes them. Does it make any sense For me it does, taking Windows firewall as a guide.

It seems to be a lot easier to understand the rules with Windows firewall. Some Outpost rules are quite confusing (those of system-level and low-level rules).

 

That's odd?? Actually, seeing Sully's posted rules (much older versions of Outpost) there're no directions specified for dns which, now that I remember (haven't used Outpost for a while), was the case for that firewall. Specifying directions in Outpost older versions at least crippled the dns traffic.

Just goes to show not all host-based firewalls handle all rules the same

Sure because: see my above quote.

Yes, I agree Windows fw rules are, for the most part, relatively straightforward - at least the ones I consider necessary. There are, of course, just like in other firewalls, so many rules that the average home user will never need, especially on a non-networked pc. However, I have found it much easier creating and modifying Windows fw rules based on using Jetico 2 rules which have been created on-the-fly through its informative pop-ups.

Yes, Outpost goes quite in depth with its full ruleset, and has quite an extensive rules processing order list as well.

BTW, I've always missed the plain text ruleset that Outpost used to offer in threir older versions. They decided to encrypt them (from version 3 I think) because they were concerned competitiors were copying them.

 

Actually, it's the same scenario as newest versions. The rule for UDP DNS is this one:

There isn't an explicit block inbound UDP DNS, but using the policy of "Block Most", which is equivalent to Windows block inbound and outbound unless strictly allowed, inbound UDP DNS gets blocked. So, if the rule for UDP DNS is for both inbound and outbound, then the inbound UDP DNS shouldn't be getting blocked, no matter what policy is chosen.

That's why I say that there's only an outbound rule for UDP DNS, and no inbound. Otherwise, I don't know why would inbound be blocked, even in "Block Most" policy.

Some of those rules include the called core networking rules, specially for ICMPv6. They are way to permissive. Outpost allow the same as ICMPv4, maybe even one less permission for the inbound.

In Windows firewall thread, I've post two links for two articles about ICMPv6 and what they say must be allowed, should be allowed and dropped/blocked. But, I think those rules are also way too permissive. I still don't have a full understanding of ICMPv6, but I believe not all of that would be necessary, though.

 

Okay, still the same. Thanks!

IMO, they may be too permissive for what's only required, but I don't feel they're too permissive with regards to presenting security concerns, especially the ipv6 rules. Remember that as long as no program or service - especially exploitable ones - is listening on an exposed port, then there should be nothing to worry about. Example, is System process sending/receiving datagram (UDP) to/from router ip address going to expose it to exploits? Somehow I doubt it, though I'm not qualified to say with certainty. I would say a greater concern would be allowing, for example, one's browsers and messenger programs, or svchost process unrestricted TCP outbound access.

 

That made look into Outpost for Teredo rules. Unless I missed it, there are no rules for it. There could be one for Block and Report it.

Is anyone blocking Teredo though the firewall? Or have you just disabled Teredo?

Source: http://en.wikipedia.org/wiki/Teredo_tunneling#Security_considerations

A firewall rule to block outbound UDP traffic to port 3544 would suffice.

 

I don't use teredo rules anywhere.

 

Outpost has the following rules for svchost, among other ones:

I have mine to block. No issues here. But, I'm wondering if a global blocking rule would be better in this case?

Both services are attached to svchost.exe, I'm aware of that. I'm wondering if just like what happens with DNS Client, which is attached to svchost.exe as well, it's svchost.exe that actually performs these lookups for SSDP and UPnP as well in name of other apps? It makes sense, considering DNS Client way of working.

 

Don't bother, just disable the SSDP service and all these port 1900 irritations go away along with the rules.

After you disable service you can delete the rules for blocking them. No rule means no packets passed in or out.

 

Yes, totally, I agree. I'm just making all these questions as a way of exercising my brain.

That's one of the things I actually like about Windows 7 own firewall. I actually haven't tried the other way around, but, for example, remote access is disabled, so all the rules for it are also disabled in the firewall. (I might actually enable remote access and see if the rules become active, in a virtual machine.)

Actually, not so sure. DNS Client is disabled, and therefore, following that same principle, the firewall rule would also become disabled, I guess.

In a policy of block all except what's allowed, there's no need for extra blocking rules, unless the user is only trying to exercise his/her mind, which is always great, though. The only exception might be if there's an allowing rule, either incoming or outgoing, but you do not wish to play with the default rule, so one to block is created. In Windows firewall a block rule will precede an allow one.

 

The introduction of rules that add uneeded complexity are counterproductive IMHO. It doesn't help learning much.

I have NO allow incoming rules. The only packet handshakes I want are one's my setup initiates.

 

I just got a reply from Agnitum support, after sending them an e-mail asking to shed some lights on a few doubts I had regarding, among other stuff, UDP rules.

They mention that both incoming or outgoing traffic is either blocked or allowed, whether the rule allows or blocks the connection. It's valid for every protocol and if no direction is defined.

 

How is working for you having no incoming rules? I'm not saying whether or not is cripples things; just wanting to know.

For example, if you have Outpost set to Block Most and automatically create rules for well-known and digitally signed applications, if needed, Outpost will create incoming rules for those apps. For example, avast! antivirus process avastsvc.exe has an inbound rule for MY COMPUTER (loopback).

I'm testing some stuff in a virtual machine, and I've installed avast! there as well, for the sake of learning what rules are actually required and those that aren't.

So, do you have no incoming rules, and have Outpost set to Block Most and no automatic creation of rules, or Wizard mode, and then only allow incoming connections you wish so?

 

When a laptop, such as mine looses power, BIOS clock is wrong. AV thinks last update was in 1980 January or something similar. BIOS clock has to be set on bootup which is a big PITA. Which is why I do need to permit the service to run and limit svchost as I described in post 146 which rules apply to every firewall I've used so far learning from your and CrazyM and few other great threads here.

The battery on my Toshiba laptop is on the motherboard, and the ENTIRE MOTHERBOARD will need to be replaced just for the clock, something I have no intention of paying for. A ridiculous design of an otherwise six years old, fabulous XP computer. Heck, they saved 4 cents in designing it during all this cost cutting fashion.

 

I work fine with no incoming. You see the way this works when say your AVAST needs to update IT initiates the connection with the AVAST host. This is done via an allowed OUTBOUND connection from your computer to Avast.

THEN, incoming packets are allowed via your computer initiating it. So I do have incoming packets BUT only ones I initiated.

There should be NO Inbounds that I/you don't initiate. This is why we have firewalls in the first place.

On my Out Post FW Pro set up I have zero generated rules. I run under Block Most.

Right now I haven't the energy to go into loop-backs.

Someone else can do that.

 

What do you mean? Have them disabled, default one inbound and outbound enabled? Or just disabled IPv6 all the way?

 

I just don't have the built-in teredo rule enabled. The only one I can find is a Core UDP rule.

 

Yes, there's only one UDP rule... or actually, two (inbound and outbound) for UDP. So, you do have a rule in place. You just have disabled it.

By the way - and I hope it is over -, the only way I actually found to stop SSDP connections to port 1900 was to actually disable SSDP and UPnP (this one needs the first one, so better just disabled as well) services.

Disabled rules or specific rules to block such connections wouldn't do a damn thing about it Odd, because those connections shouldn't happen, because no rules allowing them are/were enabled for svchost.exe or any other process (I haven't tried blocking for every process).

I just disabled, as for the time being, not part of any network. But, if I was, Windows firewall should be blocking it due to the lack of allowing rules.

Outpost Firewall PRO blocks it just fine, if I set it that way. I wonder why Windows firewall fails at that.

 

I am not seeing that.
I do have the SSDP service enabled on win7 x64, but do not see any outbound from that service.

What is your NIC set to (private/public?)

If your NIC is set to public, then SSDP should be blocked by default.
What outbound are you seeing? Have you a log/sniffer capture to show the comms?

Currently, the only outbound I see from that win7 x64 setup is ARP and a DNS lookup (after boot) for teredo.ipv6.microsoft.com (The PC as fixed IP)

- Stem

 

Hello Stem, thank you for your interest.

First, I don't know if it makes any difference, but I connect to the Internet via an USB 3G modem. I don't know if this is the reason that triggers such connection.

It's set to public.

This is what I could find from an earlier connection, when SSDP was enabled, from Windows firewall log:

2010-10-31 19:53:30 ALLOW UDP 127.0.0.1 239.255.255.250 52467 1900 0 - - - - - - - SEND
2010-10-31 19:53:30 ALLOW UDP 127.0.0.1 239.255.255.250 52467 1900 0 - - - - - - - RECEIVE

I haven't tried to find out what makes it trigger, but according to Outpost Firewall PRO log (I don't have the virtual machine started right now.), which I have it to block pretty much every svchost rule, I see that the process that triggers communication to port 1900 is precisely svchost.exe.

I also noticed, from earlier, while SSDP was still enabled and set to manual (default setting), that SSDP service had been initiated.

I'll see if I can get more into in later.

But, as you said, these communications should be blocked. Also, if no rules are enabled to allow them, then they shouldn't happen. -Edit-: If rules are also in place to block such connections, they still get allowed. I created one inbound and one outbound to block communications from port 1900, but they still were allowed (I have tried it yesterday.)

2010-10-31 23:16:41 ALLOW UDP xxx.xxx.xxx.xxx 224.0.0.252 60891 5355 0 - - - - - - - SEND
2010-10-31 23:16:41 ALLOW UDP xxx.xxx.xxx.xxx 224.0.0.252 61772 5355 0 - - - - - - - SEND

Shouldn't these be also blocked, considering LLMNR (Link-Local Multicast Name Resolution) has no enabled rules in the firewall?