Windows Vista/Windows 7 + Sandboxie + Integrity Levels

wat0114 wrote:In reality there are many ways to bank on-line securely; m00nbl00d's method will probably work fine, but there are numerous other ways as well.

And, that's the beauty of it.

Heck, I could even couple the test I suggested/that I've done with Prevx SafeOnline/Trusteer Rapport/Etc. In this case I coupled it with Sandboxie.

There's so much users could deploy, for a general and relatively safer experience, if they can't use live cds for whatever reason, of if some word other than Windows scares them.

Anyway, what I mentioned was just a test that I've done in my relative's system. I'm still investigating more stuff, but I just thought of sharing the integrity levels approach. It works against keyloggers damn well. And, unless I'm mistaken, but I will investigate, it would also work against malicious code in process's memory. Say we apply a low integrity level to a media player. Anything initiated by it will inherit its low integrity level as well, and I don't think malicious code would be any different. But, I'll test it out with some PoC whenever I can.

I think wat0114 sums it up well, and I will reference my previous comment too:

But yes, at the end of the day, if your relative (or anyone out there) is happy with your setup/approach, then that's great!

As I've said already, I think this approach is rather excellent, and in fact, the two best parts of it (that make it rather "bullet-proof") are the following:
1. Firewall restrictions
2. Integrity levels

I don't think Sandboxie really plays a significant role to secure online banking/transactions with your relative's setup.

