new portable firewall

Can it be made simple to use on default settings( like application based- allow x.exe, block y.exe etc)? Complex rules can be hidden in advanced settings for power users.

 

We won't be blocking applications from running, but we would allow applications from being blocked/limited for communicating.

 

Take a look at Jetico and you'll see what I mean

 

It's one thing to separate "network rules" from "application rules", but Jetico certainly is not intuitive.

IMO, or my preference , Kerio 2.1.5's model or ComodoFP are ideal. I mean only CFP's firewall bit, and with 2.4's GUI stile, not window here window there v3 stile...
Kerio since one table gets it all, or CFP since there are objective differences between global rules (apply to the OS as a whole) and per application rules. Global rules are read first.

Both are easy to set rules from the prompts, assuming you know them - doesn't take a manual, just networking concepts and knowing where the options are and how they work.

Kerio allows you to create a custom rule right from the prompt.
CFP allows you to set the "alert level", and then your answer to prompts will create rules as refined as you chose in that level (from yes or no, up to specific IPs and ports). That could be an extra option, i certainly enjoy that in CFP, and don't miss Kerio's feature that much because of it.

Being portable i don't know what is applicable really. How does it save settings, etc.

 

Disable the Process Attack Table and Jetico is a intuitive rule-based firewall if you dig a bit.

 

I mean Block internet access for x application, allow for Y application etc. Application based rules.

 

Some governements in europe are preparing in the next month a keylogger.

They will contact the antivirus and firewall editors in order to ask them no to
detect their keylogger.

Is kerio enought independant ??

 

Well, the first comment is that you have no chance of being able to please everyone (as the varied requests made so far show) so providing some indication of design priorities (security, ease of use, flexibility, speed, low resource usage) may help in deciding which ones to accommodate first.

The second is that portability is going to be pretty hard for a firewall in Windows - you need to implement a driver of some sort for low-level network filtering and that in turn will require administrator privileges and a system restart.

However I don't think you have an option with NDIS-level filtering - security needs to be a prime factor and without NDIS, you can't provide adequate protection from incoming attacks (especially ones exploiting buffer overflows in the network stack). Being able to limit traffic by application is pretty much a requirement so you'll need TDI also.

A further factor to consider is malware resistance - do you want your firewall to be able to resist being shutdown or disabled by malware? If so, then you need to look at process control features (specifically being able to block driver installation, physical memory access and process termination/modification) regardless of the calls by others here to avoid "HIPS". Yes, Kerio may be a good network filter, but it wouldn't last a second against malware attack. If not, you need to warn users that extra software (e.g. System Safety Monitor) needs to be used, and you need to check compatibility.

Leaktest performance - Windows has certain "features" (Internet Explorer, DLL/code injection, AppInit DLLs) which malware has exploited to gain network access via trusted programs. If you want your firewall to provide comprehensive security, it needs to address such techniques.

Logging is important since users need to be able to see what is being allowed and what isn't. Without good logs (and easy ways to filter them) users will have to work blind in creating the best configuration.

Stateful Packet Inspection (SPI) - you can't do a useable firewall without at least network/transport-level SPI (identifying which TCP stream packets belong to) and that shouldn't require much extra processing (indeed, it could save CPU since you only have to do a full rules check on the initial SYN packets). Higher levels of SPI can be avoided (though adding something for FTP control/data connections would be a good idea).

Most users have little knowledge of what to allow or deny - if you are going to cater to non-experts, then you have to provide a simplified configuration setup (probably relying on whitelists of known legitimate applications).

Features which I would suggest as being of lesser importance (i.e. better left until version 1.0/2.0 is released) include:

• ARP filtering - not relevant to most home users.
• IP blacklists - attractive to P2P users but of little use to everyone else.

Finally I would suggest considering this for GNU/Linux instead - there is almost nothing available there in terms of application filtering firewalls (the only example I can find is TuxGuardian) while Windows users have dozens to choose from.

 

Adding HIPS is going to cause several problems. It wouldn't be very portable or easy to use if the user has to start out configuring a HIPS every time it's plugged into a different PC. Even if it uses whitelists of the common apps and system components, how would the portable HIPS determine if the apps are legit or malware files that have modified or replaced system files? Signatures for every version of each common internet-able executable that's been released? For how many versions of windows, going back how far? If this is limited to just the newer systems, you've just limited how portable it will be.

It should be possible to give the firewall resistance to termination without making it a full blown HIPS. Resistance to malware is a very tall order for a portable product.

