CHX-1

Discussion in 'other firewalls' started by Diver, Feb 6, 2005.

Thread Status:
Not open for further replies.
  1. Diver

    Diver Registered Member

    Joined:
    Feb 6, 2005
    Posts:
    1,444
    Location:
    Deep Underwater
    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.
     
  2. dukebluedevil

    dukebluedevil Registered Member

    Joined:
    Sep 14, 2002
    Posts:
    177
    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.
     
  3. Kerodo

    Kerodo Registered Member

    Joined:
    Oct 5, 2004
    Posts:
    8,013
    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.. :)
     
  4. Kerodo

    Kerodo Registered Member

    Joined:
    Oct 5, 2004
    Posts:
    8,013
    Yep, I'm with you on that...
     
  5. dukebluedevil

    dukebluedevil Registered Member

    Joined:
    Sep 14, 2002
    Posts:
    177
    Excellent news indeed! Thanks for the info Kerodo. :)
     
  6. Stefan_R

    Stefan_R Registered Member

    Joined:
    Dec 12, 2004
    Posts:
    47
    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.

    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.

    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.
     
  7. Diver

    Diver Registered Member

    Joined:
    Feb 6, 2005
    Posts:
    1,444
    Location:
    Deep Underwater
    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.
     
  8. Stefan_R

    Stefan_R Registered Member

    Joined:
    Dec 12, 2004
    Posts:
    47
    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.
     
  9. Diver

    Diver Registered Member

    Joined:
    Feb 6, 2005
    Posts:
    1,444
    Location:
    Deep Underwater
    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
     
  10. Stefan_R

    Stefan_R Registered Member

    Joined:
    Dec 12, 2004
    Posts:
    47
    ;) There's that community spirit!!!

    Have a great vacation and watch for the sharks!

    Regards,

    Stefan.
     
  11. Diver

    Diver Registered Member

    Joined:
    Feb 6, 2005
    Posts:
    1,444
    Location:
    Deep Underwater
    Stefan-

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

    Stefan_R Registered Member

    Joined:
    Dec 12, 2004
    Posts:
    47
    Once again, I beg to differ! :)

    Best Regards.
     
  13. Kerodo

    Kerodo Registered Member

    Joined:
    Oct 5, 2004
    Posts:
    8,013
    Diver, nope, 8Signs only has TCP stateful. That's one reason why I prefer CHX-I.

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

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    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) and Port Explorer 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 site. An alternative approach is to try shutting down or altering any running firewalls (process protection software like Process Guard is the best counter to this).
    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.
    It would trigger an alert as Perfect Keylogger's installation guide admits.
    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.
    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 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.
    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.
    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 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) - 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?
    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?
     
    Last edited: Feb 9, 2005
  15. Stefan_R

    Stefan_R Registered Member

    Joined:
    Dec 12, 2004
    Posts:
    47
    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. ;)


    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.

    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.
     
  16. Stefan_R

    Stefan_R Registered Member

    Joined:
    Dec 12, 2004
    Posts:
    47
    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.
     
  17. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    There was a detailed discussion about this in the Firewall with these features?? thread where I did suggest some terms to try to cover the differing implementations.
    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.
    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.
    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).
    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.
    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.
    In other words, like the network connection status as reported by netstat?
    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.
    Nice try, Hype Man. :) Much more of that and we'll have enough hot air to float a Wilders' airship! :D
    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.
    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
     
  18. Stefan_R

    Stefan_R Registered Member

    Joined:
    Dec 12, 2004
    Posts:
    47
    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
     
  19. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    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.
     
  20. Stefan_R

    Stefan_R Registered Member

    Joined:
    Dec 12, 2004
    Posts:
    47
    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
     
  21. Kerodo

    Kerodo Registered Member

    Joined:
    Oct 5, 2004
    Posts:
    8,013
    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?
     
  22. Stefan_R

    Stefan_R Registered Member

    Joined:
    Dec 12, 2004
    Posts:
    47
    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.
     
  23. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    "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.
    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 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... ;)
    Device drivers would be in a different category from running processes (though Task Info does list loaded drivers as does Process Explorer) - 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).
    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.
     
  24. Jazzie1

    Jazzie1 Registered Member

    Joined:
    Dec 5, 2003
    Posts:
    174
    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 levelo_O 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
     
  25. Paranoid2000

    Paranoid2000 Registered Member

    Joined:
    May 2, 2004
    Posts:
    2,839
    Location:
    North West, United Kingdom
    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). 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 has these and it is a closer competitor to CHX-I than personal firewalls).
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.