Unfortunately though (and as you've alluded to), I believe at the end of the day, the user is the most important safety factor - user carelessness (and lack of awareness) must surely be (one of) the most important factors contributing to the likelihood of malware infection and malicious logging. This is why I'm so "meticulous" (as Scoobs put it!) with my setup/approach - in some ways, it's forcing me to be careful. It's also about reaching that happy medium of security and convenience.

By the way, a little off topic but still related to safe online banking etc (I may move posts as required, but I don't really care unless other members care), what do you know about (Firefox) NoScript and protection against DNS hijacking and fraudulent SSL certificates?

ssj100 wrote:I think wat0114 sums it up well, and I will reference my previous comment too:

But yes, at the end of the day, if your relative (or anyone out there) is happy with your setup/approach, then that's great!

As I've said already, I think this approach is rather excellent, and in fact, the two best parts of it (that make it rather "bullet-proof") are the following:
1. Firewall restrictions
2. Integrity levels

I don't think Sandboxie really plays a significant role to secure online banking/transactions with your relative's setup.

Yes, you're right. Sandboxie doesn't play a significant role, except for two "simple" tasks: contain browser files in the sandbox and then securely erase with Eraser.

Unfortunately though (and as you've alluded to), I believe at the end of the day, the user is the most important safety factor - user carelessness (and lack of awareness) must surely be (one of) the most important factors contributing to the likelihood of malware infection and malicious logging. This is why I'm so "meticulous" (as Scoobs put it!) with my setup/approach - in some ways, it's forcing me to be careful. It's also about reaching that happy medium of security and convenience.

Yes, (un)fortunately, the user does play a role. If the user isn't careful, at the end of the day, it won't really matter if he/she even uses a Linux live cd. What happens if the user ends up using the same browser to browse the web, while access the bank account?

By the way, a little off topic but still related to safe online banking etc (I may move posts as required, but I don't really care unless other members care), what do you know about (Firefox) NoScript and protection against DNS hijacking and fraudulent SSL certificates?

I'm not a Firefox user, and therefore not a NoScript user, but I took a look at the website, and judging by the features won't do anything against fraudulent SSL certificates.

It does help against XSS attacks, which is helpful. I thought Firefox protected their users against it?

Anyway, NoScript won't do nothing against fradulent SSL certificates. Something like Prevx SafeOnline or Trusteer Rapport would be useful, because they will verify the server's IP(s). So, if the IP doesn't match with the real IP, then for sure they should alert the user.

m00nbl00d wrote:
Yes, (un)fortunately, the user does play a role. If the user isn't careful, at the end of the day, it won't really matter if he/she even uses a Linux live cd. What happens if the user ends up using the same browser to browse the web, while access the bank account?

Odds are pretty good nothing at all will happen. Browsing the web while banking on-line, especially in a live Linux environment, doesn't automatically guarantee infection. A somewhat careless user in the hands of a security-enhanced machine banking on-line probably stands a decent chance of coming out of it unscathed.

m00nbl00d wrote:I'm not a Firefox user, and therefore not a NoScript user, but I took a look at the website, and judging by the features won't do anything against fraudulent SSL certificates.

It does help against XSS attacks, which is helpful. I thought Firefox protected their users against it?

Anyway, NoScript won't do nothing against fradulent SSL certificates. Something like Prevx SafeOnline or Trusteer Rapport would be useful, because they will verify the server's IP(s). So, if the IP doesn't match with the real IP, then for sure they should alert the user.

I'm having a very similar exchange on the Sandboxie forums, but never mind haha.

NoScript can enforce specific sites (eg. banking sites) to only load if HTTPS is available. Therefore, the only issue here would be with an "attack" which uses fraudulent SSL certificates with DNS hijacking? But since the issue here can be addressed by using IP address verification, couldn't this be achieved with relevant firewall restrictions (much like what you've been discussing) or manual checking/verification of the IP address when one visits their eg. bank site? I think I'd rather do this than rely on yet another "third-party" vendor (with administrative rights) with this kind of sensitive digital information.

ssj100 wrote:
I'm having a very similar exchange on the Sandboxie forums, but never mind haha.

I'll head over there, maybe tomorrow and give a read to that discussion. Maybe I'll learn something else.

NoScript can enforce specific sites (eg. banking sites) to only load if HTTPS is available. Therefore, the only issue here would be with an "attack" which uses fraudulent SSL certificates with DNS hijacking?

This is taken from NoScript website:

Anti-XSS protection

Cross-Site Scripting (XSS) vulnerabilities are usually programming errors made by web developers, which allow an attacker to inject his own malicious code from a certain site into a different site. They can be used, for instance, to steal your authentication credentials and, more in general, to impersonate you on the victim site (e.g. your online banking or your web mail).

If one restricts the browser to connect only to the bank IP, which is unique, then such type of attack would never happen. But, for the general crowd, who don't even whitelist JavaScript, etc., I suppose NoScript would be useful.

The question is: To what point would people want to trust NoScript (the author)? Years have, probably, shown him as a credible person... still... But, I suppose the same could be said about security software. Or, are we relatively safer with known and estabilished security companies to help protect our credentials/money? Tough question, perhaps.

Anyway, NoScript would also be useful for that. By the way, does Firefox protect against XSS attacks? Is it really needed to use NoScript for that? IE and Chrome do it, by the way. So, I'd use one of these to access the bank account.

But since the issue here can be addressed by using IP address verification, couldn't this be achieved with relevant firewall restrictions (much like what you've been discussing) or manual checking/verification of the IP address when one visits their eg. bank site? I think I'd rather do this than rely on yet another "third-party" vendor (with administrative rights) with this kind of sensitive digital information.

Yes, firewall restriction would be enough. The only thing a stolen SSL certificate does it make people believe they're using the real service. It would make the fake service look the legit one. Well.. it has been certified... right?

Nonetheless... a fake page. Not in the same IP. It can't... unless the attacker hacks the bank's servers...

Page is fake... IP is not the same... But, for most people the SSL would make it look like the real deal. The danger would rely more in other type of services, with shared IPs and IPs that may not always be the same. In my opinion, of course. Unless I'm missing some other relevant information... I'm only human, after all. lol

Cross-Site Scripting and HTTPS enforcement are 2 different things (among many others) that NoScript offers.

HTTPS enforcement (from NoScript web-site):

HTTPS stands for "Hypertext Transfer Protocol over Secure Socket Layer", and you can figure it as HTTP (the protocol you usually retrieve web pages with) over a secure encrypted connection. It is meant to protect you from eavesdroppers and man-in-the-middle attacks. An important feature of HTTPS is that if a web site has a valid digital certificate for its identity, as verified automatically by your browser, you can be reasonably sure it is the one it says to be. You can recognize HTTPS web sites by looking at their addresses, always beginning with "https://". Firefox hilights sites having a valid certificate turning part of the location bar to blue or green. Since NoScript security is largely based on domain names, a malicious party capable of spoofing a trusted site might work-around your whitelist. This kind of spoofing may happen through a DNS Hijacking attack or because you're using an untrusted proxy server, like many anonymizers including Tor. The former risk can be mitigated by configuring a static secure DNS, e.g. OpenDNS, and forcing its usage even if you're roaming with your laptop. Untrusted proxies or connectivity providers are harder to tame, because a man-in-the-middle could inject arbitrary content in any non-secure (non-HTTPS) page. In order to mitigate these issues, NoScript can be configured to honor your whitelist only if the current page is served through HTTPS, and therefore cannot be spoofed. Additionally, NoScript can help you forcing your most sensitive sites to always use HTTPS, and mitigating cookie hijacking.

Q: How can I tell NoScript to allow only the sites of my whitelist which are served through HTTPS?
A: Open NoScript Options|Advanced|HTTPS|Behavior, click under Forbid active web content unless it comes from a secure (HTTPS) connection and choose one among:

Never - every site matching your whitelist gets allowed to run active content.
When using a proxy (recommended with Tor) - only whitelisted sites which are being served through HTTPS are allowed when coming through a proxy. This way, even if an evil node in your proxy chain manages to spoof a site in your whitelist, it won't be allowed to run active content anyway.
Always - no page loaded by a plain HTTP or FTP connection is allowed.

Q: Can NoScript force some sites to always use HTTPS?
A: Yes, just open NoScript Options|Advanced|HTTPS|Behavior, entering the sites you want to force in the topmost box, and those you want to always leave alone in the bottom one.
You can use space-separated simple strings, which will be matched as "starts with...", glob patterns like *.noscript.net and full-fledged regular expressions. If, for instance, you want HTTPS to be forced on every Google application excluding Search and iGoogle, you can put

*.google.com

in the "Force" box and

www.google.com/search www.google.com/ig

in the "Never" box (the latter can be of course rewritten as a

^https?://www\.google\.com/(?:search|ig)\b.*

regular expression).
Notice that NoScript provides also a mechanism for web site to declare they want SSL forced on their connections.

So I suppose a "banking browser" would have the "Always" option selected (meaning no web content loaded by plain HTTP or FTP connections is allowed) and also have the specific banking domain to only load HTTPS content.

m00nbl00d wrote:The question is: To what point would people want to trust NoScript (the author)? Years have, probably, shown him as a credible person... still... But, I suppose the same could be said about security software. Or, are we relatively safer with known and estabilished security companies to help protect our credentials/money? Tough question, perhaps.

Very tough question. I guess it's all about whether the software has proven itself over the years. For example, Sandboxie is only run by one man, and yet I "trust" Sandboxie to protect me more than any other apparently "established security company".

m00nbl00d wrote:By the way, does Firefox protect against XSS attacks? Is it really needed to use NoScript for that? IE and Chrome do it, by the way. So, I'd use one of these to access the bank account.

I don't know. I'd bet it protects against some XSS attacks, but not all. I would also bet that is also true for IE and Chrome. Unfortunately I don't have much knowledge in XSS attacks to comment further.

By the way, feel free to continue discussion (as you deem relevant) here:
https://ssj100.forumotion.com/t428-methods-for-improving-security-when-performing-online-transactions#3587

ssj100 wrote:
Cross-Site Scripting and HTTPS enforcement are 2 different things (among many others) that NoScript offers.

Yes, I know. I ended up mixing replies.

Part of my first reply If one restricts the browser to connect only to the bank IP, which is unique, then such type of attack would never happen. was meant has an answer for:

ssj100 wrote:
NoScript can enforce specific sites (eg. banking sites) to only load if HTTPS is available. Therefore, the only issue here would be with an "attack" which uses fraudulent SSL certificates with DNS hijacking? But since the issue here can be addressed by using IP address verification, couldn't this be achieved with relevant firewall restrictions (much like what you've been discussing) or manual checking/verification of the IP address when one visits their eg. bank site?

But, then I mentioned the NoScript feature Anti-XSS, which is also a useful feature, in various credential scenarios.

Sorry for the confusion.

m00nbl00d, when you say you use a firewall to restrict access to only the bank IP address, how exactly do you achieve this? You'd have to allow a range of IP addresses right (that's quite a few I think)? Also, wouldn't you also have to allow the relevant IP address range that provide your browser with information on the SSL certificate?