Being portable, it's likely this would be used mainly on someone elses PC or network. Anyone security conscious enough to want a portable firewall is most likely running one already on their home PC or network, where using such a device would be redundant. Since it's going to be used on PCs and networks that are not under the users control, possibly already compromised, it should have this. It would be useful for power users but might be more than the average user can deal with. Then again, would an average user carry a portable firewall? IMO, such a device targets power users and those who take security seriously, users who should be able to handle the details. It's also probable that it would get used on PCs and networks that have existing firewalls the user isn't aware of, causing possible compatibility problems and interactions.
Rick

 

I forgot to mention WIPFW. You might want to check it out in case you haven't already Xerobank

I disagree. Although i didn't use it that long, it still stands. I didn't get the point in a few days, so it's not intuitive for me.
Rules were all over the place

 

Agreed. A default configuration covering a basic Windows setup would cut the burden though.

Signatures for the 50 or so most common products should be good enough for most new users in most cases. Windows system components should be digitally signed so checking this is valid should suffice.

Malware resistance is something that either needs to be done well or not at all. Doing it well means covering all the actions noted above (and others like WM_CLOSE/SC_CLOSE messages, SendKeys, process suspension or debug privileges).

Given the requirements (admin access and reboot) I think portability is impractical. A better bet would be to use a VM (GNU/Linux most likely) and implement a firewall within that. Then at least you have a known environment, though still vulnerable if the host OS is compromised.

How on earth is ARP filtering going to be of any use with a compromsed system? There is realistically nothing a firewall could do since it can't be sure of setting hooks, intercepting network traffic or even seeing what programs are running. ARP filtering is only useful for users sharing a LAN with an attacker and all it protects against are some types of DoS attacks.

 

Well, this proves that someone's mind works differently than other's . I have a "Kerio 2 mindset". This and a bit of reading (help file, forums) was enough to dominate Jetico

 

Hello,

Paranoid, when you say Linux firewalls with application filtering are few, you should remember that most are based on iptables with a nice frontend.

iptables allow you to filter packets by user id, group id, process id, process name, and so forth. This means that any distro running iptables can effectively filter applications. It's not simple to setup, but it's there.

Just type man iptables (google or linux terminal) and you'll see an endless list of options...

As to effectiveness of a portable firewall, I agree - and that's why I asked my original question. How can this be implemented without rebooting, starting a service etc...

Mrk

 

This will be very problematic. Between the different versions of OS components and the number of versions of those 50 or so internet apps, this could easily get to hundreds if not thousands of signatures. That signature database could become obsolete very quickly as well whenever a new version of one of those apps is released. Unless the user updated it very regularly, any form of integrity checking that involved stored signatures could become outdated almost as fast as AV signatures. This might require too much maintenance to be practical.

Ideally, yes, but I don't see where that would be possible. For an app to be resistant to all possible malware attacks, it has to be hooked into the OS pretty deep, almost to the point of becoming part of the OS. That's completely impractical for a plugin device. Even so, there's nothing lost by giving it some termination resistance against the more commonly used methods. The user just has to understand its limitations, starting with the fact that a plugin device can't have the same level of control over an OS as a kernel hooking security suite (or a rootkit).

Even if it could do very little, I'd still want the ability to view the traffic.

I've been trying to figure out just where such a device would most likely get used. The places that come to mind are the workplace and possibly on a friends or acquaintances PC. I don't see either one responding favorably to someone attaching such a device, no matter what it's purpose. Many if not most PCs, home networks, businesses, etc already have at least an inbound firewall in place. If not the one in Windows, the one that's part of the cable or DSL modem. Even if it can be made to work well, I'd question if it should be used on someone elses property. I can't imagine the average employer saying yes and I'd be quite mad if I caught someone plugging a device into my PC without asking.
Rick

 

Heh. Think about that for a second, Paranoid: We don't have admin and boot privs, so instead we'll use a VM, which requires admin and boot to install drivers.

I'm thinking we can do TCI from the current session. That may be all we can do. Then again, we're still trying to think about what is possible in a world where users want features. When we get into NDIS we're approaching trouble.

My thought is the firewall is deployable: 1) It uses TCI for current session, and if you want to keep it in place 2) we can insert a NDIS driver on boot.

This allows us to even stay Vista compatible. I don't think we're going to try to support <2k.

The idea isn't the end-all be-all firewall. There are already a gazillion of those out there. I'm trying to feel out if there needs to be an alternative, if there is a niche that isn't being filled.

