Both methods have their place. IP addresses don't always resolve to a name. Names can resolve to different IPs depending on where you're at. The 2 methods can complement each other quite nicely. Food for thought. If you're a Tor user, blocking by IP addresses/ranges can prevent any direct connections to a given site while still permitting you to access it via Tor. Combined with the AutoProxy extension, it opens up some interesting possibilities, like allowing direct connections to the site itself while routing trackers, adservers, etc through Tor. When someone tries to combine the data, they get conflicting results.
As promised here is screenshot of firewall wanting Inbound TCP connection. In order to stop all the popups I had to place block rule. (range 1024-5000) It may of not needed to be set to 5000 though. The other screenshot shows outbound TCP connection and remote address over port 80. Prior connection was to port 443 and remote address to my search engine, but not shown.
1. What was the remote ip and port which triggered the first dialog you posted above (#327) for some inbound attempt? 2. Those screenshots of the dialogs do not look like Kerio or Sunbelt fw would issue. Resembles Outpost but not exactly. Are you running two firewalls?
Im on XP Pro SP3. As I understand it, the Lifetime key would be for you only, so it looks like it counts me out .
Not at all. In addition to my beta tester key, the developer gave me another unlimited key that I can freely share. This way his work doesn't go to waste. SSM failed because it wasn't financially viable, not because it wasn't effective. It targeted a very small user base and represented a one-time sale.
Not sure as firewall popup gave limited info and the log details... there were so many entries. First popup was for TCP inbound on local port which could very with each connection unless you set a range rule. Then it would ask for DNS UDP out on port 53 . After that connection made to search engine TCP out on port 443 and finally the cert authority used by search engine provider on TCP port 80. The remote IP's were listed for remote address (search engine) and cert authority. Yes I'm running 2 firewalls, (hardware & software) but only test one software firewall at a time.
I didn't realize that you've been working with more than one software firewall. I don't recognize those screenshots. What firewall is that? The information I gave you regarding Kerio may or may not apply to that firewall. There's a lot of information those screenshots are not supplying including the IP address and the application the rule applies to. They appear to be screenshots of the rule editing interface, not the connection prompts. This is a screenshot of Kerio prompting about a loopback connection for Palemoon. Loopback connections are both inbound and outbound. For all practical purposes, loopback traffic is handled by a separate device in a PC. Unlike a physical network card, the loopback adapter exists in code only. Firewalls vary widely regarding how they handle this traffic. Some have separate rules for that traffic. Others don't filter it at all.
I am working currently with only one software firewall. I didn't post the screenshots of the popup connection shots which will tell you the app and file path, ports, remote address - IP addresses, but limited info on TCP inbound. Firewall logs are more detailed, but harder to figure out info. Loopback rules for Kerio I need to configure better as I have one block rule and not sure where to place it.
Without knowing what firewall that is, I can only give general suggestions. The popup alerts should give you all the information you need to make a decision. I'm not sure what you mean by "limited info on TCP inbound." Without inspecting the actual contents of the packets, the information should include the IP address it comes from, the local and remote port numbers, the protocol being used (TCP, UDP, ICMP) and whether the connection is inbound or outbound. As I mentioned earlier, loopback/localhost traffic is the exception here. When a browser makes a loopback connection, it is both connecting out and receiving an inbound connection. Every firewall seems to treat loopback traffic differently. Kerio treats it as outbound. With Kerio, the rules that govern loopback traffic are on the same interface as the rest of the rules, but the rules themselves apply to a separate network adapter and function separately from the rest of the rules. As a general rule, keep the rules for specific applications and system components together. If you use a filtering proxy like Proxomitron, Tor, SocksCap, and/or multiple browsers, or your setup uses multiple configurations or chains, the setup gets more complicated. With these setups, the browser, proxy, and other components are treated as a group. In post 65 of this thread, I posted a flow chart of the traffic through a multiple component package and a firewall ruleset for that package along with an explanation of how and why it works. Yours will be different of course but it should give you an idea of what rules are needed and how they should be ordered. Depending on your package and needs, DNS rules can be very simple or quite involved. If you're using proxies (local or remote), Tor, VPNs, etc, the Windows DNS can be a big complication and a major leak.
Packet Content Details: (some of the info, but not all for the network traffic and firewall activity) Path: Shows path of browser Direction: Inbound/Outbound IP: Source Address -> Destination address -> Protocol (TCP/UDP) TCP: Source port -> Destination Port Not sure of creating rule for loopback (127.0.0.1) although there are advanced profile settings for advanced rules, but I didn't venture into creating advanced rules with the firewall. Couple of popups when browser runs and you then create rules. NOTE: check post #334 for Kerio loopback rule.
If you really want to block Palemoon loopback, in Kerio, enter application=PaleMoon(navigate for full path), local address=any, local port-any, remote address=127.0.0.1, remote port=any, direction=both, protocol=TCP, Block or Deny, and enable the rule. Loopback: I don't have SeaMonkey where Kerio is, so this is from Kerio's close relative, Sunbelt on another XP. Kerio doesn't have two lines/process. Chats less with itself? Interesting. I post this in case more loopback clarification needed, with included log. Both firewalls only alert and only log outbound. I don't mean to step on anybody's toes or confuse the matter. This is an interesting thread all along.
Both PERSFW.exe and PFWADMIN.exe showing remote address of 127.0.0.1 (localhost) and one connected in and other connected out on TCP with different ports. Loopback rule is similar for blocking and I forgot about TCPView as I have that also.
What servers does Pale Moon contact? Pale Moon, by default, contacts a few different servers in addition to what you are surfing to. Security-aware people may have noticed, so here is a roundup of what Pale Moon occasionally contacts for its various purposes: • palemoon.org to check for updates to the browser • blocklist.palemoon.org to check for updates to its extension blocklist • addons.palemoon.org and versioncheck.addons.mozilla.org to check for updates to extensions • pmsync.palemoon.net if you use Pale Moon Sync with the default server (optional) https://forum.palemoon.org/viewtopic.php?f=3&t=631 NOTE: Testing browser & firewall when connecting so placed rule(s) that trigger alert.
Trying to find and shut down all of those "features" in current browsers is a pain. Just about when you find and disable them all, the browser gets updated and you get to do it all over again. I have to wonder how many of them send unique identifiers or other trackable information without the user knowing it. Auto-updating is a double edged sword. On one hand, you get security fixes and an occasional useful feature or other improvement. On the other, you get more ways to call home to an ever growing list of places plus a lot of useless features and undesired changes, like built in ads. It gets worse with extensions. Some of what shows up in extension updates is adware/spyware by any known definition. I'm glad that I don't have to fight these battles. I'll update when and if I choose, not when I'm told to.
Yes, it's a pain , but IMO more painful in Firefox than Pale Moon. Kerio pops up on quite regular basis when I set those rules, but like you said with updates you get security fixes with possible unwanted or useless features and/or changes that may "call home". Quick question on Kerio. Does the Network/Mask address setting work at all? You mentioned before not using it.
At best, it's inconsistently applied. I regard it as broken. In the old Kerio learning thread, last few pages, network/mask rules that were part of the Blitzenzeus ruleset were blocking traffic that they should not have affected. Network/mask was being improperly applied. I never finished exploring this issue, but when its use caused a rule to block more traffic that it was supposed to, a permit rule using it could end up permitting more than it's intended to. Network/mask rules are normally used on large local networks. They're not really useful for internet rules. There's no real reason to use them unless your network has dozens or hundreds of internet devices, in which case you'd probably want a dedicated device anyway. You may find the Kerio learning thread useful to this thread as well. It went into quite a bit of detail regarding services on XP. There's a lot of overlap between it and this thread. Most of what's there is still completely valid.
Okay thanks. About the Blitzenzues rulesets. There were 2 versions (standard & advanced) IIRC. Are any of those rules listed still good to use in Kerio and which ones?
His rulesets contain some good ideas and patterns one can use. The blocking rules for zero octet, IGMP, Protocol50 are part of my ruleset. Most of what's there will not apply to most users. It is not a complete rulesets and shouldn't be treated as such. They have the same unavoidable problems as the default ruleset. In order to be truly effective, they need to be matched to your needs and equipment. IMO, you're better off starting with no rules and writing your own. This way, each is tailored to your system.
Makes sense. I basically started from scratch , but left some of the default settings while disabling Windows entries. Zero octet? https://en.wikipedia.org/wiki/Octet_(computing)
I should have been clearer. The zero octet blocking rule specifically blocks all traffic directed to 0.0.0.0.
Is that zero octet rule shown in BZ ruleset? // I deleted the zip file. Have one Protocol 50 IPv6 rule: Protocol: Other [50] Direction: Incoming Remote endpoint: Any address Action: Deny & Display alert Have one IGMP Rule: Protocol: Other [2] Direction: Both directions Remote endpoint: Any address Action: Deny That look correct?
There is a screenshot of the BZ rulesets in the Kerio thread. That is the rule I was referring to. Regarding the 2 rules you posted, they look fine. It's up to you if you want to be alerted to IPv6 in addition to having it blocked. I save that option for rules that would point to being compromised or a hacking attempt, like trying to use DNS servers I didn't specify, UPnP traffic appearing after I've disabled it, or the browser ignoring the proxy settings and attempting to establish a direct connection. How you use the alert and logging features is entirely up to you.
Read most of the Kerio thread, but missed the screenshot . Found it now. Any particular place to put the octet rule ? (order)
