CHX-1

[Diver]

Adventurs in Firewalling.....

Some of you may notice that I have finally registered for Wilders.

I have CHX-1 up and running on my test machine. Very interesting. First thing I noticed is this baby does not have a service running. There is a driver somewhere, but no service. Over at the Device Manager, View, Show hidden devices, Non-Plug and Play Drivers, I found "CHX-1 filter Hook Driver".

By the way, if you never look in that non PnP driver list, you should. This is where some really nasty stuff can be found, like software keyloggers which tru to hide by not running a service.

It seems that all the examples in the documentation are for incomming filters.

I hope I understand this right, but an incomming filter set to allow, is only allowing incomming packets that is are responsonding to outgiong packets from my machine.

To allow unsolicited incomming packets, I had to set up a force allow incomming rule. For example, eMule requires a force allow incomming TCP on port 4662. Netbios required force allow from ports 137 and 138 to ports 137 and 138 with both local and remote addresses being my lan address range. And so on....

This seems to imply that any application on my machine can make outbound connections on any port to any remote port at any address.

Is this less secure than having a set of rules in 8Signs that allow all applications to make outbound connection on local ports 1024-5000 to remote ports 21,25,53,80-82,110,443,1024-65535 at any remote address?

Perhaps the answer is it is not less secure once you accept that you do not need application control. After all, most trojans are going to operate on these common services anyway.

Any thoughts from the firewall gurus?

[ronjor]

-{ Quote: "Some of you may notice that I have finally registered for Wilders." }-

Great Diver! :)

[Diver]

OK, I think I figured out how to make CHX-1 behave more like 8Signs on the outbound side. I made a filter to allow outbound TCP for the usual stuff.

That is, local ports 1024-5000 out to 21, 80-82, 443, 1024-65535 and so forth.

Then I have a couple of force allow filters for any outbound TCP that needs some special treatment, like restricting port 139 to the trusted lan.

Similar strategy for UDP with special rules for DHCP, DNS etc.

[Paranoid2000]

-{ Quote: "Perhaps the answer is it is not less secure once you accept that you do not need application control. After all, most trojans are going to operate on these common services anyway." }-This statement made me blink a few times...it is because of trojans using common ports that application control is needed. A firewall with application control can distinguish between Internet Explorer trying to send traffic to remote port 80 and StrangeNewApplication trying the same - and either block it or prompt you about this new program.

This feature is for many people the first indication that they have malware on their system and is why, in my view, firewalls like CHX-I and InJoy are suited for proxy servers and ICS gateways (where it is not possible to see the originating application on client machines anyway) - not end-user systems.

[CrazyM]

