Windows Vista/Windows 7 + Sandboxie + Integrity Levels

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.

m00nbl00d or wat0114, could you post a screenshot of what your "banking firewall configuration" would look like?

Mine is below:

Blotted out areas are individual IP addresses.



So basically those listed rules would be the only connections allowed to go through while banking. As far as I understand it, the only way for data to be logged (assuming a clean system) would be by either directly hijacking the bank servers or the DNS servers. I'm not talking about redirection - with the rules above, no other IP address can be connected to. Also, only 2 files (with MD5 verification) have access to the internet - firefox.exe and svchost.exe.

An update for IPsec (posted on the Sandboxie forum, but thought I'd better post it on my forum too haha):
http://www.sandboxie.com/phpbb/viewtopic.php?p=72398#72398

IPsec is sort of like a "poor man's" firewall for Windows XP. I try to minimise the number of third party software on my system, and so IPsec is very appealing to me, as it comes built into Windows XP. The important concept is that the built-in Windows Firewall (XP) is unable to control (block) outgoing traffic. Now when it comes to (malicious) data mining, outgoing traffic is of importance to the "hacker" - without it, the hacker wouldn't be able to steal any data.

One of the features of IPsec is that it can be configured to block certain internet (and intranet) traffic on your local computer. In fact, you can create a default deny policy which blocks all traffic. Then, you can create further rules which allows specific traffic in/out. I must admit that it's not very user friendly (especially when you're new to it), but it's all pretty much set-and-forget once configured.

In fact, for my "banking setup", I only have two rules configured. One rule is to block all traffic. Another rule is to specifically allow incoming/outgoing TCP protocol traffic via Port 443 to my bank IP address. Any other traffic will be denied by default while this policy is in place.

There are numerous web-sites out there which give instructions on how to use IPsec in general. Here's one:
http://www.petri.co.il/block_web_browsing_with_ipsec.htm

There was also one post on a forum I randomly came across (can't find it now) which gave instruction on how to block all traffic and only allow communication with certain IP addresses. However, it's all quite simple and logical once you get familiar with the settings.

m00nbl00d, I was just thinking, applying Integrity levels like you've described in this thread would not help if the malicious logging mechanism was running with High integrity (for whatever reason)? This scenario would be very possible - for example, the user (mistakenly) installed malicious logging malware as Admin. This could happen if the user downloaded an apparently genuine file that was "tagged" with malware. This shows how important it is to eg. verify digital signatures, checksums etc.

ssj100 wrote:m00nbl00d, I was just thinking, applying Integrity levels like you've described in this thread would not help if the malicious logging mechanism was running with High integrity (for whatever reason)? This scenario would be very possible - for example, the user (mistakenly) installed malicious logging malware as Admin. This could happen if the user downloaded an apparently genuine file that was "tagged" with malware. This shows how important it is to eg. verify digital signatures, checksums etc.

You're correct. The method I described is only efficient if the malicious logging mechanism is running with a lower integrity level - low or medium.
By design objects with the same integrity level can interact with one another.

But, if the situation you describe happens, then I'm afraid there's no trust in the system. Once something gets high level access, and especially kernel access, pretty much all bets are off. I wouldn't put blind faith in anything in my system, at all.

So, as you say it's very important to verify digital signatures, checksums, download from official and/or trustworthy sources, verify the downloads with antimalware applications (online and offline), and also monitor the application's reputation (if it is widely known or recent). I personally try to avoid applications that I can't find practically no information in trustworthy sources.

Resuming, using the method I described as part of a layered security and common sense, then it will be one more layer fighting malicious logging mechanisms in user land. And, in good truth, malware doesn't need kernel access to do its dirty work; sure it's way better, but not truly needed.

I see it as a matter of when, rather than if. When a malicious logging mechanism is lurking around, then having the extra comfort of knowing my method is there to stop it from retrieving credentials is worth the little hassle of setting it up. If it's one lurking in higher places, then bend over -

I think restricting IP addresses and Ports (like you've described) would probably still defeat malicious logging mechanisms even if they had higher level or Admin access? I'm not sure about kernel-level loggers - what level does Windows Firewall (or IPSec) function at? What level do third party Firewalls function at? Would kernel-level loggers bypass these? If so, would a hardware-level Firewall restricting the IP address/Port prevent this bypass?

Whatever the case, I think for the vast majority of instances (probably ALL practical and real-life instances), restricting the IP address/Port is the safest bet when it comes to sensitive (financial) browsing. Software like Webroot SecureAnywhere and Trusteer Rapport continue to be bypassed as evidenced by public demonstrations. Also, I don't see any evidence of the same sort of software "saving anyone's bacon" with regards to information stealing.