CHX-1

Is that a UDP idle-time-out and can it be user defined?

Regards,

CrazyM

 

Fixed time out for UDP.

 

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

 

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.

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.

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

 

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.

 

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?

 

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.

 

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.

 

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

 

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…

 

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?

 

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

 

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

 

Uh? If you are talking about the previous discussion in the Firewall with these features?? 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.

 

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.

 

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.

 

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

 

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

 

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.

 

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.

 

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

 

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

 

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

cheers khaz