Or are you not worried about the SSL certificate, since you're confident with your IP address restrictions?

Would be nice if you could share what your "banking firewall setup" looked like, or at least give a guide.

It depends on the bank's ip range, but let's say they range from, for example, 192.168.64.20 - 192.168.64.50. I know there are some 3rd party firewalls that will allow an ip range to be entered, as well as Vista/Win7's fw with advanced security. There's also the possibility of a subnet mask or alternatively ip with a CIDR block such as, for example: 192.168.64.1/26, which will allow a range from 192.168.64.1 - 192.168.64.62.

Indeed, but it would be hard to know exactly what the IP range is - I suppose you could contact the bank and ask? Also, what about the IP addresses associated with the SSL certificate? I think m00nbl00d would have these blocked in his "banking browser" (in case these IP addresses get hijacked to serve out malware?), which would result in a "semi-faulty" online banking experience especially when logging in - the SSL associated content would keep trying to load and eventually give up - I've noticed this myself when I was playing with IPsec. In fact, blocking the SSL associated IP addresses resulted in slow loading of my banking web-site. But there's probably a way to disable SSL certificate use in the browser, which could mean the browser doesn't even bother contacting the SSL associated IP addresses.

Anyway, IPsec in Windows XP (I understand it's integrated into the firewalls of Vista and 7) is an interesting and rather nifty tool. Unfortunately, I don't think there's a way to configure it to block IP ranges.

Currently, for my own purposes, I'm more convinced with using a "clean slate" Firefox browser with NoScript (including HTTPS enforcement), and ShowIP (to check that the banking web-site's IP I'm on matches with the correct one).

ssj100 wrote:Indeed, but it would be hard to know exactly what the IP range is - I suppose you could contact the bank and ask? Also, what about the IP addresses associated with the SSL certificate? I think m00nbl00d would have these blocked in his "banking browser" (in case these IP addresses get hijacked to serve out malware?), which would result in a "semi-faulty" online banking experience especially when logging in - the SSL associated content would keep trying to load and eventually give up - I've noticed this myself when I was playing with IPsec. In fact, blocking the SSL associated IP addresses resulted in slow loading of my banking web-site. But there's probably a way to disable SSL certificate use in the browser, which could mean the browser doesn't even bother contacting the SSL associated IP addresses.

If it were me, I'd clear my Security logs, then embark on a normal online banking procedure, then pore over the logs when finished and record all the ip addresses and remote ports (probably 443 mostly would show). From the recorded ip addresses, one should be able to notice a range of some sort, then build the ip restrictions in the fw rule accordingly.

As for the SSL certificate, I'm not sure about that. m00nbl00d can hopefully shed some light on that.

Currently, for my own purposes, I'm more convinced with using a "clean slate" Firefox browser with NoScript (including HTTPS enforcement), and ShowIP (to check that the banking web-site's IP I'm on matches with the correct one).

Imo, you can't go wrong with this approach. It's at least rock solid

ssj100 wrote:m00nbl00d, when you say you use a firewall to restrict access to only the bank IP address, how exactly do you achieve this? You'd have to allow a range of IP addresses right (that's quite a few I think)? Also, wouldn't you also have to allow the relevant IP address range that provide your browser with information on the SSL certificate?