-{ Quote: "OK, I think I figured out how to make CHX-1 behave more like 8Signs on the outbound side. I made a filter to allow outbound TCP for the usual stuff.

That is, local ports 1024-5000 out to 21, 80-82, 443, 1024-65535 and so forth.
" }-
Just curious as to why the broad rule for 1024-65535 outbound for 8Signs?
It has been awhile since I looked at CHX-1 and whether it would need such a rule.

Regards,

CrazyM

[Paranoid2000]

-{ Quote: "Just curious as to why the broad rule for 1024-65535 outbound for 8Signs?" }-Passive FTP perhaps?

[CrazyM]

-{ Quote: "Passive FTP perhaps?" }-
Not required for 8Signs, the stateful inspection will dynamically allow the port used by the data connection.

Regards,

CrazyM

[Kerodo]

-{ Quote: "Adventurs in Firewalling.....

Some of you may notice that I have finally registered for Wilders.

I have CHX-1 up and running on my test machine. Very interesting. First thing I noticed is this baby does not have a service running. There is a driver somewhere, but no service. Over at the Device Manager, View, Show hidden devices, Non-Plug and Play Drivers, I found "CHX-1 filter Hook Driver".

" }-

Hi Diver... Glad to see you finally reg'd with Wilders. :)

CHX-I runs as a Kernel Service. You can start and stop it in one of the menus if you need to.

As far as the rules go, it looks like you're figuring things out as you go, so that's good. You can set up rules for inbound and outbound traffic just like 8Signs. Takes a little getting used to at first, but it's fairly straightforward. The online docs are mandatory reading as you're finding out...

Once you get your rules set up, you might want to export them to a file. That way you don't have to go thru the hassle of setting them up again if you reinstall sometime.

All in all, it's the lightest on resources of all the firewalls/packet filters I've seen to date. Very nice...

I heard there is a version 3.0 in the works, perhaps coming out soon, so that'll be good to see too.. ;)

[Diver]

Passive FTP...

The range remote ports 1024-65535 on TCP outgoing is used for passive ftp, bittorent and eMule. I noticed on CHX-1 that this range is not necessary for passive ftp as I can check a passive ftp outging boox and it will allocate the ports. I don't know if this will work for bittorent or eMule, but I will test for it.

At the moment I have CHX-1 set up with most of the frequently used internet services (TCP outbound) in an "allow" rule. That blocks everything else, so I need a couple of "force allow" rules to take care of special situations like limiting port 25 to certain SMTP addresses.

I suppose I could run it without any outgoing rules. That would be like I mentioned in the first post. I think that is the equivalent of letting everything outbound which originates within the local machine. Is that right?

[Kerodo]

-{ Quote: "I suppose I could run it without any outgoing rules. That would be like I mentioned in the first post. I think that is the equivalent of letting everything outbound which originates within the local machine. Is that right?" }-

That's basically what I wound up doing. I allowed everything out and then used stateful inspection to control what was allowed in, along with a handful of force allow rules for inbound stuff. Very simple. But it worked for me...

I suppose some would say that's not much protection, but if you're not worried about what's running on your machine then it's all you need. Reminds me of just having a router and nothing else. I guess that's basically what it's like.

[Diver]

K-

I finally succeeded in getting CHX-1 going with both inbound and outbound rules. The hardest thing to work out was that I could not seem to open a server port for bittorrent while I could for eMule. It turns out that my outbond rules had the usual local ports 1024-5000 allowed out. eMule opens up 46xx inbound and bittorrent operates inbound in the 6881-6999 range. The inbound server ports needed outbound communication to work with these rules. Once an outbound port was opened up to match the inbound port for bittorrent it worked. But, it took me forever to realize that.

[Diver]

My conclusion is that CHX-1 is intended to function best without comprehensive outbound rules. This is because I can't find a single example or picture on their site showing anything but inbound rules and also because it was very difficult to deal with comprehensive outbound rules. Perhaps a typical outbound rule would be to reject a range of ports used for some service like IRC.

I found the logging to be a bit too complete. Either it is flooded with all sorts of stuff or it is off. There did not seem to be any obvious way to tailor the logged events to what I am interested in seeing.

So much for that one for now....

[Stefan_R]

-{ Quote: "My conclusion is that CHX-1 is intended to function best without comprehensive outbound rules. This is because I can't find a single example or picture on their site showing anything but inbound rules and also because it was very difficult to deal with comprehensive outbound rules.
" }-

A pretty good observation - I might say.

From a server and/or multi-homed system's point of view, filtering outbound doesn't make any sense(e.g. on a gateway the egress acls are on the internal/service interface, hence they are inbound filters with respect to the internal interface).

The kernel driver is oblivious to the user mode space ( which app is doing what) so outbound filtering in the context of a packet filter is only useful in debugging network apps.

Our packet filter is just what its title implies: a tool to enforce network level acls. If you have a rule blocking incoming TCP dstPort 80 then we can tell our customers that any such traffic will be blocked. Unfortunately, we cannot do the same in the context of "outbound" activity by unequivocally matching a user mode app, parallel protocol and/or driver to an exact network activity. The lack of such control restricts us from offering a viable solution, hence no "app control". Security through obscurity has its advantages, but it is not our primary focus.


-{ Quote: "
I found the logging to be a bit too complete. Either it is flooded with all sorts of stuff or it is off. There did not seem to be any obvious way to tailor the logged events to what I am interested in seeing.

So much for that one for now...." }-

Logging options and implicitly what you'd want to sort is available by right clicking on the log file, select view and then your desired options. You can also customize the mmc console in author mode to include several instances of a log file displaying different filtered info.( Pretty much the regular mmc stuff admins are used to.)

Best Regards,

Stefan

[Kerodo]

-{ Quote: "My conclusion is that CHX-1 is intended to function best without comprehensive outbound rules. This is because I can't find a single example or picture on their site showing anything but inbound rules and also because it was very difficult to deal with comprehensive outbound rules. Perhaps a typical outbound rule would be to reject a range of ports used for some service like IRC.

I found the logging to be a bit too complete. Either it is flooded with all sorts of stuff or it is off. There did not seem to be any obvious way to tailor the logged events to what I am interested in seeing.

So much for that one for now...." }-

Diver, sounds like maybe you like Jetico a little better eh? ;)

I think if I do want app control then I'd probably choose something else, but if I'm not concerned with app control, and I want something like 8Signs or CHX-I, then I'd have to choose CHX-I. I liked the logging myself and found it pretty good and you can tailor it to your needs as Stefan mentioned above. But then again, your situation is probably different from mine.

I'm glad you tried it though... You can at least add it to your list of things you've done... ;D

[Diver]

K-

Actually, I was not thinking about Jetico.

Stefan-

Thank you for the advice. I will have to give CHX-1 another try. I amhaving a blast trying out these programs. I can really see some great applications for CHX-1. It can be set up as a set it and forget it firewall.

Fact of the matter is, folks are making a lot of noise about advanced app control and sandboxing. With that kind of thing you are never done with the pop-ups. Some of the folks around here take for granted their technical knowledge and forget what everyone else does not know.

In fact, thanks for droping in Stefan. A word from those in the know is always helpful.

[Kerodo]

-{ Quote: "

Fact of the matter is, folks are making a lot of noise about advanced app control and sandboxing. With that kind of thing you are never done with the pop-ups.

" }-

There are others with quite a bit of knowledge and experience (much more than I) who insist that app control is a complete waste of time and that malware or other programs can always get past any 3rd party firewall.

I personally don't see the great need for app control for my own situation...

[Diver]

K-

I am with you on app control. The AV and user awareness are supposed to take care of that.

Well, just for fun I put CHX-1 back on. All of 5 rules and it does everything. It seems to run faster than anything else, and the no entry in the task manager is really a hoot after listening to all this stuff about resources.

Per Stefan, I took another look at the log, and indeed it is possible to filter it down to something managable.

I have been fooling around with PC's since the Apple II came out. It cost a bunch back then and you were lucky to have 64K bytes of memory. The PC came along and 640k bytes was high cotton. then 1 mb, 8mb...and now some have a gig or more.

CHX-1 reminds me of the good old days when software got the job done with elegant minimalism. This firewall is the closest thing to not being there while it still does its thing.

[Kerodo]

Yep, it's a great one isn't it? I know what you mean by the minimalist stuff. CHX-I was the lightest thing I encountered. I even went one better and tried configuring IPSEC as a packet filter. Since it's part of Windows itself, I figured it would have even less of an impact on resources than CHX-I, if that's even possible...

IPSEC is pretty cool but the only thing about it is you can't prevent someone from using a source port of 80 and getting into your system to either scan ports or send TCP in. Reason is you have to allow remote 80 out and in at the same time for things to work since there's no stateful in IPSEC. Also, there's no logging, and you can't set up individual ICMP types, it's all or nothing for ICMP (if I remember right).

Here's a link if you're interested in playing with it though:

http://www.microsoft.com/serviceproviders/columns/using_ipsec.asp

I like CHX-I because of it's light footprint, great stateful inspection, good fragmented packet analysis, good logging, and ease of use. You can truly set it up and forget it, as you say. And the liberation you get from the lack of app control is somehow refreshing.. Some will scream at that I know... But the truth is, the best way to prevent programs from doing foul deeds is to not install and run them to begin with... and perhaps use something other than IE for your browser..

[Kerodo]

-{ Quote: "K-


I have been fooling around with PC's since the Apple II came out. It cost a bunch back then and you were lucky to have 64K bytes of memory. The PC came along and 640k bytes was high cotton. then 1 mb, 8mb...and now some have a gig or more.

" }-

I started playing with computers around that time also I guess. The first one I got was a little Timex Sinclair with 16K of ram. Couldn't do much of anything with it except a little Basic. Then I got the first Compaq Portable with 2 floppies and got up to 640K of ram. No HD yet. Those were the days... :)

[Diver]

K-

I had one of those Compaq's too. The power supply burned out twice.

[Kerodo]

Yeah, I remember that was a problem... I think I paid $2500 for mine, if you can believe that. Prices in those days were really high.. Maybe they werent' the good old days after all.. :)

[dukebluedevil]

-{ Quote: "I like CHX-I because of it's light footprint, great stateful inspection, good fragmented packet analysis, good logging, and ease of use. " }-

Me too! :) Stefan has done an outstanding job I think in creating CHX-I! This packet filter is hard to beat, it is just so good all the way around. The lack of application control is a killer for most people I know. If you need it, at least there are programs such as LookNstop that are out there that can be added to control that aspect of things. For me I don't worry about it too much either since I am rarely ever downloading much of anything and if I do download something I am very careful about what it is and who its from. The most important thing I think is just having a very strong anti-virus in place along with many different anti-spyware programs and a little common sense goes a long ways too. :)

[Phant0m]

I agree totally with yea dukebluedevil.

There are numerous reasons to favour CHX-I Packet-filter, for instance it’s by far the strongest packet-filtering system I have ever seen for Windows platforms, it is freeware for home use and the support is currently excellent. And because it uses proper notions everything is a breeze to understand and work with, for my case anyways.

I favour CHX-I but I like 8Signs also though, it does have some nice features that CHX-I doesn’t yet have, but after I get some spare time on my hands I’ll be contacting Stefan again with some more suggestions, and also introduce Phant0m``s rule-sets for CHX-I and even 8Signs.

[Diver]

I think there is a lot less discussion of whether app control is necessary than there ought to be.

While I respect P2k's opinion, I find it difficult to imagine that I would ever be in a situation where a firewall pops up and says "malware.exe wants to conect to remote port 80" as my first warning.

I suppose it can happen because computer techs are constantly cleaning up systems with all sorts of AV's that even had up to date definitions.

Thre are many layers of security, The first and most important one is user awareness. It goes a long way.

Several other layers involve things going on outside the PC. Is the machine in a secure location? If not it needs password enabled access and possibly a lock on the case. Ever check for a hardware keylogger? These beasties actually get used and people have been caught and arrested for it. The results of this attack are a lot more devastating than some search redirector crapware.

How about your ISP/mail provider? Do they bolck ports 135 and 445? How about scanning mail for viruses? Spam filters?

Firewall inbound protection is the next layer. Without it you will be cooked by a worm or hacker in no time at all. IMO, this is what a firewall should do for you.

Next layer: a goood AV. IMO, your AV should be comprehensive enough to catch all malware without the need of an anti trojan scanner although I do keep adaware around. The only AV I personally trust to do that is KAV with extended bases. Possibly, McAfee enterprise is up to the job. Because it is passive, I also like spyware blaster.

Next layer: Dump IE for Firefox or Opera, dump outlook/OE for some other mail client (Eudora, Thunderbird, The Bat, Pegasus etc).

If you have done all of the above, you will not need application control. Once you begin to believe in app control, then you are going to want sandboxing because the leak test guys will put the fear that a trusted app will be hijacked to gain internet access. IMO, sandboxing to prevent firewall outbound "leaks" is about as far as you can go and it results in an annoyance factor itself. Yet, many act like it is the first line of defense.

Sandboxing never seems to be finished. It is totally unacceptable for a non technical user or work enviornment. That's right, stop everything and call IT to find out what to do with the popup. In fact, app control is not generally not used on individual workstations on large corporate networks. It is just not worth the trouble to set it up and maintain.

I believe what is going on is that many users want a completely automated goog proof approach that requires no awareness. They might as well use deep freeze. That sucker is used to protect PC's in libraries.

Back to CHX-1...

I noticed that I could make a rule:

deny, outbound, TCP, source port & addres:any, remote port:25, remote address: not {address range of my email SMTP server}

This limits outbound mail to a particular mail provider, who also happens to require authorization. It would require any trojan sending mail to use the same mail provider that I do. It is a limited form of protection, but it is available.

OTOH, I cant seem to find any reason to have restricted DNS and DHCP rules unless someone around here wants to tell me why.

By the way, Eudora (and several other mail clients) will let you turn off downloading of HTML graphics. The microsoft search phone home can be eliminated with a host file entry for sa.windows.com. Most of the bad behavior of Windows media player 8 have been eliminated in version 9, or just use Media player clasic. Don't forget, back doors and other remotely run malware require inbound commands to run which a firewall blocks without application control. There is a discussion of this on DSLR in a FAQ for the security forum. Anyway , those are several often cited advantages of app control.

I am almost out of here...will cross the Pacific tomorrow...

[Phant0m]

In my much earlier posts I were trying to put that point across, but obviously hinting around doesn’t get comprehended quickly around here…

From my own experiences I know common sense outwits Application filtering, and of all the time I been using Application filtering systems, not once did it ever popup informing me of something unwanted trying to access client&server environments. And from my observations on the Look ‘n’ Stop forums I don’t recall anyone posting about Look ‘n’ Stop detecting something like Trojans on their systems or Spyware of its own code.

However I still see the benefits with “basic” Application filtering like what Look ‘n’ Stop offers, and it is indeed quite powerful one at that, and it is good for restricting unnecessary communications to remote servers such as those for privacy leaks. And I do like to see and control what accesses server&client environments, while Look ‘n’ Stop really doesn’t offer much in away for server defining and controls like something ZoneAlarm has, Look ‘n’ Stop does inform when applications accesses server environments and offers blocking capabilities.

But that said I still don’t think people should act as if App-filtering is first line of defense, because it isn’t and I can understand why James Grant and other authors of only packet-filtering systems don’t favour the idea of implementing app-filtering capabilities due to the fact people get the wrong impression and become careless to where we should be focused most importantly. And pretty much as I been saying, and what I interpreted what Diver have said, a packet-filtering systems should be among the first to have up and running and being properly maintained for today’s activities threats or otherwise…

And that being said I favour strong & true stateful packet-filtering systems much, much more then what I do for Application-filtering systems.

[Diver]

I just want to amplify this a bit. Over at the site for Perfect Keylogger they make a big deal about how it is the only keylogger that does not show up in the windows task manager and how undetectable it is. In their installation guide they make note of how to avoid firewall warnings. Would simple application control a la ZoneAlarm stop this malware? I dont know, but I downloaded the trial version and scanned with my AV. It picked it up, so I never had to test this against any firewall. Go read the installation guide, is hilarious in some respects.

Next I downloaded Ghost keylogger and the AV got it. Same for 007. I quit then because downloading keyloggers is depressing.

By the way, I consider keyloggers to be the most malicious of all malware. Now that the big shift has been away from junk that formats your drive to crap designed to make money for someone, most malware (unless a lot of it gets loose on a company network) annoys rather than really injures. A keylogger can really hurt you by stealing a banking log on.

At least I finally have a firewall in CHX-1 that I can stick on a win2k box and not have to worry about pop ups spooking my mate. I also prefer to open up machines on a small network on only the services needed to talk, rather than the usual application oriented firewall default of declaring the entire network to be a trusted zone for all services, ports and protocols.

[dukebluedevil]

-{ Quote: "I favour CHX-I but I like 8Signs also though, it does have some nice features that CHX-I doesn’t yet have, but after I get some spare time on my hands I’ll be contacting Stefan again with some more suggestions, and also introduce Phant0m``s rule-sets for CHX-I and even 8Signs." }-

Yes, 8Signs is a very good packet filter too. I haven't used it in awhile, but the last time I did I was impressed by it and its developer. 8Signs seems to be a little more innovative in terms of adding new features and such to there firewall I noticed. Of course they charge for it so I guess they have to. :)

I see a company called Third Brigade aquired IDRCI not that long ago, so lets just hope Stefan will still be able to keep working on CHX-I in the future.

[Kerodo]

-{ Quote: "Yes, 8Signs is a very good packet filter too. I haven't used it in awhile, but the last time I did I was impressed by it and its developer. 8Signs seems to be a little more innovative in terms of adding new features and such to there firewall I noticed. Of course they charge for it so I guess they have to. :)

I see a company called Third Brigade aquired IDRCI not that long ago, so lets just hope Stefan will still be able to keep working on CHX-I in the future." }-

I wrote last night and asked them when the next CHX-I packet filter was going to be released, and they said version 3.0 would be released by the end of this month as a public beta. So that's excellent news.. :)

[Kerodo]

-{ Quote: "And that being said I favour strong & true stateful packet-filtering systems much, much more then what I do for Application-filtering systems." }-

Yep, I'm with you on that...

[dukebluedevil]

-{ Quote: "I wrote last night and asked them when the next CHX-I packet filter was going to be released, and they said version 3.0 would be released by the end of this month as a public beta. So that's excellent news.. :)" }-

Excellent news indeed! Thanks for the info Kerodo. :)

[Stefan_R]

-{ Quote: "

I see a company called Third Brigade acquired IDRCI not that long ago, so let’s just hope Stefan will still be able to keep working on CHX-I in the future.

" }-

Correct. Our company (IDRCI) was acquired in September 2004 by Third Brigade Inc. I am not at liberty to make any official statements but I believe we will continue to serve the security community as we did in the past and continue to improve on many aspects of our work that were not previously public. Ideally, we should see all of our drivers go open source soon, among other things.
Most importantly, the CHX development team goes far beyond myself. There are other people who deserve much more credit than I do for the creation of CHX.

-{ Quote: "
I wrote last night and asked them when the next CHX-I packet filter was going to be released, and they said version 3.0 would be released by the end of this month as a public beta. So that's excellent news…
" }-

The 3.0 architecture has been in testing labs for quite a while now. It is being incorporated into the Third Brigade distributed IPS solution and it goes far beyond the regular packet filtering abilities. It is still undecided what will be available to the general public but we are making efforts towards that goal.

-{ Quote: "
And that being said I favor strong & true stateful packet-filtering systems much, much more then what I do for Application-filtering systems
" }-

I think I need to clarify my position on this matter. I am not against application-filtering approaches. I just don’t find much value in them. It is a personal opinion that was reflected in the CHX line of products. This, however, does not mean all the work being done by our peers hasn’t any value. As long as people understand that there will always be one more way to by-pass application control – then that is fine with me. As with the AV industry – a reactive approach that definitely has its value.

One fallacy observed within the security industry is the tendency to keep throwing technology solutions at technology problems driven(and created) by the omniscient human factor. We took the approach of going back to basics and started by calling a dollar a dollar. No need for SPI,DPI,VDPI and so on. Ask yourself this: how many packet filter/firewall vendors detail their stateful algorithm and internal state tables? Yet everyone is throwing these terms left and right. That - my friends - is a sign of FUD, but in a world of dog-eats-dog, the biggest marketing machine wins. Needless to say, the end user loses.

Best Regards,

Stefan.

[Diver]

Beta firewalls? I will let you guys try it out first. Usually I stay away from pre release software until it at least gets to RC status.

Does 8Signs have any sort of stateful inspection on UDP? I never tested for that. It seems that some firewalls do not, judging from the behavior of certain applications that use UDP.

CHX-1 is so elegant in its simplicity. It reminds me of the days before bloat.

[Stefan_R]

-{ Quote: "Beta firewalls? I will let you guys try it out first. Usually I stay away from pre release software until it at least gets to RC status.
" }-

A beta program is needed when new architecture is released. No matter how many efforts we make in testing every single harware/software/network topology scenario - we are bound to miss on something. As you've pointed out, you have a choice between waiting for a stable release or contribute with your experiences. It is a matter of give and take and you have a choice to just take.

Regards,

Stefan.

[Diver]

Whoops... OK Stefan, I will help you out, but only on my P3 beater until it gets to RC status. It might even be ready to try when I get back....

Au revoir

[Stefan_R]

-{ Quote: "Whoops... OK Stefan, I will help you out, but only on my P3 beater until it gets to RC status. It might even be ready to try when I get back....

Au revoir" }-

;) There's that community spirit!!!

Have a great vacation and watch for the sharks!

Regards,

Stefan.

[Diver]

Stefan-

I really hope to see some sharks. There is nothing else like it.

[Stefan_R]

-{ Quote: "Stefan-

I really hope to see some sharks. There is nothing else like it." }-

Once again, I beg to differ! :)

Best Regards.

[Kerodo]

-{ Quote: "
Does 8Signs have any sort of stateful inspection on UDP? I never tested for that. It seems that some firewalls do not, judging from the behavior of certain applications that use UDP.

" }-

Diver, nope, 8Signs only has TCP stateful. That's one reason why I prefer CHX-I.

Have a nice vacation/trip by the way... :)

[Paranoid2000]

-{ Quote: "I just want to amplify this a bit. Over at the site for Perfect Keylogger they make a big deal about how it is the only keylogger that does not show up in the windows task manager and how undetectable it is." }-Typical marketing hot air. It is certainly possible to make a program invisible to Task Manager but the process will still be visible to other task monitor utilities (like TaskInfo (http://www.iarsn.com/taskinfo.html)) and Port Explorer (http://www.diamondcs.com.au/portexplorer/) will highlight any such "hidden" processes. Ultimately, no process can be truly invisible because it needs access to resources (memory, CPU) and, to send data out, it has to connect with Windows' network stack at some level, which is where the firewall comes in.

This is why the more advanced malware tries to hijack commonly-permitted programs (e.g. Internet Explorer) to send traffic out (using techniques like scripting, DLL injection and code injection) since they cannot avoid being identified by firewalls if they make a network connection directly. More details on these methods (and firewalls' ability to counter them) can be found at the Firewallleaktester (www.firewallleaktester.com) site. An alternative approach is to try shutting down or altering any running firewalls (process protection software like Process Guard (http://www.diamondcs.com.au/processguard/) is the best counter to this).-{ Quote: " In their installation guide they make note of how to avoid firewall warnings." }-Quoting from their guide "During the installation of Bpk it is important to choose a good keyword like “upgrade centre”. “Upgrade centre” will look like a legal program that needs internet acces in case of a firewall alert. It will fool many people." In other words, it is not invisible to application-filtering firewalls and relies on installers choosing an inocuous or legitimate sounding name just like most spyware, in the hope that victims will choose to allow it.-{ Quote: "Would simple application control a la ZoneAlarm stop this malware?" }-It would trigger an alert as Perfect Keylogger's installation guide admits.-{ Quote: "Go read the installation guide, is hilarious in some respects." }-Quoting again from it: "Specify the program to combine it with the keylogger. Nice programs are funny exe files...And simple lying will help a lot. Say that it is a funny file and that you’ve just received that file from a friend ;)". This is encouraging people to use this software as a trojan.-{ Quote: "By the way, I consider keyloggers to be the most malicious of all malware. Now that the big shift has been away from junk that formats your drive to crap designed to make money for someone, most malware (unless a lot of it gets loose on a company network) annoys rather than really injures. A keylogger can really hurt you by stealing a banking log on." }-This I would agree with - but any such malware needs network access to complete its job making a good firewall a key line of defence. Anti-virus/anti-trojan programs cannot be relied upon to provide 100% protection since they rely on signatures and it is possible to modify keyloggers in various ways to avoid detection (see the Scheinsicherheit rebasing article (http://home.arcor.de/scheinsicherheit/rebasing.htm) for one method).

The closest thing therefore to a 100% defence is monitoring/blocking keyboard hooks (which is the province of "anti-keylogger" software and more general protection programs like Process Guard) and/or a properly configured application-filtering firewall that can counter all known leaktests.-{ Quote: "I also prefer to open up machines on a small network on only the services needed to talk, rather than the usual application oriented firewall default of declaring the entire network to be a trusted zone for all services, ports and protocols." }-Any decent firewall should allow you to define rules restricted to specific addresses or subnets which would cover this. The "trusted zone" facility is a convenience option for those who don't want to take the time to identify what they need to permit for Windows' common functions.-{ Quote: "I think I need to clarify my position on this matter. I am not against application-filtering approaches. I just don’t find much value in them. It is a personal opinion that was reflected in the CHX line of products. This, however, does not mean all the work being done by our peers hasn’t any value. As long as people understand that there will always be one more way to by-pass application control – then that is fine with me. As with the AV industry – a reactive approach that definitely has its value." }-Thanks for posting in this thread Stefan - since I would like to ask some questions about CHX-I's stateful inspection... ;)

As you have pointed out, there are many terms banded around without being properly defined and SPI has certainly been one of them. However, full SPI (as defined by Checkpoint who first used the term, in their Stateful Inspection (http://www.checkpoint.com/products/downloads/Stateful_Inspection.pdf) PDF) requires specific support for each network protocol (not just network/transport level TCP, UDP and ICMP which is mentioned in the CHX-I online manual, but higher level protocols like FTP, IRC and P2P ones like Gnutella, eDonkey and BitTorrent). I can find no mention of which ones CHX-I supports on the IDRCI website (something like Checkpoint's supported application list (http://www.checkpoint.com/products/firewall-1/vpn-1_firewall-1_appsupport.html)) - could you please either provide a full list or a link to the relevant page on your site?

Also when you say you don't find much value in application-filtering, could you suggest an alternative method for a firewall to distinguish between a legitimate webpage request and a trojan trying to send data to port 80 on a hijacked server?-{ Quote: "Ask yourself this: how many packet filter/firewall vendors detail their stateful algorithm and internal state tables?" }-Outpost firewall has a Debug plugin (only generally available to beta testers though) that allows users to view the internal rules, including temporary ones created by its stateful inspection implementation. Was that what you meant?

[Stefan_R]

-{ Quote: "
Stefan - since I would like to ask some questions about CHX-I's stateful inspection... ;)

As you have pointed out, there are many terms banded around without being properly defined and SPI has certainly been one of them. However, full SPI (as defined by Checkpoint who first used the term, in their Stateful Inspection (http://www.checkpoint.com/products/downloads/Stateful_Inspection.pdf) PDF) requires specific support for each network protocol (not just network/transport level TCP, UDP and ICMP which is mentioned in the CHX-I online manual, but higher level protocols like FTP, IRC and P2P ones like Gnutella, eDonkey and BitTorrent). I can find no mention of which ones CHX-I supports on the IDRCI website (something like Checkpoint's supported application list (http://www.checkpoint.com/products/firewall-1/vpn-1_firewall-1_appsupport.html)) - could you please either provide a full list or a link to the relevant page on your site?

" }-

Frankly, I have no idea what SPI or "Full SPI" means anymore...However - I can tell you how we interpret our own state machine. It is merely a supporting mechanism for tracing packets within the context of TCP sessions. That's pretty much it. You can see its detailed description and its live functionality (via chx state tables) and draw the necessary conclusions for yourself.

Scanning the contents of a TCP packet and triggering adaptive acls are done either internally (e.g. passive, active ftp) or by our payload engine(e.g. stk prototype). Much like we did with nat and the packet filter, we have separated the payload filtering/editing/trigering engine from the basic packet filter/nat modules. For the sake of simplicity,functionality and rationality.

As for protocol support - we do not have a dedicated list on the web site that our engine supports. We occasionally hear from our users about specific protocol problems and we fix them as we go along. FTP, IRC,Gnutella, eDonkey and BitTorrent seem to be working fine although I am sure there's a bunch we don't cover with just the packet filter. It may be a good idea to build such a list although I'd rather build a list of protocols we don't support. Thanks for the idea. ;)


-{ Quote: "
Also when you say you don't find much value in application-filtering, could you suggest an alternative method for a firewall to distinguish between a legitimate webpage request and a trojan trying to send data to port 80 on a hijacked server?
" }-

If I had an answer I would be a happy man. But I don't. I am not even worried about user mode or kernel mode trojans attempting to send data. How about a kernel network driver that modifies data in transit?
In any case - the reason I resist this app control methodology is because I cannot think of any method that would actually work as advertised.

-{ Quote: "
Outpost firewall has a Debug plugin (only generally available to beta testers though) that allows users to view the internal rules, including temporary ones created by its stateful inspection implementation. Was that what you meant?" }-

Good for Outpost! :)

What I meant is a detailed account of how state information is being tracked. What are the exact details part of the state table, and so on and so forth.
An app such as chx state tables answers all these questions and customers don't have to guess what we are doing with their traffic. As simple as that.

Of course, then there's the fine detail of performance, usually not a factor among the private use of packet filetring software. We do not really have an audience within the personal use sector. If we wanted to target that audience we would have built app control!!! Mostly servers and gateway environments - so forgive me if I sound like a novice when it comes to stuff such as Gnutella or Donkeys or other creatures of the same kind. :)

Hope I answered some of your questions, and if I'm late in my replies it is because I do this on my spare time between work and travelling for work.

Best Regards,

Stefan.

[Stefan_R]

-{ Quote: "
As you have pointed out, there are many terms banded around without being properly defined and SPI has certainly been one of them. However, full SPI (as defined by Checkpoint who first used the term, in their Stateful Inspection (http://www.checkpoint.com/products/downloads/Stateful_Inspection.pdf) PDF) requires specific support for each network protocol (not just network/transport level TCP, UDP and ICMP which is mentioned in the CHX-I online manual, but higher level protocols like FTP, IRC and P2P ones like Gnutella, eDonkey and BitTorrent).
" }-

Almost forgot.....about full SPI and what's right or wrong:

"How Stateful is Stateful Inspection? "

http://www.spitzner.net/fwtable.html

Now some marketing stuff:

" CHX-I Fully supports the following list of protocols":

http://www.iana.org/assignments/port-numbers

Impressive isn't it? I could defend the above argument but that would be just hype wouldn't it? ;)


Best Regards,

Stefan.

[Paranoid2000]

-{ Quote: "Frankly, I have no idea what SPI or "Full SPI" means anymore." }-There was a detailed discussion about this in the Firewall with these features?? (http://www.wilderssecurity.com/showthread.php?t=53646) thread where I did suggest (http://www.wilderssecurity.com/showpost.php?p=299171&postcount=27) some terms to try to cover the differing implementations.-{ Quote: "However - I can tell you how we interpret our own state machine. It is merely a supporting mechanism for tracing packets within the context of TCP sessions. That's pretty much it. You can see its detailed description and its live functionality (via chx state tables) and draw the necessary conclusions for yourself." }-That would suggest that CHX-I's stateful inspection only goes as far as network level - which would be the same as almost all other personal firewalls (the only exception I'm aware of is Look'n'Stop where SPI is an option rather than the default). Given some other posters' statements about CHX-I, I was expecting it to offer a higher level of SPI (although it does cover ICMP to some extent while other firewalls offer simple bidirectional filtering) so thanks for the clarification.-{ Quote: "Scanning the contents of a TCP packet and triggering adaptive acls are done either internally (e.g. passive, active ftp) or by our payload engine(e.g. stk prototype). Much like we did with nat and the packet filter, we have separated the payload filtering/editing/trigering engine from the basic packet filter/nat modules. For the sake of simplicity,functionality and rationality." }-Passive mode FTP would be an interesting example to look at in detail. From your previous statement, it sounds like CHX-I would make its decision on whether to permit or block packets by checking whether the packet was part of an existing connection or an attempt to start a new connection (TCP SYN flag set) - if a new connection, this would be permitted or blocked depending on the rules set for the destination address/port. So for passive mode FTP, it would be necessary to have a rule allowing traffic to destination ports 1024-65535 on the FTP server (to cover all possible ports that could be used for the data connection).

Now in passive mode FTP, the FTP client sends a PORT command to the server with the number of the port that it intends to use for a data channel. A full stateful inspection firewall with FTP support would monitor the FTP control channel and would create a specific rule when it saw the PORT command, avoiding the need for a 1024-65535 port rule as per the previous paragraph (if all this seems obvious, my apologies, but a full explanation may be important for others reading this thread).

So the advantage of "full" application-level stateful inspection is that it can reduce the need for overly broad rules to accommodate certain applications which use multiple network connections. Aside from FTP, other examples would include MSN Messenger (for file transfers and voice chat), NetMeeting, Internet Relay Chat (a more complex case since file transfers via DCC would involve the destination having to open a data connection back to the sender) and teleconferencing.

From a security perspective though, most of the benefits of SPI are gained at the network level which gives the ability to distinguish between unsolicited incoming traffic and (legitimate) replies to previous outgoing requests.-{ Quote: "As for protocol support - we do not have a dedicated list on the web site that our engine supports. We occasionally hear from our users about specific protocol problems and we fix them as we go along. FTP, IRC,Gnutella, eDonkey and BitTorrent seem to be working fine although I am sure there's a bunch we don't cover with just the packet filter. It may be a good idea to build such a list although I'd rather build a list of protocols we don't support. Thanks for the idea. ;)" }-For network-level SPI, this should not really be an issue - the main protocols that matter would be TCP and UDP (though you could make a good case for IPsec also).-{ Quote: "If I had an answer I would be a happy man. But I don't. I am not even worried about user mode or kernel mode trojans attempting to send data. How about a kernel network driver that modifies data in transit?" }-That certainly would be a different class of trojan and one that process control software like Process Guard or System Safety Monitor would be better suited to countering (both can block driver/service installations thereby protecting from such rootkit trojans). However these are quite rare while the "let's use port 80 or piggyback on an Internet Explorer hidden window" malware is endemic.-{ Quote: "In any case - the reason I resist this app control methodology is because I cannot think of any method that would actually work as advertised." }-The current difficulty with application filtering is the various leaktest tactics, however the best performing firewalls here (Look'n'Stop and Outpost) do cover almost all the bases. Add in process control software (Process Guard or System Safety Monitor) and a tight firewall configuration (for DNSTester) and every known leaktest can be blocked.-{ Quote: "What I meant is a detailed account of how state information is being tracked. What are the exact details part of the state table, and so on and so forth.
An app such as chx state tables answers all these questions and customers don't have to guess what we are doing with their traffic. As simple as that." }-In other words, like the network connection status as reported by netstat?-{ Quote: "Of course, then there's the fine detail of performance, usually not a factor among the private use of packet filetring software. We do not really have an audience within the personal use sector. If we wanted to target that audience we would have built app control!!! Mostly servers and gateway environments - so forgive me if I sound like a novice when it comes to stuff such as Gnutella or Donkeys or other creatures of the same kind. :)" }-I would agree that CHX-I would seem better suited to proxy servers and gateways (where no information on the application running on the client PC is available anyway) as a first line of defense to block incoming traffic (much like router firewalls for home users). Coupled with an application-filtering firewall running on each client PC to provide control over outgoing traffic, this should provide very good network security. However running a firewall like CHX-I on its own could not cover all the bases in the same way.-{ Quote: "Impressive isn't it? I could defend the above argument but that would be just hype wouldn't it?" }-Nice try, Hype Man. :) Much more of that and we'll have enough hot air to float a Wilders' airship! :D-{ Quote: "Almost forgot.....about full SPI and what's right or wrong:" }-An interesting article - but in all fairness it does not appear to using any of Checkpoint's application rules (the destination ports 23-25 do not include any "multi-connection" protocols where these would apply) and it is 4-5 years old also.-{ Quote: "Hope I answered some of your questions, and if I'm late in my replies it is because I do this on my spare time between work and travelling for work." }-Either you're dedicated beyond the call of duty or a security junkie needing an extra fix - if the latter, then welcome to the asylum! ;D

[Stefan_R]

-{ Quote: "

Now in passive mode FTP, the FTP client sends a PORT command to the server with the number of the port that it intends to use for a data channel. A full stateful inspection firewall with FTP support would monitor the FTP control channel and would create a specific rule when it saw the PORT command, avoiding the need for a 1024-65535 port rule as per the previous paragraph (if all this seems obvious, my apologies, but a full explanation may be important for others reading this thread).

" }-

5:30 am here and I gotta run but just a quick comment....

In passive mode the ftp client actually sends a PASV command and expects the server to send the necessary arguments (dstIP and Port).
In active mode the client send the port with the dstIP and port it expects the server to initiate a connection back (usually from portn-1 to the port specified by the client).
In both cases chx scans the contents of the ftp command channel for these args and adjust it's rules accordingly. However I do not see that as a big deal and as explained priorly this is achieved in the same way with other protos like h.323 etc.



Gotta run but I'll keep an eye on this thread and I hope we can look at some fun features we have implemented and discuss what other features would be worth implementing.

BTW, if you look at the chx stk - you'll understand my earlier statement about separating packet content scanning from pure packet filtering and linking the two with triggers. There's some neat stuff you can pull with this mechanism.

Best Regards and stay safe.


Stefan

[Paranoid2000]

-{ Quote: "5:30 am here and I gotta run but just a quick comment...." }-Browsing forums at this time of the morning? Shame on you... ;)-{ Quote: "In both cases chx scans the contents of the ftp command channel for these args and adjust it's rules accordingly. However I do not see that as a big deal and as explained priorly this is achieved in the same way with other protos like h.323 etc." }-I beg to differ - if CHX-I does scan application traffic and creates rules dynamically based on the contents then this is application-level stateful inspection. This is over and above what most other firewalls offer and should be considered a key selling point - and all the protocols/applications which CHX-I can handle in this fashion should be listed on the IDRCI website.

[Stefan_R]

-{ Quote: "Browsing forums at this time of the morning? Shame on you... ;)I beg to differ - if CHX-I does scan application traffic and creates rules dynamically based on the contents then this is application-level stateful inspection. This is over and above what most other firewalls offer and should be considered a key selling point - and all the protocols/applications which CHX-I can handle in this fashion should be listed on the IDRCI website." }-

I will let the business people handle the key selling points (e.g. CHX customers report losing wight after spending many nights tring to figure it out). Buy two licenses and the third one is half the price of the combined price of the two initial ones! ;)

Anyhow, this is why everything is so confusing nowadays and why I gave up arguing the semantics -which don't matter in the end anyway.

Application firewalls - such as Appshield from Sanctum - are a completely different beast, in the sense that they can fully decode and understand end-to-end network application semantics. Appshield is an example of a web application firewall.

Scanning packets at layer 3 within the context of layer 4 cannot be considered application firewalling. There are too many missing details. Yes, one can easily scan for specific info such as a PORT arg but this does not nearly qualify as an app fw. An app level fw should be able to defend a network server (web, smtp, dns, etc) from data (as in HTTP transaction) attacks. Parameter tampering, session hijacking, etc.

So now we have:

- Protocol scrubbers
- Protocol normalizers
- Network anomaly behavior analysis (mainly statistical)
- Stateful analysis
- Deep packet inspection (matching signatures across packets in the context of TCP sessions, among other things)
- IDS (passive buffering, protocol decoding and sig matching)
- NIPS (pretty much an inline IDS with the ability of dropping packets)
- HIPS ( anything from personal fws, av, anti-spyware to system anomaly analysis)
- Application Firewalls (Web, Mail, DNS)
- Web services firewalls (XML firewall, SOAP firewall)
- My prediction is that this year a new buzzword will appear. I suggest Intrusion Guessing System - a revolutionary alg that would take random guesses at whether a particular packet contains an attack.


All that to say that the packet filter is just a simple tool that must not impact the performance of a server/gateway and allow for selective acls with as much granularity as possible. Workstations should not rely on the pf unless in a corp environment where things such as installing emonkeys are simply not an option.

The packet filter is NOT a security solution for the regular end user. Not even a partial one.

Best Regards,

Stefan

[Kerodo]

-{ Quote: "Browsing forums at this time of the morning? Shame on you... ;)I beg to differ - if CHX-I does scan application traffic and creates rules dynamically based on the contents then this is application-level stateful inspection. This is over and above what most other firewalls offer and should be considered a key selling point - and all the protocols/applications which CHX-I can handle in this fashion should be listed on the IDRCI website." }-

Paranoid, this is not really related to the current CHX-I discussion, but you obviously know quite a bit about firewalls. I was wondering why you choose Outpost over all the others available?

[Stefan_R]

-{ Quote: "

It is certainly possible to make a program invisible to Task Manager but the process will still be visible to other task monitor utilities (like TaskInfo) and Port Explorer will highlight any such "hidden" processes.

" }-

Are you sure? How come the network device drivers are not listed in the above mentioned apps?

Say, for instance - I loaded chxnat.sys and I route all outbound traffic through my rogue system. Where do I see that in the above mentioned apps?


Best regards,

Stefan.

[Paranoid2000]

-{ Quote: "Scanning packets at layer 3 within the context of layer 4 cannot be considered application firewalling." }-"Session level stateful inspection" would be a more accurate term but somewhat more confusing for most :) - "applications" (as in user-run executable files) can cover layers 4 to 7 of the OSI network model so "application-level SPI" would seem an appropriate (if not completely exact) description.-{ Quote: "An app level fw should be able to defend a network server (web, smtp, dns, etc) from data (as in HTTP transaction) attacks. Parameter tampering, session hijacking, etc." }-This is where Deep Packet Inspection and its ilk is supposed to play a role - in my view a firewall should be concerned with allowing or blocking network connections first and foremost with any further analysis (intrustion detection, transaction analysis) being value-added functions. The key problem for these though is encryption (see the Dangers of HTTPS (http://www.wilderssecurity.com/showthread.php?t=31087) thread for more on this) which would prevent any data analysis. As such, preventative measures against such attacks are best deployed on clients where the decrypted traffic is visible.

It will be interesting to see how enterprise firewalls cope with IPv6 where encryption is offered at network level... ;)-{ Quote: "Are you sure? How come the network device drivers are not listed in the above mentioned apps?" }-Device drivers would be in a different category from running processes (though Task Info does list loaded drivers as does Process Explorer (http://www.sysinternals.com/ntw2k/freeware/procexp.shtml)) - my comment was in reply to Diver's post about Perfect Keylogger. Whether a driver could act as a keylogger also is not something I could be certain about, but it should need to install a keyboard hook which would be detected or blocked by Process Guard or System Safety Monitor (possibly PrevX also).

Of course, a driver has to be loaded before it can take effect and process protection software like Process Guard and System Safety Monitor will intercept this (PG will block it, SSM will prompt whether to allow or block).-{ Quote: " I was wondering why you choose Outpost over all the others available?" }-It was the best by some margin when I purchased it with the level of control (via custom rules) and user interface being its strong points - this was back in 1999 when the competition was AtGuard (my previous choice, which had just been acquired by Symantec necessitating a move) and ZoneAlarm. Although there was a verrry long delay before Outpost 2.0 was released, the new features (and those of 2.1 and 2.5 released since) have kept it up to date with most network threats and the UI is still a strong point.

It's not a complete panacea (it has very limited ability to protect itself from termination by malware so really needs to be backed up with Process Guard or SSM) but for the majority of situations, I consider it the best choice.

[Jazzie1]

Hi all!

I have used CHX-I, off and on for the last year and must say it is one of the best packet filtering fw's (next to 8signs) I have ever used.. It does perform 'true' SPI on a network level... Aposed to others, that have partial SPI or are 'stateful like' (Agnitum, Sygate, ect...). I have not seen a fw mechanism that actually does icmp and udp psuedo spi, since checkpoint... I worked with and own Firewall-1 NG with Application Intelegence... And have to say that CHX-I is a good competitor next to CP FW-1.....
I agree with both aspects of both Stefan and Paranoid to an extent. Since security is a layered process, I believe that a good AV, strong packet filter and some common sense, is a good basis for comparison... The opinion I share with Stefan, is that people do 'blindly' rely on application based fw's as a 'protect all' source from all the perils of the i-net. Which it is not.. So in a sense, it is illusionary or gives the illusion that it will protect you and your system against any and all attacks... For the view of Paranoid, I agree that for a workstation, one has the need to control applications and network activity/connectivity... ChX-I is intended for Servers and gateways that required packet filtering capabilities and NOT for the every day, home user... But, since ther is room for expansion and enhancements, do you Stefan, see a version of CHX-I geared towards the home user (workstation) with both a strong packet filter and some form of Application filter on a TDI level??? Because, from the point of view of most, they want to be able to allow/dis-allow (control) some or most of thier apps from calling out. I believe I asked you this before, but you were hesitant to answer me back then. Do to having to investigate into home user (workstation) aspect, apposed to a corporate one.. Thanks for the input!

CU
Jazzie

[Paranoid2000]

-{ Quote: "...Aposed to others, that have partial SPI or are 'stateful like' (Agnitum, Sygate, ect...). I have not seen a fw mechanism that actually does icmp and udp psuedo spi, since checkpoint." }-I can't comment about other firewalls' stateful inspection but Outpost does do "pseudo" SPI on UDP traffic (for details, please see the Outpost forum Stateful Inspecton (http://outpostfirewall.com/forum/showthread.php?t=7443) FAQ). ICMP is not handled statefully but can be filtered by type and direction (for workstations, this should be sufficient).

As for extra features, I'd be tempted to suggest traffic graphs and bandwidth control (InJoy Firewall (http://www.fx.dk/firewall/windows.html) has these and it is a closer competitor to CHX-I than personal firewalls).

[CrazyM]

-{ Quote: "I can't comment about other firewalls' stateful inspection but Outpost does do "pseudo" SPI on UDP traffic (for details, please see the Outpost forum Stateful Inspecton (http://outpostfirewall.com/forum/showthread.php?t=7443) FAQ)." }-
Is that a UDP idle-time-out and can it be user defined?

Regards,

CrazyM

[Paranoid2000]

Fixed time out for UDP.

[Phant0m]

I believe in firewalls that offer users as much custom controls as possible for one with the needs to fiddle whatever to their own needs, and if one thing that can be obvious on the internet is, not everyone has same quirks… And that being said, CHX-I Packet filter is an excellent decision for my needs.

Though it isn’t anything big, I wish for future versions of CHX-I Packet filter to offer logging controls FOR EVERYTHING THAT GETS discarded, I hate the “silently discarded”. At least it isn’t all that bad when compared to what gets silently discarded without user knowledge on those other firewall systems.

You see...? I'm a freaking control freak...

[Stefan_R]

-{ Quote: "Hi all!
do you Stefan, see a version of CHX-I geared towards the home user (workstation) with both a strong packet filter and some form of Application filter on a TDI level???
" }-

I will exclusively focus on network level toys. I will let others - more qualified developers (when it comes to end user stuff) in our company make that decision. You can easily guess what my vote on that decision would be. ;)

-{ Quote: "

I can't comment about other firewalls' stateful inspection but Outpost does do "pseudo" SPI on UDP traffic (for details, please see the Outpost forum Stateful Inspecton FAQ).

" }-

Hmmm. I read the FAQ and I found a rather troubling statement.
"SPI should not be used with a rule for incoming connections - there is no way for Outpost to determine if such a connection is legitimate and would result in further connections being permitted (port scans being a major example).
"

That doesn't make any sense at all. The whole idea of keeping state is to build session information from network packets such as:

- incoming/outgoing SYNs
- Ack packets after a cold start

I suggest you correct that statement since it sounds silly and adds more confusion to the general audience. Mixing TCP state inpection with user mode applications is just a mish mash of mass proportions.

-{ Quote: "

Though it isn’t anything big, I wish for future versions of CHX-I Packet filter to offer logging controls FOR EVERYTHING THAT GETS discarded, I hate the “silently discarded”.
" }-

Everything that gets discarded is logged unless you disabled logging (static or stateful). The "silently discarded" as opposed to reject (send an RST or icmp message) concerns modus operandi rather than logging details.

With that being said - have come across an instance where something was dropped and not logged? If so - it could be a bug and I'd like to follow through with you on our usual communication channel. ;)



Regards,

Stefan

[Paranoid2000]

-{ Quote: "Hmmm. I read the FAQ and I found a rather troubling statement.
"SPI should not be used with a rule for incoming connections - there is no way for Outpost to determine if such a connection is legitimate and would result in further connections being permitted (port scans being a major example).
"

That doesn't make any sense at all." }-Outpost offers two types of SPI - the "network level" one which is applied at the packet level (and cannot be disabled) and a "transport level" option which is discussed in that FAQ. This option should only be enabled when needed for certain applications and only in conjunction with an outgoing connection (which can be verified as belonging to that application).

Incoming connections cannot be verified by the Outpost as belonging to any specific application (it can only go on the port number) so using this option for an incoming connection could provide an attacker with the means of triggering the rule and gaining access through the firewall.

[Phant0m]

-{ Quote: "Outpost offers two types of SPI - the "network level" ." }-

Thanks, that is valuable knowledge...
Now that I know I wont refer to Outpost not being true stateful application-filtering based firewall...

Please don't take this the wrong way, I believe you on this, but are there any official Outpost documents that discusses their SPI Implementation? :-\

[Stefan_R]

-{ Quote: "Outpost offers two types of SPI - the "network level" one which is applied at the packet level (and cannot be disabled) and a "transport level" option which is discussed in that FAQ.
" }-

OK. I am going nowhere with this. Perhaps another attempt would help:

Linking incoming/outgoing packets to a user mode process cannot be called state inspection since it has nothing to do with TCP state. I am not disputing its value here just that the chosen semantics make no sense at all. It is sad to see the devalorization of network concepts by incorrectly using terminology assigned to pure network level activity.

In the contest of personal firewalls I can see that an incoming or outgoing packet is matched to a specific user mode process and processed accordingly, but calling it SPI is just misleading in so many ways.

I now understand better why this term has lost its original meaning. Look at the diagrams in checkpoints paper (Inspect engine) and you'll see there is no communication with user mode process or mapping to user processes of any kind.
http://www.checkpoint.com/products/downloads/Stateful_Inspection.pdf


Regards,

Stefan.

[Paranoid2000]

-{ Quote: "but are there any official Outpost documents that discusses their SPI Implementation?" }-Possibly but most likely in Russian ;) - that FAQ was based on information received from Agnitum developers.

As for Outpost's SPI implementation, the network-level stuff is pretty much the same as any other personal firewall (i.e. fiirewall intended for workstation use) - the extra "transport-level" option (since it is rules-based I would consider it as limited SPI) is a feature of 2.0 onwards and unique to Outpost AFAIK.

[Phant0m]

OK I admit this here is confusing me.
So I was right to include Outpost in the stateful-like list then.....

[Phant0m]

The problem is the lack of available "OFFICIAL" informational resources with many of today’s software firewall products, they should have document detailing every aspect of their product and available in different languages that the product comes in…

[Paranoid2000]

-{ Quote: "Linking incoming/outgoing packets to a user mode process cannot be called state inspection since it has nothing to do with TCP state. I am not disputing its value here just that the chosen semantics make no sense at all. It is sad to see the devalorization of network concepts by incorrectly using terminology assigned to pure network level activity." }-The network level stateful inspection in Outpost is based on the connection state (i.e. a packet is allowed if it is part of an existing network connection or creates a new one which is permitted by the ruleset). This is certainly a valid description since the key criterion is the state of the transport layer.

Outpost's SPI option allows further network connections provided the connection that triggered the rule stays open - it therefore is partially stateful but is not SPI in the recognised sense in that it is a specific rule setting and does not consider the session layer. So yes you can argue that it is not "full SPI" but it is nonetheless a useful facility for some applications. Now can we get back to CHX-I? ;)

[Phant0m]

HAHAHAHA FINALLY, FINALLY, FINALLY, FINALLY I have been proving RIGHT!!! All that arguing in those previous topics yet!!!

:D

[Phant0m]

I apologize for gloating, but I do deserve it!!!! ;D

[Paranoid2000]

-{ Quote: "HAHAHAHA FINALLY, FINALLY, FINALLY, FINALLY I have been proving RIGHT!!! All that arguing in those previous topics yet!!!" }-Uh? If you are talking about the previous discussion in the Firewall with these features?? (http://www.wilderssecurity.com/showthread.php?t=53646) thread, then I would remind you that the "argument" was about the merits of full application-level SPI versus application-filtering + network-level SPI. The posts above change nothing.

[Stefan_R]

-{ Quote: "The network level stateful inspection in Outpost is based on the connection state (i.e. a packet is allowed if it is part of an existing network connection or creates a new one which is permitted by the ruleset). This is certainly a valid description since the key criterion is the state of the transport layer.
Outpost's SPI option allows further network connections provided the connection that triggered the rule stays open - it therefore is partially stateful but is not SPI in the recognised sense in that it is a specific rule setting and does not consider the session layer. So yes you can argue that it is not "full SPI" but it is nonetheless a useful facility for some applications. Now can we get back to CHX-I? ;)" }-

I think I understand now. You are talking about conditional filters. For instance, in chx you can defne what could come in or what gets dropped based on TCP/UDP/ICMP state tables.
So ,if there's an existing connection to dstport 25 then you allow a SYN to 113 from that remote box:
http://www.idrci.net/stef/conditional.jpg

Regards,

Stefan.

[noway]

I pretty much agree that for me, app control is unnecessary. I'm currently using Blackice 2.9car, with customized firewall.ini to control ICMP. It uses 10 MB RAM but I like the GUI. One click on the tray icon brings up the log and settings are accessible by right-clicking on the tray icon. I have tried most of the other firewalls but I insist on quick access to the log/settings without wading through menus. I haven't had to change any settings since I first installed it and it has never crashed. It seems much more stable than the
newer version. It doesn't stealth "TCP "ping"" or "TCP FIN" at PCFlank but I'm not too worried. I use KAV for antivirus.
I have tried CHX-I and liked it too and may switch sometime, maybe soon.
In using app-control firewalls like Zonealarm and Kerio I have learned what
IP addresses need to be blocked by app-unaware firewalls for the programs
I have installed. I think if I am using a non-app firewall that it may be beneficial to install one once in a while just to see if something has changed. This is easy for me since I can make an image using Drive Image, uninstall Blackice or whatever, install Kerio or ZA, monitor app activity for a few days?, then revert to the image I created so that none of the Kerio or ZA stuff remains.
To me, the ergonomics and lack of bugs and annoyances are more important than whether app-control is provided. Based on this, Blackice 2.9car and CHX-I are my top choices, with Kerio 2.1.5 and ZA 2.6.362 after that.

[Infinity]

-{ Quote: "This is easy for me since I can make an image using Drive Image, uninstall Blackice or whatever, install Kerio or ZA, monitor app activity for a few days?, then revert to the image I created so that none of the Kerio or ZA stuff remains." }-

I wonder how speedy your computer will be after a while...that isn't the best thing you can do I guess, changing drastic software packages that often isn't good...your system will get corrupt faster 8) but all the rest will slow down. Kernel level programs shouldn't be played with ::) not so good :)
Take care

[noway]

-{ Quote: "I wonder how speedy your computer will be after a while...that isn't the best thing you can do I guess, changing drastic software packages that often isn't good...your system will get corrupt faster 8) but all the rest will slow down. Kernel level programs shouldn't be played with ::) not so good :)
Take care" }-

Powerquest Drive Image 6 will restore things EXACTLY the way they were,
unlike XP's system restore. None of my saved images contain a single
uninstall. As a result, things couldn't be cleaner. I have done restores 100's of times without incident. If I restore to my first image made after
formatting in November, it will be EXACTLY the same as it was in November,
and so on. I create an image before I install anything new. That's why it
always runs the same, as fast as the day I installed it! So if something gets
corrupted it only stays corrupted until I restore to a previous image. I usually
restore at least once a day, since it only takes about 3 minutes.

[Infinity]

hmmm that's nice Noway, kinda like TrueImage...True Image is great but It happend a lot anyway that things get wrong and you need to use your copy of xp, no use of True Image. Things at kernel level can always act weird but normaly an image would do. (I'm using Raxco's Firstdefence - kinda like yours) and allready had to delete an *image* I made due to some corruption with some ati driver...and since then my system is acting weird lol

[Arup]

I am on CHX alone and have Sysinternal's TCP View on all the time to monitor outgoing connectins, my PC feels super light and my net speed has picked up as well.

[Kerodo]

CHX-I can't be beat for good SPI and lightness.. only thing you sacrafice is that app control. But if you don't need it, then CHX-I is possibly the best.

[Mal76]

Hello all,
I downloaded and installed both CHX-1 management control NAT and CHX-1 packet filter 2.8.2.
Should I have installed both of these?.Do I need anything else?.
I also downloaded the 2.8.2 help file but I cannot open it and online help within that file says page unavailable. So I have no idea how to set this CHX-1 up.
I am running windows xp home and also filseclab firewall.
I am using Antihook on my other computer with filseclab but the free version of that, is for use on one computer only, so I thought I would try CHX.
Antihook was very easy to setup, but CHX seems daunting.
I don't think it's doing anything at the moment.
Thanks for any helpful suggestions you may have.
Regards,
Mal

[Stefan_R]

-{ Quote: "Hello all,
I downloaded and installed both CHX-1 management control NAT and CHX-1 packet filter 2.8.2.
Should I have installed both of these?.Do I need anything else?.
I also downloaded the 2.8.2 help file but I cannot open it and online help within that file says page unavailable. So I have no idea how to set this CHX-1 up.
I am running windows xp home and also filseclab firewall.
I am using Antihook on my other computer with filseclab but the free version of that, is for use on one computer only, so I thought I would try CHX.
Antihook was very easy to setup, but CHX seems daunting.
I don't think it's doing anything at the moment.
Thanks for any helpful suggestions you may have.
Regards,
Mal" }-

You do not need the NAT module unless:

a). you are configuring a gateway
b). you have a server needing port splicing

The 2.x documentation is here:
http://www.idrci.net/doc/packetfilter/index.html

The 3.0 binaries and documentation are available here:

http://www.idrci.net/chx_beta/index.html


Best Regards,

Stefan

[Mal76]

Stefan,
thanks for your reply, and the links. I will disable the NAT and have a read of the documentation.
Regards thanks again.
Mal.

[khazars]

Stefan, when does CHX-I 3 come out, I heard sometime in September, is this still on?

cheers khaz

[Stefan_R]

-{ Quote: "Stefan, when does CHX-I 3 come out, I heard sometime in September, is this still on?

cheers khaz" }-

September sounds good - not 2005 though... ;)

Seriously - we are doing our best to iron out all driver issues before signing it and releasing a stable.
Meanwhile try the latest beta - quite stable as far as we can tell.

Best Regards,

Stefan.

[khazars]

ok, thx for the reply, not trying to rush you into a release, just curious! ;)

[khazars]

I tried CHX-1 beta 3 and I couldn't connect to the internet using 2.6 filters and bind pe filters. I understand I am meant to use something else what and where can I get this?

Ah, this is it below.

- If Allow or Deny All was used in the previous version's policies then an additional packet filter rule MUST be added allowing ARP traffic.

How do I allow ARP traffic?

[Jazzie1]

Here is how your ARP allow rule should look like:
http://www.fluxgfx.com/ssc/attachment.php?attachmentid=22&stc=1

It is basicly allowing all arp from any source. Depending on your network/router, sometimes are too finicky to set ARP restrictions! Normally it would be set from any address, ie: ff:ff:ff:ff:ff:ff

Regards
Jazzie

[Arup]

Khazars,

You only need BIND PE filters if you are using Treewalk, otherwise the 2.6 filters are enough to stealth you or you can use the alternate WAN filters at IDRCI site. I would like to know exactly what interface did you import the filters for and also did you turn on SPI for TCP/UDP/ICMP?

[khazars]

cheers guys for the replys!

I have SPI on for Tcp,udp and icmp .

What do you mean by interface? Interface is cable modem local area connection!

So I only need the 2.6 filters and not

[Arup]

Yep, you only need 2.6 and not the BIND PE, by interface I meant the two physical address of LAN, in your case, the filters should be attached to the LAN where your cable modem is installed. BTW: did you have any other firewall installed before CHX?

[khazars]

yes, I have Jetico, I tried installing CHX 1 again and added those rules and it still blocks the internet. If I delete all the rules including the filter rules I can connect to the internet!

CHX-1 2.8 and Jetico run together no problem!

Any ideas?

[Stefan_R]

-{ Quote: "I tried CHX-1 beta 3 and I couldn't connect to the internet using 2.6 filters and bind pe filters. I understand I am meant to use something else what and where can I get this?

Ah, this is it below.

- If Allow or Deny All was used in the previous version's policies then an additional packet filter rule MUST be added allowing ARP traffic.

How do I allow ARP traffic?" }-

If you are using the Allow base rule set you must add a rule allowing ARP:

Allow Incoming Eth Type= ARP any any

The general rule of thumb is that if something is not working the pf logs are your best friend when debugging pf policies.

Best Regards,

Stefan.

[khazars]

cheers Stefan, I got it, changed allow to force allow and that did it! ;)

Any news on CHX-1 3 release, maybe Xmas?

[Stefan_R]

-{ Quote: "cheers Stefan, I got it, changed allow to force allow and that did it! ;)

Any news on CHX-1 3 release, maybe Xmas?" }-

Good things come to those who wait.... ;)
XMas sounds good !


Best Regards,

Stefan.

[Arup]

Xmas would be a nice gift from CHX Santa:)

[GHost357]

I really liked this program, but it brought me back to the reality, that Im not as smart as I thought I was. Getting it to work, required me to pull half the hair from my head. :D

1) will the Final 3.0 version remain FREE, or is it tiled to for paying peeps? If so, will the 2.0 remain out there for free?

2) Will the Final 3.0 version come with preset filters configured already? As it will take alot of time for me to learn how to make what I need.

I have recently tested alot of software firewalls and will say this one looked the best, used the least amount of ram/pagefile. This small FootPrint on the system will be a large benefit to us all.

Thanks for all your hard work. Hoping when the 3.0 Final rolls that there are some n0oB guides out there, so I can learn how to manage this awesome tool.

[Stefan_R]

-{ Quote: "I really liked this program, but it brought me back to the reality, that Im not as smart as I thought I was. Getting it to work, required me to pull half the hair from my head. :D

1) will the Final 3.0 version remain FREE, or is it tiled to for paying peeps? If so, will the 2.0 remain out there for free?

2) Will the Final 3.0 version come with preset filters configured already? As it will take alot of time for me to learn how to make what I need.


Thanks for all your hard work. Hoping when the 3.0 Final rolls that there are some n0oB guides out there, so I can learn how to manage this awesome tool." }-

Hello,

As far as I know - there is no reason non-commercial license CHX policies should change with the 3.0.

We'll try to include as many sample sets/guides as we can.

Best Regards,

Stefan

[GHost357]

>> As far as I know - there is no reason non-commercial license CHX policies should change with the 3.0 <<

Ahh, good news, Free is great, but could easily see how its attractive to the commercial peeps as well.

Thanks Stefan, looking foward to trying the next version out, once a guide more suitable for my use is availible

[Arup]

It has made me turn off my router's firewall and NAT, I now run it bridged with CHX, thats how impressed I am with it.

[GHost357]

Hiding behind a Double NAT is a good thing.

https://www.grc.com/nat/nat.htm

[GHost357]

Stefan_R, I have a request.

You know in WinXP, you can have an icon (two computer monitors that flash with traffic flow) for each connection made in windows. Regardless if its 56k or BroadBand.

I like to have a clean system tray, no additional icons as possible. Wondering if you would consider adding your firewalls CONTEXT MENU to the windows icon, in notification area? Allowing quick access to needed portions of your GUI, through the windows icon, rather then having your own icon, with its context menu. I just think this would be alittle more streamlined. Not sure if it would reduce you currently low footprint (ram/pagefile useage) further, but it might.

Your thoughts & Ideas on this?

[Andmed]

I have a problem with CHX-I packet filter 2.8.2 running on w2kASsp4eng+critical&important updates.

There is no dial-up (WAN) adapter available in CHX management console.

I have two LAN adapters (VMWARE virtual networks) and both of them are there and work fine.

I have a modem and remote access to Internet provider. It works also. Of course, WAN adapter is ok (checked hidden devices), but I can not see it in CHX-I console and can not manage it.

How can I solve it? I need to make packet filter rules for dial-up Internet connection.


Thanks!


p.p.s. Before CHX-I I was using Visnetic, and WAN was there, so I think the problem is with the CHX-I.

[Arup]

Dial up will only show when its active, so dial up first and then open the CHX console to see if its shown.

[dukebluedevil]

A new beta for CHX packet filter 3.0 was released yesterday. (Not sure whats been fixed)

http://idrci.net/chx_beta/index.html