Questions about CHX

Ingress / Egress acls are usually implemented at the perimeter (router,fw,etc). An Internet facing TCP application(e.g. web server) may also benefit (as in increasing the cost of attack) from ingress filtering applied on the host if SYN-flooding is in progress. You also have the Syn cookies option to help increase the cost of a syn flood attack.

The sample sets are meant to help understand the filtering functionality of CHX. Since no two networks or systems are the same – chances are each system will have a different rule set.

Whether you run chx tools on a gateway(router, fw, bridge) or an end point, keep in mind its intended functionality: providing a mechanism for implementing network access control filters and a network transport mechanism (nat). From a simple packet filter static rule to a relatively complex payload rule mitigating SQL injection (payload) to port splicing (nat), these tools are also meant to provide visibility into network events and assist anyone interested in understanding network filtering.

Best Regards,

Stefan.

 

I'm comparing the filters that I got from vampiric_crow with the Workstation sample that you can download from http://www.idrci.net/downloads/samplesets.zip.

VC's filters allow *any* ICMP packet to come in.

But the sample from idrci.net has a ICMP rules that only allow packets with the following flags to come in:

type: 0, code: 0
type: 5, code: 128
type: 1, code: any
type: 1, code: any (this is either a mistake or a duplicate)
type: 1, code: 130 (I would think this would be covered by the previous rule)

So is it OK to let all ICMP packets through, or should I only allow certain ones to come in?

 

The sample that I give you only have the "***Deny Ingress filter" changed and was added the "***Allow Router Broadcast" rule.
All the other rules was made by Stefan...

 

Type: 0, :-Allow in(echo reply)

Type 5 code 128 :- I dont know the code,
For type 5: (Redirect)
Codes
0 Redirect Datagram for the Network (or subnet)
1 Redirect Datagram for the Host
2 Redirect Datagram for the Type of Service and Network
3 Redirect Datagram for the Type of Service and Host

Type 1 is Unassigned


ICMP Types/Codes Info

.

 

stem: OK, looks like those rules were defined incorrectly, but have the correct descriptions. Based on the descriptions, it has rules to allow the following ICMP packets:

type 0, code 0: Echo Reply
type 11, code 0: Time Exceeded: Time to Live exceeded in Transit
type 3, code 1: Destination Unreachable (Host Unreachable)
type 3, code 3: Destination Unreachable (Port Unreachable)
type 3, code 4: Destination Unreachable (Fragmentation Needed and Don't Fragment was Set)

So are those the "safest" ICMP packets to allow, or is it OK to just allow all ICMP packets?

 

Can anyone answer a question about the stateful inspection engine? I'm finding this to be really confusing. Here's what the online manual says:

the CHX-I stateful mechanism generally acts the following way:

- A packet is passed through the stateful routine if it is explicitly allowed via static filters.

- The packet is examined if it belongs to an existing connection by checking the CHX-I connection table for matching end points

- The TCP header is examined for correctness (e.g. sequence numbers, flag combination)

So the first bullet makes it sound like an incoming packet is checked against the filters before the stateful inspection engine checks it. So if you have a rule to allow an unsolicited packet, it will be allowed at this first stage.

But then the second bullet makes it sound like the stateful inspection engine will reject unsolicited packets? So even if you have a rule to allow an unsolicited packet, it will not get past the second stage (the stateful inspection engine)? That can't be right... I must be misunderstanding something here.

 

Hi delerious,

The ICMP rules you have posted should be sufficient, I personally only use 4 ICMP rules, the first 2 you mention(in), the type 3 with any code(in), and type 8 (out) for ping command.

Stem

 

Hi delerious,

Yes,..

If a packet is found by the SPI to be out of sequence, then the static rules are checked to see if the packet should be allowed. If a rule is found to allow the packet, then this is passed back for SPI. If no static rule is found, the packet will be dropped.

Stem

 

Correct.

If you make a rule to Force Allow, like you should do if you want that your system acts like a server, that packets aren't blocked...

Take a look at the Filter action type options...

 

Hi VaMPiRiC_CRoW,

The force allow is to over-ride an exising static Block rule,..

Example from online help file:

A simple example for low priority allow rule for SPI could be:

Allow out TCP remote port 80

You would then connect out to the web(http), the SPI would then check all packets for the sequence for that connection,... you then open a new (2nd) connection, the SPI would see this out of sequence, and pass back to static rules (the first connection is still active within the SPI), the static allow rule is found and the 2nd connection is allowed and passed back for new sequece in the SPI (both connections would continue).

If a force allow was needed for this, then only one connection sequence would be allowed at any one time for a low priority rule.

Stem

 

I expressed myself badly...

I only wanted to make a suggestion to how allow incoming traffic.

Thanks for correcting this

 

I think I understand the Deny, Accept, Force Allow stuff. It's how the state inspection engine works that is confusing.

stem: in your post at 5:49 AM, you agreed that an incoming packet is first checked against the filters. Then you said that if the SPI found it to be out of sequence, the packet would be checked against the filters to see if it is allowed. But it already did that... that was the first thing it did. Then you said if it is allowed, it would be passed back to the SPI. So one packet could go through the following: check against filters, check by SPI, check against filters, check by SPI?


Here's another question: the manual says:

2. "Allow" rules are Prohibitive. This means anything not specified in the Allow rules is automatically dropped.

I have not defined any rules for the Outgoing direction. Since no outgoing has been specified, all outgoing packets should be dropped, right? So why is it still allowing me to use my web browser?

 

It has been a while since I have used CHX-I, but you must first create a rule which concerns outgoing for the default block all not defined to take effect. For example, when you first install CHX-I, there are no rules thus no effect on your internet connection.

 

Normally, from my use of firewalls with SPI, the start of sequnce is a connection (SYN packet) to an IP, the sequence is then checked and remains with the SPI untill out of sequence. The working of the SPI would depend, first on the implimention by the dev, and then on the rules in place.

As poted by "AJohn", I think this is down to the direction, if you have no filtering on outbound then all would be allowed.

 

Assuming each network interface has a list of static rules, state options enabled and payload rules attached to a traffic stream the following applies per interface(directions are treated separately with respect to each interface):

TCP:
- any incoming datagram is checked against the static rules chain (not necessarily all of them depending on action/priority)
- any incoming datagram that is explicitely or implicitely allowed is then passed to the TCP stateful engine.
- any incoming datagram that passes the stateful inspection engine is then passed to the reassembly/normalization engine and subsequently to the payload rule alg.

UDP/ICMP:

- For each interface - an outgoing datagram creates a pseudo stateful entry with a timeout value. A "response" (e.g. if an outgoing echo request, then we expect an incoming echo reply) will be allowed if-and-only-if it passed the static rules (e.g. Allow incoming icmp)
One difference with pseudo-states for UDP/ICMP is that in the absence of static rules any "unsolicited" udp/icmp datagram is discarded.

!As noted above for each interface directions (incoming/outgoing) are treated separately.

You may also find this interactive demo useful:

http://idrci.net/products/qt/spffunc.html

Best regards,

Stefan

 

Thanks for the replies, everyone, I appreciate it. I have not yet digested the information in the latest replies, as my job has gotten really busy, but I hope to do so within the next couple days, so there will probably be a follow-up by then.

 

Thanks everyone, the recent replies and that interactive demo were very helpful. Let me see if I've got this straight now...

If you have no filters defined for a direction, then all packets are allowed in that direction (unless you have enabled stateful inspection for UDP and/or ICMP packets, in which case incoming UDP and/or ICMP packets that are unsolicited will be denied).

If you have one or more filters defined for the incoming direction, then an incoming packet is first checked against those filters. If the filters allow the packet, then the packet is handed off to the stateful inspection engine (assuming that you have enabled stateful inspection for the protocol used by the packet). If the packet is an unsolicited UDP or ICMP packet, then the stateful inspection engine will reject it (unless it had been allowed by a Force Allow filter, in which case the stateful inspection engine will allow it). If the packet is a TCP packet, then the stateful inspection engine will determine whether or not to allow it (for example, an unsolicited ACK would be rejected).

That sound about right?


Now I have some questions regarding the Interface Properties dialog box:

- Is there any reason to not block unsolicited ARP replies?

- Is there any reason to not deny all incoming fragmented packets?

- What do "Skip Fragmentation Analysis" and "Clear IP Options" do?

- Is it recommended that I leave the "Reset incoming datagrams' TTL value to" box unchecked?

- I enabled stateful inspection for UDP, and I also checked the "Don't keep state incoming for force allowed UDP" box. Right now I have a rule that Force Allows all incoming UDP packets, and my router sends me a UDP packet every 30 seconds. I notice that the ChxStateEntries.exe program is showing those UDP packets from the router. But since I checked the "Don't keep state incoming for force allowed UDP", shouldn't the ChxStateEntries.exe program not show those?

 

Correct.

Gratuitous arp replies.

Many reasons. If you run a network trace, chances are you will often see legitimate fragmentation. It is a bad idea to have this "feature" on unless you have a very specific need.

sometimes, the frag analysis can interfere with testing of the IP reassembly alg. For instance, if you use fragroute to test the IP reassembly alg, many fragments will be discarded by the frag analysis alg.

Removing IP options can mitigate some vulnerabilities in TCP/IP stacks. (e.g. http://xforce.iss.net/xforce/alerts/id/192 )

This is a feature for gateway environments.

This can be a bug. If you disable the Force Allow - do you see these UDP datagrams blocked ?

Best Regards,

Stefan

 

So I can get more than one ARP reply to an ARP request? But don't I only care about one of them, which would be solicited anyway?

OK. I've read a lot of people who run Kerio 2.1.5 and they mention the "fragmented" problem, which they say you can solve by using CHX-I to discard the fragmented packets. I'm not running Kerio, but based on what they said I thought allowing fragmented packets might be a bad idea.

So would you recommend enabling the "Skip Fragmentation Analysis" and "Clear IP Options" boxes?

So I should leave it unchecked for a workstation computer?

I turned on my laptop tonight and noticed that the ChxStateEntries.exe was no longer showing those UDP packets. So I unchecked the "Don't keep state incoming for force allowed UDP" box, and then I started to see the UDP packets. So then I checked it again, and I still saw the packets. Then I stopped the CHX Packet Filter Module Driver service, and restarted it. Then I finally didn't see the UDP packets. So I guess when you uncheck the box, you don't need to restart the service, the setting will take effect immediately. But if you check the box, then you need to restart the service before it takes effect.

Thanks for your help, Stefan!

 

It's a bit more complicated than that. I guess you can safely leave that feature on.

These people do not understand the fact that fragmentation is part of the Net's daily life....

No to the "skip frag analysis". Yes to the "Clear IP Options".

Yes.

Thanks for your feedback.

Best Regards,

Stefan

 

Now I have a few more questions...

- My router sends me ARP packets, so I have a filter to allow those. Is it OK for me to allow only ARP packets from my router's MAC address, or could someone else send me legitimate ARP packets?

- Is the SYN flag for TCP packets only used when initiating a connection, or does it have other uses?

- Do you recommend that I deny TCP packets containing CWR, ECE flags?

- There is the "Activate SYN flood protection when the number of half-open connections reaches X" option. I'm curious about how this protection works... what exactly does CHX do if the number of half-open connections reaches X?

- I have both the "Allow Outgoing Passive FTP" and "Allow Outgoing Active FTP" boxes unchecked for my wireless interface. But I can still connect to my ISP's FTP server without a problem. Is this a bug, or am I misunderstanding those boxes?

 

Any device on your local segment will require ARP.

The SYN bit is also set in the syn-ack. That's about it.

Only if you have a specific need to do so(testing, debugging,etc).

Syn-cookies. Instead of allowing the OS to allocate stack resources (SYN-RECVD) the original SYN is discarded, and a SYN-ACK containing a "cookie" is sent. If an ACK arrives containing the cookie the session is re-established (transparent to both client and server).

It will depend on your static pf rules AND the type of ftp session. Outgoing Passive ftp will be functional unless you have explicit rules denying outgoing TCP traffic (both command and data channels are uni-directional).

Best Regards,

Stefan

 

But each computer will receive ARP packets only from the router, right? They will never receive legitimate ARP packets from any other computer?

So this must mean that if I have a filter for TCP packets with the SYN flag box checked and all other flag boxes unchecked, then that filter will only match SYN packets and not SYN-ACK packets, right?

So if I don't have explicit rules denying outgoing TCP, then outgoing passive FTP will work. And if I have explicit rules denying outgoing TCP, then outgoing passive FTP will not work. So what is the point of that "Allow Outgoing Passive Ftp" box?

Thanks again for your help, Stefan!

 

What happen to www.idrci.net? Is it down?

 

I now have another problem which I never had with CHX 2.8, I have to log in to an FTP where it uses active instead of passive and with CHX 3, it logs in but stops at the List command.