You have to create a rule for the web browser (the main process: chrome.exe, iexplore.exe, etc) used for home banking. Then, if the firewall allows you, you should add the bank IP(s) in the remote server option, or what ever other name it's given. In Windows firewall, I add it to Remote IP address box.

I just allow communications to happen to the bank IPs, and nothing else. I don't care about the SSL. Unless the bank servers get hacked, then if I'm restricting communications to the bank IPs, I know I'm connecting to the bank.

Or, does anyone see any other danger I'm neglecting? Even in man-in-the-middle attacks, information would go to a stray server and only afterwards to the bank, manipulated by the attacker. But, in this case, the firewall wouldn't allow the communication to happen, to anywhere, because I'd only be connecting to the attacker's server and not the bank's server. But, this would be that something between me and bank got in the middle... The ISP? Symantec (I'm using Norton DNS)?

Would there be any other possible danger that I'm missing? If you're aware of anything, please let me know, so that I can take measures against it.

Or are you not worried about the SSL certificate, since you're confident with your IP address restrictions?

Unless someone can give me information that I'm posing my self to risk, due to that, I don't see the problem, as long as you're sure the IP(s) in the firewall belong to the bank.

Would be nice if you could share what your "banking firewall setup" looked like, or at least give a guide.

Well, first of all:

1) Different browsers/different installs of the same browser;
2) A separate standard user account for home banking;
3) Restrict communications of the browser's process (firefox.exe, chrome.exe, iexplore.exe, whatever.exe) to the bank IPs only;

You'd have to add the IP(s) to the box related to Remote IP addresses. I don't know how other firewalls work or how they're presented to the user.

