The CHX-I Thread...

All I did was use the sample rules from the CHX web site to start with. Just 2 rules covered everything. I believe the sample rules covered both TCP and UDP in one rule. Also turned on SPI for TCP/UDP/ICMP with logging. This allowed all outbound traffic and inbound only what SPI would accept.

Then I created a couple of force allow rules to accomodate my DHCP servers. I have a situation where I have 2 DHCP servers. The outgoing request goes out to one server, but the response comes back from another server. So I need a force allow rule for that response.

 

I deleted the single UDP&TCP with SYN on rule in favor of a separate TCP In Syn on and UDP In Force Allow rule so that I might specify/control my DNS Server under UDP (the single UDP&TCP would not allow for this). I have been test-driving 3.0 beta for a couple of weeks and like it. It's a bit different than 2.82 but rules creation is pretty much the same (there are some added features).

On a side note, in the email I received from Stephan with the link to 3.0 beta he mentioned that 3.0 was suppose to be offically released July 1st. Any news on that anyone?

 

I have not heard anything on a release date for 3.0 yet, but perhaps it's soon. I know that it has been in testing for quite some time now. I tried it out a month ago or so and liked it a lot. I am hoping Stefan doesn't rush to release it and keeps the quality up there as it's always been in 2.82 and prior. I would prefer to wait for the best results if necessary.

 

Yep, you can always do that. I opted for simplicity in my own case. But it's possible to add rules to control inbound and outbound traffic and get as detailed as you want.

 

Hi all!

