No, Pale Moon is working. Kerio pops up block filter rule (not shown in screenshot) denying access to Google. Already tried disabling loopback rule.
Is there a blocking rule in your ruleset that's not shown in the image you posted? None of the rules in that image should block Google. Did you implement something similar to the junk block rule that I use? Blocking entries in the hosts file? Peerblock/Guardian or something similar?
Oops, that's an older image. I purposely am blocking Google IPs that I had when I was using Peerblock. Yes it's probably similar to your junk block rule with some other entries. It works as it should, just having problems with HMPA.
OK. That makes more sense. By any chance, using this IP list? Is SandBoxie failing to terminate both HMPA and the browser? I question if sandboxie has the ability to terminate a service. Is it possible that if Sandboxie fails to terminate the service, it doesn't even try to terminate the next application, in this case the browser?
Yes that would be the Google entries. Sandboxie can terminate the browser only if I choose " terminate all programs" when running HMPA. Normally I don't have to do that. The browser and Sandboxie function as should , but I'm still trying to isolate the issue between Kerio and HMPA. Remember this happens without Sandboxie . I tried it both ways in testing. (sandboxed/unsandboxed) HitmanPro is integrated now into HMPA. It's a malware scanner that can also be downloaded as a separate program. If HMPA comes across exploit of some type then it pops up a message and you can use Hitman Pro to scan and hopefully remove infection. HMPA does offer protection of its own though as well. Currently HMPA is still in RC with final version coming out when devs are ready to release it. There is more info on HMP and HMPA on Wilders forum about what each program does.
What is the purpose in Kerio firewall to have passwords for both administation and statistics and log views? Would you set same password for both or use different passwords? I'm use to setting one password for an app.
@Compu KTed I didn't (until now) have the "status window" password protected. I guess for situations where there's multiple users it would keep prying eyes out of that area. When I was looking for firewalls, at the time Im pretty sure Kerio was the only free one that offered password protection. I like that. Notwithstanding what a pesky keylogger can do, password protected firewalls make a lot of sense.
Having used many different firewalls over the years IIRC Online Armor, Comodo and PC Tools offered password protection. There may be more , but Kerio may have been one of the first, but not sure.
I'm pretty sure that they use the same password. A password on the status screen would be useful in situations where the administrator doesn't want users to be able to view the traffic. For the average user, I don't see much use for status screen passwords. IMO, requiring a password for access to the ruleset and the ability to shut down the firewall is an asset. It's also required for making any permanent rule.
Just before when I enabled the status window option and set a password, it was a different one, so it looks like you can have 2. Yes it is an asset. Easy to instantiate for the less knowledgeable with great returns for little effort. IF anyone was to close your FW down, imagine the gaping holes it would leave!
The password for each different section (admin & status) can use 2 different passwords. Not that I would do this, but it's possible. Administration password I agree is an asset.
So it does. I missed that. Not a feature that I've used. I also noticed Kerio can allow remote administration and remote access to the status and log screens. For that I can definitely see a password as necessary.
Right, but "enable remote administration" Um, not for me thanks. Just adding, I also noticed the need for a status PW can be disabled without having to re-enter that PW if it's different.
Even when you disabled cookies entirely, have Javascript turned off and use a VPN service, this technique will still be able to track you. lucb1e.com/rp/cookielesscookies/ Has to do with cache tracking .
Prevent boot-up from any device other than your hard drive. Set strong passwords in BIOS for both starting up and modifying the BIOS settings. Recommend or not recommmend one or both?
This is very dependent on your needs. I set mine to boot from the hard drive first. A bootable CD or USB device doesn't change that. Because it's also a Tor exit, I also set the BIOS to automatically boot the system when power is restored. Because of this I don't use a BIOS password for starting up. I did set a password to restrict access to its settings. Don't put too much faith in a BIOS password. On some motherboards, removing the battery for a period of time will cause the BIOS to revert to the default settings and lose the password. On other boards there's a jumper that can be used to bypass BIOS passwords. That info is usually in the manual for your motheboard. Sometimes it's in the PC owners manual. If bypassing a BIOS password via physical access is part of your threat model, you can take steps to make it more difficult, like soldering the battery and jumper in place, adding a 2nd hidden battery under the board, and bridging the connection of the BIOS password jumper in another location. None of these are sure things. Given time, an adversary will find and defeat these measures. That said, they do increase the amount of time it would take, which increases the chances of their getting caught in the act.
Read the thread. Something has changed when going to that site. Thought RequestPolicy handled etags. Going to do some more testing and be back to report results.
Request Policy handles connections. eTags are content in the headers. I don't know if NoScript can handle eTags or not. Proxomitron can remove eTags with this filter.