ssj100 wrote:
Indeed, but it would be hard to know exactly what the IP range is - I suppose you could contact the bank and ask? Also, what about the IP addresses associated with the SSL certificate? I think m00nbl00d would have these blocked in his "banking browser" (in case these IP addresses get hijacked to serve out malware?), which would result in a "semi-faulty" online banking experience especially when logging in - the SSL associated content would keep trying to load and eventually give up - I've noticed this myself when I was playing with IPsec. In fact, blocking the SSL associated IP addresses resulted in slow loading of my banking web-site. But there's probably a way to disable SSL certificate use in the browser, which could mean the browser doesn't even bother contacting the SSL associated IP addresses.

I don't think you'd have to worry about IP range. This is what I'd do: 1) Verify to what IP the main bank's domain translates to, and add it to the firewall. 2) Open the bank's website, with the firewall already restricting communications. 3) Login to the account, which probably is done in a bank's sub-domain. Check your firewall logs and see which IP addresses are being blocked, and then translate the bank's sub-domain (if the case) to its IP, and match the IP with one of those in the firewall log... 4) Add permissions to the firewall for that IP.

Should you fear that the IPs could not be the right ones, then I'd contact with the bank support. They MUST have the technical knowledge to tell you that, otherwise they should be looking for a new job, because if I were the bank owner I'd fire them.

I just checked the firewall rules, created months ago, and the current bank's IP address, and they still match. Bank IPs don't change that often. It has been my experience, anyway. But, I don't think they do.

There's been a long time since I lasted checked it, but later on I can check if there are any speed issues by having it restricted this way, due to SSL. But, I don't think there was any.

Anyway, there shouldn't be a reason to add IP ranges. I wouldn't do that. When and if required, Id add the new IP(s), individually. I'd never add ranges, as it would be wreckless IMHO.

By the way, you could also map you bank's domain/domains to their respective IP(s) in the hosts file. This way, you know you'd always get there. DNS wouldn't come into play, because the hosts file comes first, only then the system asks for DNS.

It's another measure one could make use of.

-edit-

Regarding the SSL, there would be SafeOnline or Rapport. They would give the IP as well. If they match the one in the firewall and hosts file, or the IP you wrote down in a paper, let's say, then all is good?

I'm not sure what bank web-site you use, but for mine, blocking the SSL certificate associated IPs causes slow (inital) loading of the site - this is an extra 15 or 20 seconds, so it's not huge. Also, I no longer get a "green" valid SSL certificate in my Firefox browser (not that it really matters - it just feels a little uneasy haha).

With regards to IP ranges, whenever I connect to my bank web-site, it seems different IPs are used to communicate with it each time (you may have to close the browser and wait a few minutes to test this properly each time) - they are similar, but may differ by one or two numbers - there's no way to even access the site if one relevant IP is blocked.

By the way, there's no need for a third party firewall or third party software (on Windows XP) if you're only wanting to block individual IPs - IPsec works great.

Hi m00nbl00d,

do you also retsrict the allowed bank ip addresses to the correct remote port(s)? How about protocol? As for blocking ip addresses, this is not necessary with most fiewalls, at least not Windows Vista/7. Only the allowed ip addresses will connect and everything alse will be default-denied anyway.

Yes, actually I meant default-denying everything except certain IPs - you can do this with IPsec even on Windows XP (it's built in). I was quite surprised to see this and that there has been very few mention of it on other more established security forums.

With IPsec, you can also configure individual protocols and ports for respective allowed IPs. So if you know the IPs that need to be allowed, you can just restrict your entire system to these while you bank etc.

ssj100 wrote:I'm not sure what bank web-site you use, but for mine, blocking the SSL certificate associated IPs causes slow (inital) loading of the site - this is an extra 15 or 20 seconds, so it's not huge. Also, I no longer get a "green" valid SSL certificate in my Firefox browser (not that it really matters - it just feels a little uneasy haha).

Well, I don't see much of a difference. Nothing perceptible, anyway. It probably has to do with the fact that some time ago, before restricting stuff, Internet Explorer was giving issues with the certificate, not allowing access, when I could with Chromium (back then I didn't use Chromium for home banking). So, I installed the certificate back then.

Yes, indeed, you'll no longer see the green padlock. If you really think you need it, for the extra comfort ;D, you can always get the certificate and install it in your user account.

But, the green padlock by itself means nothing really, and many people from countries like Iran would tell you just that. But, if it makes you feel comfortable you can install it, by using a non-restricted browser to access the bank website and download the certificate.

As long as the IP (what truly matters) is the real one, everything's OK, and the traffic is still encrypted by SSL. The browser simply can't check if the certificate as been revoked or not. But, this is something you can easily check using another browser, if you really must.