I also had a problem with that rule for my router DNS. Instead of deleating the rule, I made into a DNS rule only (DNS UDP&TCP_NO_SYN(Stateful ON) and changed the source port to 53. And made seperate rules for UDP &TCP responses.. Works quite well!!

I just received the newest beta 3 yesterday, so I think there are still some issues that need to be ironed out before final release. It has been really stable, from what I could tell. The only thing I found was when deleating logs, that when new loggings populate, it shows the number of the logs with no info. Untill, you change to a different tab and back again... Which really isn't a bug or issue, just a cosmetic occurance. A truely great firewall..

Regards
Jazzie

 

Hi Jazzie - I totally agree on that. In fact, 2.82 is the only firewall I can think of that doesn't have any bugs or problems (as far as I can see). My favorite.. I am sure 3.0 will be the same...

 

One must be careful when using Force Allow within the context of UDP/ICMP pseudo-state. As you know - a force allow trumps the UDP/ICMP pseudo-state analysis so anyone can spoof UDP source port 53 with relative ease. Furthermore, even if you lock the source port 53 to your DNS servers it becomes a false sense of security since any attacker with a bit of wit can find out what they are and spoof the source IP as well. With UDP/ICMP - crafted packets can make their way into "userland" if one is not careful.

In other words - try to stay away from force allows with udp/icmp stuff. In 3.0 we have the conditional filters (dynamically allow certain "streams" based on already available info in the state/pseudo-state tables). Make use of this feature whenever possible or use payload to pf triggers (activate dormant pf filters upon a TCP/UDP/ICMP payload event).


Best Regards,

Stefan.

 

Thanks, Stefan_R, for your response. Much appreciated. The reason I used the Force Allow for UDP In for my DNS Server is the guidance you offered in the 751 kb Help file>Nota Bene>rules of thumb when creating packet filter policy>

3. If the UDP "pseudo-stateful" option is enabled a Force Allow must be used when running UDP servers (e.g. DNS).

Also, any info on the release of version 3.0? And thanks for a great firewall.

 

Kerodo, I have since went with the two filters for workstations in CHX. Had no problems getting on the internet and all ports stealthed at GRC.

As far as DHCP, if you have SPI on for all three protocols, why do you have to create extra filters since your request goes out from CHX? That's what I thought SPI was for ( it will let a response in from what was requested out). One other thing, the BIND_PE_Filters do have an allow DHCP broadcast filter, couldn't you use that?

Talking about the BIND_PE_Filters, for the hell of it I imported those filters but deleted all but the spoofed filters and deny TCP and deny trojans. Then I go to Dave's Port List and do a defined port list in CHX with all the trojan ports from 1024 to 5000 and use the list in the DENY TROJANS filter for TCP and UDP. OK, be brutally honest, did I just waste my time and I'm blowing smoke or should I get a life and just delete that filter?

Regards,

Jaws

 

I thought that the 1024-5000 allowed ports are for TCP only while UDP requires a far wider range. I also have a Deny Trojan list as well but I only apply TCP to it. I suppose one should have a UDP Deny Trojan list. Please, correct me if I'm wrong.

 

Hi Trespasser,

If you check out Dave's port list some of them are also on the UDP ports. I really don't know, that's why I asked.

Regards,

Jaws

 

Trespasser, there are about 20 UDP trojan ports in that list. You know what, my browser seemed to open pages slower, I opened the log file and noticed that my DNS servers wanted to connect to 2555. One of the ports I blocked even though it's only a TCP trojan port.

I now made a UDP trojan list with only the UDP ports that are in that list and created a new filter for UDP trojan ports and everything is back to fast browsing.

Jaws

 

I should have modified my comments a little. Here's what happens. Normally, my dhcp works fine. Request goes out to 172.x.x.x and returns from same address. But when I do a manual ipconfig /release and then ipconfig /renew, the request goes out to 172.x.x.x BUT the response back comes from a different server in the 10.x.x.x range. Hence, if I want things to work when I manually release and renew my dhcp lease, I need that extra rule.

 

Kerodo, I'll just post this in the CHX thread to keep it going. About logging...good idea.

I disabled logging in each of the spoofed filters only and in has quieted the logs down a lot.

Thanks,

Jaws

 

My preference is to always try and keep rule sets simple. Define what you need, everything else is implicitly denied.

Regards,

CrazyM

 

Does it have to be so complicated?

If you have permission rules for your inbound ports/addresses, and then put a Deny-All-Other-Protocol Rule as the final rule, you've covered everything

-rich
________________
~~Be ALERT!!! ~~

 

This is exactly my feeling also. Keep the rule set as simple and uncluttered as possible.

However, I am thinking that his Deny Trojans rule is related to outbound traffic perhaps? If so, you could either specify specific ports to deny outbound and allow all others OR specify the ones you want to allow outbound and have CHX deny all others. Or am I full of hot air? I don't have it installed right now, so I can't go look...

 

Hi Kerodo! The sample ruleset at IDRCI is sufficient enough for Workstations (or even some servers) that don't need inbound (outbound) connections. I myself, modified the 'Allow UDP&TCP_NO_SYN(Stateful ON)' rule: (which allows ALL traffic outbound from local ports 1024-5000.) for each connection state that I needed, such as HTTP-HTTPS-FTP-POP3-SMTP, ect.ect.. and use the 'block spoof' rule since I am behind a LAN. I sometimes also use a block Netbios rule inbound and outbound and block broadcast attempts. All in all, I believe I have ten rules total. But rule of thumb is, if there is no rule for a connection, it is droped/rejected. Which is good for either creating a rule that is needed or seeing exactly what is not needed and blocked. So, that is my reason for breaking down the Allow all UDP & TCP with no SYN flags...

Regards
Jazzie

 

Jazzie - That sounds similar to what I did with 8Signs.. Worked out well. But when I went to CHX-I, I just decided not to limit my outbound stuff at all and allow everything. Seems easier for me that way. Once in a while you get those odd/weird browser ports happening and there's no way to know except if something doesn't work or you check the logs.

At any rate, sounds good...

 

Hi All,
I started writing this last night but went to bed and never posted it so I'll just let it run on.

CrazyM,
Yea, I think I was coming to that realization, but I needed someone to tell me it was so. For a workstation PC, just the two filters seem to work quite well, especially when you see all the logs pile up with blocked connections.
I imagine using CHX's SPI with a router that doesn't do SPI would be a good combo too.

Rich,
I think with CHX you don't even have to do that, because allow rules are prohibitive, anything not specified in the allow rules are automatically dropped.

Kerodo,
I think the deny trojan rule is a waste of time. Someone correct me if I'm wrong but wouldn't the trojan just call out on a commonly used port (80). I'm thinking ( I know, what did I tell you about thinking ) that the trojan rule is more for servers.

Jazzie,
Just this morning I've hooked up my router again after testing CHX by itself. As I thought would happen CHX's logs are empty.

Since I'm on the 10.10.10.0 private address with my router, you're saying it would be a good idea to create a block spoofed rule for the 10.10.10.0 range of addresses? That sound logical, so I may keep CHX on my PC, but CHX will definitely be going on a friends PC when I get over there.
Also doesn't the *Disable NetBIOS over TCP/IP* in the Local Area Connection Properties > IP Protocol > Properties > Advanced > WINS tab accomplish what you do with the rule for netbios?

Another reason CHX may stay on my PC with my router is the Active Network Processes page. Has a lot more info then TCPView and doesn't refresh automatically so you have more time to examine what's going on. Plus you can check the logs to see if your router is letting anything pass. Also there is no slow down in browsing with both.

Regards,

Jaws

 

Hi all!

Jaws-

Yes it does, but that is not my purpose. Since I do have a small LAN. I want to sometimes (dis-allow) other users access to my system by just enabling the rule. Sure I can also remove the admin$ or C$ shares, but no need. I only use that rule seldomly. But the anti-spoof (ingres) filters are great, plus now we have ARP to deal with. Which, if it wasn't for my finicky router, I would use. Since my router wants ARP rules to and from the router and NIC, it is exactly the same as allowing all ARP (well just about!)

Regards
Jazzie

 

Hey Jazzie,

I should have known you can't teach an old dog new tricks.

Maybe some of our slightly less knowledgeable brothers & sisters can use this info to easily disable netbios if they don't need it.

Regards,

Jaws

 

Jaws - I have to agree. I never bother with the trojan rules myself. I have seen others use them though.

 

Jaws-

Show me a 'new trick' and I will decide if it is worth learning or not!!!

Regards
Jazzie

 

Hi All,

CHX is a really neat packet filter that also has great logging and the Active Network Processes (ANP) page. The ANP page gives you a lot of info and doesn't refresh automatically, so you can view what's going on at your leisure.

One of the things that concerned me on the ANP page , especially when you hear about threats of a port 445 attack, was ports 135 and 445 were always listening. I did a google search for port 445, which brought me to this tutorial on services and listening ports. It's a good read and there's a handy little program at the bottom of the first post [11] if you're not comfortable going into the registry and changing things.

For the most part this is for a standalone PC so take the necessary precautions. Of course, with all the ports stealthed with CHX, I think it's more of an annoyance then a problem anyway. The standard - backup your registry first before you mess with it - is always a good idea.

Regards,

Jaws