An adversary with physical access can easily take out your HDD and put it into his own computer in order to get around the BIOS password. Only glittering your laptop's screws makes this readily detectable. I do recommend setting a supervisor password in BIOS in order to prevent modification of settings, but in reality if somebody with skills gets their hands on your computer, it's a false sense of security. Secure boot is a wise thing to enable, it's an option in newer computers with UEFI. It won't work for Linux though in most cases (at least not without a bit of fiddling)
Want to store some text here? Go ahead, type something and store it. Then close your browser and open this page again. Is it still there? No text shows up after typing , closing browser and revisiting web site. Logged into HTTPS and not HTTP. Shows number of visits 2. Tested again by installing Secret Agent extension and now shows number of visits 1 No other extension were installed. lucb1e.com/rp/cookielesscookies/ RequestPolicy result: (green-protected) NoScript result: (green-protected) ip-check.info/?lang=en (cache E-Tags)
On mine, Request Policy shows no other connections. I got the same results with HTTP and HTTPS. Typed in different text for each. Clicked on store button. I then pressed CTRL+F5 for a forced reload. There was no text. In the other post I linked to, I had different results with 2 different filtersets. It was filters that permitted specific caching in the Sidki set that gave the mixed results.
lucb1e.com/rp/cookielesscookies/ What was your number of visits when you went there ? Close the browser and revisit again. Was it the same number?
Right now it says 2 visits. I'd made at least 5. I suspect that they're just counting visits from individual IPs for that number. If I connect direct, it says 2. Via Tor it says 1. I never closed the browser.
I have my BIOS also setup to boot from hard drive first. I do have everything else unchecked though. I just don't like having to enter all these passwords just to boot system and log into OS. What are the security risks and which if any to enable?
I would definitely use a setup password to prevent changes in boot order. That's the only time that password should be required. I believe that the system password would be the one that would be used to boot the system.
Thanks. I just want to make sure I don't lock myself out of my system. Not sure on Password Status (lock/unlock) I suppose one could remove and reinsert the CMOS battery that powers the BIOS memory if you somehow got locked out?
I started testing lucb1e.com/rp/cookielesscookies/ yesterday ... using: FF /Sandboxie / and changing Prefbar settings in between browser restarts. I didn't type anything in the box, but just looked at the # of visits, which were inconsistent. Here's one combo of settings I used 3 times which increased visits to 3 and nothing I did could get the the number back to 1 visit. I had JS box unchecked, Flash unchecked, Real UA. I have Cache set to 0 in FF options. When I went there today, the visit count on those same settings was just 1. This tracking method is despicable. On BIOS passwords, I've always utilized that feature from day dot. It may not be 100% secure but any measure one can take is better than nothing. I don't seem to have an option for different passwords for different aspects, just one.
Okay, your correct. Setup password is set. When I boot into BIOS the first thing required is the password. Don't know if I would need the system password. I take it that would show up prior to entering the BIOS screen.
I'm not sure, but I think that would appear before the OS begins to boot. I've never set one to see how it behaves. I'd assume (and could be wrong) that this password would prevent live CDs and USB devices from booting as well. No idea what's required to bypass this.
Yes, early in the boot process is what I was thinking. Password would be needed everytime one boots up whereas setup password is only needed when one boots into the BIOS to make changes if I'm understanding correctly. I do use live CDs and need access so maybe I won't concern myself with this for now unless find out otherwise.
KeyPer, heres what happens in my situation. I've never NOT booted without having to put my BIOS PW first. Thats the way I wanted it. Short of taking those steps mentioned, (jumper settings HDD removal etc) there's no way to circumvent it and its the very first thing that happens. For example, you can't access the likes of safe mode without going through BIOS PW. If I want to change BIOS settings (which I would need to do to change the boot order) I press Delete to go there, FROM the BIOS PW screen (white lettering black background) OR, if I press Delete before the main BIOS PW screen comes, either way I still am presented with a password box.
Trying to remove index.dat files so booted into live cd that is capable of deleting the .dat files and proceeded to replace those deleted files with folder of the same name as recommended. C:\Documents and Settings\Administrator\Local Settings\Temp\Cookies\ C:\Documents and Settings\Administrator\Local Settings\Temp\Temporary Internet Files\Content.IE5\ C:\Documents and Settings\Administrator\Local Settings\Temp\History\History.IE5\? If your running LUA then these 3 locations would also apply to that account as well. Booted up several times to see if Windows would then create index.dat files and looks okay so far. Have CCleaner app setup for locations of index.dat files. Continue to monitor locations to see if anything changes especially during any new install. C:\Documents and Settings\Administrator\Local Settings\Temporary Internet Files\Content.IE5\index.dat Only dat file that I know of having issue with. Content.IE5 folder or index.dat file is not present in Windows Explorer. Cannot create the 2 folders in Explorer (File > New > Folder not available) CCleaner shows dat file size at 16KB. Live CD shows both Content.IE5 and index.dat folders.
Kerio Personal Firewall (KPF) 2.1.5 allows local users to execute arbitrary code with SYSTEM privileges via the Load button in the Firewall Configuration Files option, which does not drop privileges before opening the file loading dialog box. (cve listed vulnerability)
If the user has set an administrative password, that option will be inaccessible. A classic HIPS with restricted parent-child permissions will also mitigate that issue. In this instance, anything launched via this interface will have PFWADMIN.exe as the parent process. PFWADMIN.exe should only be allowed to launch PERSFW.exe, nothing else. This is an example of how separate, freestanding firewalls and a classic HIPS can be configured to protect and augment each other. It's also an example of layered security and how the security of a total package can exceed that offered by the sum of its parts.
Just to add on to this on the linux side. You can sign everything yourself so it works with SecureBoot OR if you have a device that uses coreboot (Chromebooks do!) you use GPG to verify the kernel and other fancy security things. This is what I do with debian and my chromebook. Still a lot more work I realize. You can also set a harddrive "Lock" Password. Which is much more difficult to bypass and follows the driver where ever it goes. I agree on the BIOS password side of things though.
PERSFW.exe. Isn't that the service in Windows Kerio FW uses and set to automatically run (when set) at startup? I like to use that setting to load when configuring firewall rules as it can be used while system is virtualized. No classic HIPS installed and don't know if want to go back to that.
PERSFW.exe does run as a service on NT systems, as it should be. It should also be set as an allowed child process for PFWADMIN.exe so that it can also be started from the firewalls administrative interface if necessary. That's largely a question of what you're comfortable with. I've used Kerio and SSM together for so long that the rules and permissions are automatic for me. If you're comfortable with classic HIPS, they can protect the firewall from termination, suspension, and inter-process messaging. Even the free version of SSM can restart it if it is terminated by using the "keep process in memory" option. The firewall is part of the attack surface. A classic HIPS can make sure that it stays running and is not affected by code that enters via other internet applications and tries to disable it or interfere with its ability to function. At the same time, the firewall can protect the classic HIPS from any attempts to attack it from the internet by not allowing any access to it. Such an arrangement can work quite well as long as you're comfortable with working with such rules.
Okay did some testing. If you password protect Kerio Administration setting beforehand and then click on Firewall Configuration Files [Load] button then you'll lose the password security. (no password to enter) Also Kerio will load the .conf file you previously saved with any added/changed rules you've made. Kerio also informed me of a security application change & select yes or no to accept replacement of the app.
The password is part of the configuration file. Although I agree that the ability to run another executable from that interface shouldn't be there, I can't view this as a vulnerability. Once an administrative password is set, that interface is inaccessible to everyone except those who have the password, unless it's left open. IMO, it would be irresponsible for an administrator to not set a password to control access to the firewall. If the password requirement can be bypassed without using a separate OS to delete the configuration file, I'd be interested to see how it's done. If such a vulnerability does exist, it could be mitigated with a classic HIPS by making PERSFW.exe unavailable to everyone but the administrator.
Kerio Self-Protection: It is possible to delete or modify all files in the Kerio directory while Kerio is running (except the .exe), which after next reboot will make Kerio fall back on some default configuration and also loose the password. Note: It is possible to delete PFWADMIN.exe The firewall administration password should be set, however according to dslreporting forum website Kerio only prevents 2 of the 7 or 9? Win32 API ways of terminating an application. It looks like also the rules file is encrypted and by editing the registry you can decrypt the .conf file, but Kerio apparently warns you at every startup the file is not encrypted until you change or remove the edited reg key. Haven't tested this though. Looking at the permissions in the Kerio folder (files) the Admin and SYSTEM have full control and Users has no write permission. I might again look into HIPS or possibly behavior blocker.
I used .conf to text several times to make bulk changes using Notepad. One example I recall was changing A/V localhost proxy port from one antivirus to another. Useful also when you want to change DNS servers in some applications. Or as a handy list for setting up on another box. Bulk changing sure beats walking through every rule and changing something small manually. Just don't forget to change it all back and lock it up. And yes, I do use SSM to protect Kerio and Sunbelt which I use on another XP. That one will not let you touch the config file in any way. It has a checksum of sorts and also a bit of relational stuff, so might break if we mess with it.
All of the things you're describing require administrative access and most likely physical access to the PC. If that kind of access is available to an adversary, you've already lost the battle. Most of this wouldn't be possible from a non-administrative account. It couldn't be done remotely unless the PC was already infected with a remote access trojan that has at least administrative permissions.