With regards to IP ranges, whenever I connect to my bank web-site, it seems different IPs are used to communicate with it each time (you may have to close the browser and wait a few minutes to test this properly each time) - they are similar, but may differ by one or two numbers - there's no way to even access the site if one relevant IP is blocked.

I'm not saying it's just one IP they have, but mine never changes that often, and they're always IP there have been used before. I don't access much my bank account using Internet, so it's possible that they change more often. You'll have to find the right balance between restriction and IP ranges.

As an example, a relative of mine has the firewall restricting to the same IPs (3 IPs), for a very long time, and never told me something broke. So, I suppose it depend on the bank, it seems. I got 2 IPs only. (Edit: I just monitored traffic, and the IPs seem to change between these two quite often.) You need to figure out what the best approach is for you, in your case. You need to test the right balance (it always comes to that, I guess lol)

wat0114 wrote:Hi m00nbl00d,

do you also retsrict the allowed bank ip addresses to the correct remote port(s)? How about protocol? As for blocking ip addresses, this is not necessary with most fiewalls, at least not Windows Vista/7. Only the allowed ip addresses will connect and everything alse will be default-denied anyway.

Yes, I restrict to port 443. Since my last "chat" with the bank, they changed things and it's fully secured now (SSL everywhere). In the past, it had to be both 80, 443. Now, it's only 443.

Protocol is restricted to TCP. There's also a rule for DNS, as I got DNS Client disabled.

I'm not blocking IP addresses. Well, not in a direct way. I'm allowing access only the bank's IP(s), which will then block access to any other IP.

Actually you're right about the bank IP address - it's the (relatively less secure) SSL certificate IPs that change quite a bit, and they also communicate via Port 80. The actual bank IP address doesn't appear to change much at all.

So it seems even Windows XP users can make this IP restriction configuration without the use of any third party software.

ssj100 wrote:Actually you're right about the bank IP address - it's the (relatively less secure) SSL certificate IPs that change quite a bit, and they also communicate via Port 80. The actual bank IP address doesn't appear to change much at all.

I guess that's a good thing. It leaves room to restrict without having to be constantly changing IPs.

So it seems even Windows XP users can make this IP restriction configuration without the use of any third party software.

Yes, I think I've seen it mentioned before as well. I never really looked into IPSec... might be a good idea to start looking at it to learn about it, though.

P.S: By the way, I previously mentioned that if we install the certificate to our user account that we'll no longer see the red padlock, and will a green padlock. I was wrong. We'll see a yellow padlock (in Chromium, at least). Somehow, I remembered that I'd seen a green padlock; maybe confused with something else or it was in Internet Explorer that I've seen it.

But, if we install the certificate we'll no longer see the browser warning that the certificate is untrusted.

One more thing. This is just for those running Vista or 7. Maybe wat0114 is up for a little test. lol

I've done some experimenting with Prevx SafeOnline and it seems to be unable to verify the domain (it doesn't protect it) nor the IP address, if I apply an explicit integrity level to Chromium.

I've tried with low integrity level and medium integrity level. I didn't check with high integrity level, but I suppose the result would be the same.

If I run Chromium with default stuff, then SafeOnline makes the verification just fine.

I tested like 4 times, always with the same results. Interesting. If you get the same, I'll report to Prevx. I doubt they will do anything about it, though, as most people wouldn't apply integrity levels. lol

ssj100 wrote:

With IPsec, you can also configure individual protocols and ports for respective allowed IPs. So if you know the IPs that need to be allowed, you can just restrict your entire system to these while you bank etc.

I'm going to have to check this out, ssj; We have one XP Pro machine in use still in the household. Thanks for this info!

wat0114 wrote:I'm going to have to check this out, ssj; We have one XP Pro machine in use still in the household. Thanks for this info!

No problem, but I'm personally struggling a bit with IPsec. I think it's effective at blocking individual IPs, but only allowing certain IPs and blocking everything else doesn't appear to work that well. For example, I made a rule to effectively deny all traffic (except anything I specifically permit). Then I made rules to permit access to my bank's IP addresses and my ISP's DNS server IPs. However, there seems to be no consistency in whether the banking site loads, and when it does load, it often takes up to 30 seconds (or more).

Perhaps I'm missing something, but I'm thinking IPsec isn't really effective at creating this "IP restricted banking session". Anyway, let me know how you get on.