The CHX-I Thread...

[Kerodo]

-{ Quote: "Yes, absolutely. With just one filter rule you're fully steath, but you won't know. Why? Because with "Allow-Deny All Except", say for just TCP, with no UDP rule, you will not have DNS lookups.
I think we need to put this thread to bed, and start a new one if anyone is interested in doing so." }-

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.

[Trespasser]

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?

[Kerodo]

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.

[Kerodo]

-{ Quote: "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). " }-
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. :)

[Jazzie1]

Hi all!

-{ Quote: "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)." }-

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

[Kerodo]

-{ Quote: " 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...

[Stefan_R]

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.

[Trespasser]

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.

[Jaws]

-{ Quote: "
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." }-
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 (http://lists.gpick.com/portlist/portlist.htm) 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

[Trespasser]

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

[Jaws]

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

[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

[Kerodo]

-{ Quote: "

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).
Regards,

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.

[Jaws]

-{ Quote: "I just created a rule in CHX to deny it and turned logging off. That way I don't see it in the logs all the time. " }-

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

[CrazyM]

-{ Quote: "Then I go to Dave's Port List (http://lists.gpick.com/portlist/portlist.htm) 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?" }-
My preference is to always try and keep rule sets simple. Define what you need, everything else is implicitly denied.

Regards,

CrazyM

[Rmus]

-{ Quote: "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. :)" }-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 8)

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

[Kerodo]

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

Regards,

CrazyM" }-
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...

[Jazzie1]

-{ Quote: "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

[Kerodo]

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

[Jaws]

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

[Jazzie1]

Hi all!

Jaws-
-{ Quote: "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?" }-

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

[Jaws]

-{ Quote: "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? " }-
-{ Quote: "Yes it does, but that is not my purpose. " }-
Hey Jazzie,

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

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

[Kerodo]

-{ Quote: "
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.

Regards,

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

[Jazzie1]

-{ Quote: "I should have known you can't teach an old dog new tricks." }-

Jaws-

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

Regards
Jazzie

[Jaws]

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 (http://www.antionline.com/showthread.php?s=&threadid=264811) 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

[Kerodo]

-{ Quote: "

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 (http://www.antionline.com/showthread.php?s=&threadid=264811) 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.
" }-

Jaws - If you're concerned about listening on port 445, you can disable it with the following registry entry:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NetBT\Parameters ]
"SmbDeviceEnabled"(DWORD)=0

Likewise, you can stop 135 with Gibson's little Dcom util. Just shut it down completely.

I have done the above along with other things and closed all my ports here. I am running no firewall right now for the past 10 days or so, with no harm to my system or any problems..

Running CHX-I is easier though.. :)

[Jaws]

-{ Quote: "Likewise, you can stop 135 with Gibson's little Dcom util. Just shut it down completely." }-
Kerodo, I did use Gibson's Dcom utility previously but port 135 was not shutdown, at least on my w2k machine. HERE'S (http://www.hsc.fr/ressources/breves/min_srv_res_win.en.html) another good read on services and ports and it states:

-{ Quote: "Disabling DCOM does not close TCP port 135. To close it, one solution is to remove IP-based RPC protocols sequences from the list that can be used by DCOM. In our case, the sequence ncacn_ip_tcp (transport on TCP/IP) can be removed. " }-
The Windows Worms Doors Cleaner from HERE (http://www.firewallleaktester.com/wwdc.htm) can disable or enable 5 different exploits without going into the registry. Neat little utility you might want to check out if you're still not running a firewall.

Regards,

Jaws

Double checked Gibson's site for Dcom, yes it does shut down Dcom but doesn't totally close port 135.

[Kerodo]

Jaws - I used the Gibson Dcom util and it did shut down 135 on my Win2k machine and stopped all listening on 135. Closed completely here. That's interesting that it doesn't work on yours.. Did you go to the 3rd tab (far right) and disable it?

When I check with Active Ports, I have absolutely nothing open or listening here... prior to running the Dcom util 135 is listening.

Thanks for the other links also.. will check them out.

[noway]

I disabled port 135 by doing the following:

1. Disable DCOM and remove default protocols
2. Disable the following services:
a. Task Scheduler
b. Messenger
c. Distributed Transaction Coordinator
3. Reboot

After doing this, you can also prevent access to dcomcnfg.exe using Group Policy Editor if you want

If you need another Task Scheduler there is 3rd party software available which doesn't open port 135 such as System Scheduler http://www.splinterware.com/download/index.htm

Even if the ports are all closed and I wasn't worried about "stealthing" my computer (I'm not) I still like to use a firewall since the logging helps me to monitor (for interest sake) the type of traffic knocking on the door...an analogy for me: it's like the difference between having or not having a peep hole in your outside door or a video camera pointed at the door recording everything.

[Jaws]

-{ Quote: "Did you go to the 3rd tab (far right) and disable it? " }-
Yes I did, CHX's ANP page was still showing port 135 listening for me... strange.

-{ Quote: "If you need another Task Scheduler there is 3rd party software available which doesn't open port 135 such as System Scheduler " }-
About the only thing that would stop someone from shutting down 135 would be the task scheduler. I figured somebody would come up with another program as a replacement. Thanks noway.

[Kerodo]

-{ Quote: "Yes I did, CHX's ANP page was still showing port 135 listening for me... strange.


" }-
I also had all the services Noway mentioned disabled too, so perhaps that made a difference? Not sure.

I am currently clean here with nothing open/listening. However, if I did have something listening, I would surely use CHX then.

[Kerodo]

-{ Quote: "
If you need another Task Scheduler there is 3rd party software available which doesn't open port 135 such as System Scheduler http://www.splinterware.com/download/index.htm
" }-
Thanks Noway, that's a nice one to have around...

-{ Quote: "
Even if the ports are all closed and I wasn't worried about "stealthing" my computer (I'm not) I still like to use a firewall since the logging helps me to monitor (for interest sake) the type of traffic knocking on the door...an analogy for me: it's like the difference between having or not having a peep hole in your outside door or a video camera pointed at the door recording everything." }-
I used to like seeing what was going on too, however, after years of the same thing, I finally got tired of paying attention to it. All I ever got here was a few random TCP probes and mostly a bunch of UDP to ports 1026-1029. Same old stuff.

Without any firewall, I figure if someone succeeds in messing with my machine and bringing it down somehow, then I'll know or find out when it happens.. :) So far, no problems though..

[Kerodo]

Here is another interesting and related link if anyone's interested:

http://www.ntsvcfg.de/ntsvcfg_eng.html

[Jaws]

-{ Quote: "Here is another interesting and related link if anyone's interested" }-
Hi All,

Of course I'm interested, thanks. Not that I absolutely understand everything I read 100%, but I try to muddle though the best I can. Reread three of four times helps somewhat.

If it wasn't for the help I get here and at other forums I'd still be in the dark ages. That's why I try to post links for others to check out.

As a matter of fact I didn't know about that utility program I posted until I googled for port 445 which took me to one of the links that had a link to it, if you know what I mean. For me it was new but perhaps most people already knew about it. Oh, and all the free utilities and programs people post are very much appreciated, thanks.

Anyway, time for some vodka - tonic with a twist & a BBQ. Have a great weekend all.

Jaws

[Rmus]

-{ Quote: "I disabled port 135 by doing the following:" }-Just curious: Arup and others have suggested I check out CHX, so I've been interested in these threads. I realize CHX is not a regular firewall, but isn't there a way to block inbound traffic through these ports besides going to all of that trouble to disable the services, etc?

thanks,

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

[Kerodo]

CHX-I will indeed block anything and everything inbound, without the need to mess with closing ports or anything else. The only thing different about CHX-I is that it offers no traditional outbound app control.

I would suggest reading the online documentation for an understanding of how CHX rules work, and then perhaps start with the sample rule set from their web site, and modify it as needed. There are also other rule sets available. See the other CHX threads for those.

[Rmus]

-{ Quote: "CHX-I will indeed block anything and everything inbound, without the need to mess with closing ports or anything else." }-So, why all the concern in this thread about using other utilities?

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

[noway]

-{ Quote: "So, why all the concern in this thread about using other utilities?" }-

Sometimes threads tend to waver a bit from the main topic, that's all. Whether or not you decide to use CHX-I or another firewall (or no firewall) it is a good idea to close as many ports as possible. Open ports can represent processes that use memory and may not be needed. Also, if you take the trouble to close the ports, risks will be minimized IF the firewall crashes or you decide to disable or uninstall it. Now, getting back to CHX-I.....

[Kerodo]

-{ Quote: "So, why all the concern in this thread about using other utilities?

-rich
________________
~~Be ALERT!!! ~~" }-
As Noway says, we sometimes get sidetracked... ;)

[Jaws]

-{ Quote: "So, why all the concern in this thread about using other utilities?" }-
Hi Rich,

Sorry about getting sidetracked. Curiosity got the better of me, but no paranoia really. CHX is up to the job of protecting inbound, so no worries here.

As a matter of fact, CHX is blocking stuff that my router is letting through. I've got about 35 blocked connections in the past 4 days for various reasons in the CHX logs.

Mostly, Invalid Flags, Out of Connection and Does not Match Allow Policy which are self explanatory, but two of the reasons I'm not sure what they mean:

Invalid Acknowledge no. and Invalid sequence no. ?? I guess I'll be googling again.

By the way, here's two sites with explanations of flags in TCP headers if anyone cares:

http://www.firewall.cx/tcp-analysis-section-4.php

http://www.zone-h.org/files/29/tcpflags.txt

Regards,

Jaws

[Rmus]

-{ Quote: "Hi Rich,

Sorry about getting sidetracked. Curiosity got the better of me, but no paranoia really. CHX is up to the job of protecting inbound, so no worries here." }-So, why are people using CHX also closing ports by other means? Posts #26 - 29 for example?

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

[Jaws]

-{ Quote: "So, why are people using CHX also closing ports by other means? Posts #26 - 29 for example? " }-
Because as Kerodo stated in post #26:
-{ Quote: "I have done the above along with other things and closed all my ports here. I am running no firewall right now for the past 10 days or so" }-
and noway's reasoning is stated in post #38:
-{ Quote: "it is a good idea to close as many ports as possible. Open ports can represent processes that use memory and may not be needed. Also, if you take the trouble to close the ports, risks will be minimized IF the firewall crashes or you decide to disable or uninstall it." }-

[Rmus]

-{ Quote: "Because as Kerodo stated in post #26:

and noway's reasoning is stated in post #38:" }-OK, thanks!

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