So let's start with some assumptions for the TM:

1) The user has driver installation privs for TCI

2) The user isn't worried about stopping malware, but spyware/leakware

3) The attacks we are trying to stop are anonymity/privacy compromising issues. For example: leaky plugins, bad mime handlers, PDFs phoning home, evil Java, etc.

4) The user doesn't have a strong understanding of anonymity/privacy aspects.


As you may notice, lots of software is written without regard to anonymity or privacy aspects. This is perhaps one reason that anti-spyware/cleanup programs don't go after flash cookies or DOM storage. Well, this firewall might be suited to stopping unauthorized communications that diminish the privacy of the user.

 

The process name would be useful but only if it included the full path (so /usr/bin/traceroute's permissions aren't allocated to /0wned/traceroute also). There would still be a need to keep a hash of each process (and check it on every new connection) to catch any changes, so this would need a bit more than just a front end.

However assuming the problems are worked out (command matching is supposed to have problems on SMP systems, is that still an issue?) then iptables could certainly be used as a foundation for a more interactive firewall.

You can avoid having a service by using a driver but avoiding the reboot is going to be harder. However Drive Snapshot loads a driver temporarily for low-level disk access without needing a reboot (just admin privileges) via SCM/services.exe so maybe the method it uses could be applied to gain low-level network access too.

It's far easier than the task currently managed by AV software, involving tracking tens of thousands of malware variants and updates would require far less work (no need for code analysis, just a script to check the main download site for each utility daily for updates). Accumulating signatures for older software versions would be harder but allowing users to submit theirs is one method. A bigger concern would be ensuring any updates are not subject to compromise (using https: should suffice).

Bear in mind that 100% coverage isn't essential here - just providing the most common signatures to cut down on prompts, so users can focus more closely on those that remain.

That is, I would respectfully suggest, very much a specialist feature.

That should be workable provided that the NDIS install checks first for existing firewalls and prompts the user to go offline and disable/remove them first. Even with TCI/TDI only, compatibility with some existing firewalls may be a problem.

In this case, how about just providing premade configuration files for those firewalls supporting rules import? That would achieve these goals with much less work.

On the other hand, if you're using a GNU/Linux VM, the iptables options mentioned by Mrkvonic could be brought into play - the downsides shouldn't be an issue with a clean VM image.

 

Hello,

Paranoid, the exact path has less meaning in Linux than in Windows, because built-in commands are declared in the PATH variable. Therefore, when you type traceroute, you will only ever execute the one declared in the path.

To change the path, you require root - and if "malware" gets into root areas of the system then the firewall won't help you. Likewise, if the bad app has access to path and can change it, it's much more serious than firewall control.

Local commands will require ./ to execute, but again, they will only ever run with local user privileges - no access to root areas.

Finally, the chance of contracting badware is much reduced, since there's the issue of official repositories, global system-wide updates, separation of user/root, and the inherent trust of the environment. While in Windows, you definitely want to restrict apps - you probably do not want to this in Linux - and most won't try to phone home, either way.

Thanks for pointing out the driver issue ...

Mrk

 

Windows is similar in having a $PATH variable, however the reason for having the full path name in firewall permissions isn't to cover a user from accidentally running the wrong version of a file - it is to prevent malware from using an identical filename to gain network access (it would certainly use the full pathname to call its networking component in such a case).

The overall risk for a Linux system may be less than with a Windows one but it is still present and likely to increase - it is therefore desireable to have security solutions that can not only address current threats but also look ahead to future ones.

 

Hello,
Thanks for the interesting topic.
Cheers,
Mrk

 

Hmmm I suppose that is doable, but what about for those that have no such firewalls at all?

 

You can provide some general guidance on firewall configuration (e.g. limiting browsers and Java to connecting to Xerobank's client only, blocking open DNS traffic) but otherwise the situation is analogous to someone using Firefox rather than XB's browser - they can do it, but they have to take responsibility for the configuration themselves.

 

There are GUI's for Windows fw, one adds application control. That's a possibility no?

 

Why not have two versions in one package. Option to use portable firewall (with limited security), or install the full thing.

Maybe check out http://www.personalfirewall.comodo.com/distribute.html (comodo firewall) and think about getting a stripped custom version as one of the options when installing?

 

You might consider this thread on the process:

https://www.wilderssecurity.com/showthread.php?p=1107681

In my opinion, Outpost Firewall is the best I ever used. Beware the new versions, because they are not that good. I am using 4.0.1025.7828 (700) now.