Sygate Question

[snowboard]

Ive been using Sygate Personal Firewall Pro for awhile and cant find an option to block ping/icmp attacks. Does anyone know a rule I can create so it will block them?

Regards,

snowboard

[CrazyM]

-{ Quote: "Ive been using Sygate Personal Firewall Pro for awhile and cant find an option to block ping/icmp attacks. Does anyone know a rule I can create so it will block them?" }-
Does Sygate not block this by default? Are you seeing ICMP permitted that you do not want?
You may need to check your application rules. Advanced rules could be created that would be applied before anything else.

Regards,

CrazyM

[Kerodo]

Sygate does indeed block icmp type 8 inbound, not sure about the other types though. To configure it yourself, you would just create advanced rule(s) yes.. I think the free Sygate has a rule limit, but there should be plenty of room for a few icmp rules.

I would allow 8 out, and perhaps 3 out to dns servers.
And I would allow 0, 3, 11 inbound.
Block all other icmp both directions.

[dholiday]

First off I'm on dial up, XP SP1, bandwidth 85-90 Kb (average), using Syagte Free 5.5 build 2710.
Are you seeing any outbound ICMP in your Traffic Log after a cold boot? I do, from svchost.exe, with XP. So I have svchost.exe blocked in the Application Rules.
If you block svchost in Application Rules then you must then create Advanced Rules for UDP services, like DNS, NTC, etc. which are child processes of svchost.exe. Broadband has other UDP services that must be allowed, which one(s), I don't know. Also make sure that under Applications, within the Advanced Rules tab, that you select svchost.exe for DNS, NTC, etc.
Depending on what software you run you may get by with blocking all ICMP, but some programs must use ICMP, mainly pinging utilites, like Ping Plotter, IMHO a "must have".
I don't know why you're being pinged that frequently. I never am, on dial up.
You can of course disable the ICMP protocol by going to the Advanced Rules window and create a global rule, which overides all application rules.
Final thought, deny every program in the Application Rules to "act as server". This may break some programs, depending on your apps, but if so then immediately check your Traffic Log for the block and then allow "act as server".
Hope this helps.

[Jaws]

Hi Snowboard,

The "correct" configuration of ICMP filters in a firewall is hotly debated. The problem is that ICMP are the "control messages" for TCP/IP. If you block some incoming ICMP, then you will break communication.

The absolute minimum ICMP traffic to allow is the packets dealing with TCP path MTU discovery. Fragmenting a stream is more efficient at the TCP layer rather than the IP layer, so the TCP layer will try to discover when IP packets are being inadvertently fragmented. They do this by setting the "DF" (Don't Fragment) on all outgoing packets. When a router cannot forward the packet because it is too big, rather than fragmenting it, it sends back a "fragmentation needed" ICMP packet (type=3/code=4). The TCP stack then starts sending smaller IP packets, segmenting the data at the TCP layer rather than allow routers to fragment at the IP layer. Therefore, firewalls must be configured to allow incoming ICMP type=3, code=4 packets.

Quoted from This (http://security.uoregon.edu/firewalls/firewall-seen.html) this web site. Alot of good info on this site.

Regards,

Jaws

[dholiday]

To Crazy M and Kerodo:
One can, with the Sygate build I'm using, in the Advanced Rules with ICMP selected, either permit or block basic, common ICMP traffic, in either direction, or both, but no sub codes. Falls way short of Kerio 2.15 and CHX-I. I'm still tempted to run Sygate and CHX-I in tandem, just for the stateful packet inspection of UDP and ICMP that CHX provides.

[Kerodo]

I don't think you can set icmp sub codes in Kerio 2. You can in others like Jetico for example.

CHX and Kerio make a great combo if you don't mind a little double filtering of browser traffic etc. But both are fast and you shouldn't notice any speed degradation. I have run both before with success and liked it..

I have also ran CHX with Sygate.

In both cases however (CHX/Sygate and CHX/Kerio), Kerio or Sygate will get the traffic first and filter it before CHX. Then, when you check the CHX logs, you will see an occasional packet blocked due to CHX's slightly stricter SPI.

[dholiday]

To Jaws:
You are absolutely correct. ICMP is the Net's "troubleshooter". However, with Sygate, I cannot allow it to be a "troubleshooter", as I can with the other programs mentioned above.

[Kerodo]

Speaking of Sygate, does anyone know what's up with Sygate Pro 5.6? I checked their forum and there's no posts on the beta for over a month now. And it looks like the current beta is 2-3 months old. But when you download it, it says it's good for 30 days.

Does anyone know if they have abandoned the home market completely? Or if there is any work being done on the Pro 5.6 at all? Not to mention there has been no comment on the age old loopback issue either.

[dholiday]

To Kerodo:
CHX-I's SIP wth Sygate for TCP, UDP, ICMP? All or just maybe ICMP and UDP?

[Kerodo]

Sygate has TCP SPI only, right? CHX has TCP SPI and also UDP and ICMP pseudo SPI. So I would think that CHX would complement Sygate a little. I did run both here so I know they can coexist ok. Sygate seemed to filter packets first, then CHX. Occasionally you would see a packet or two in the CHX logs that Sygate either missed or didn't handle as well as CHX.

[dholiday]

To Keredo,
Yes, TCP SPI only with Sygate, and all other software firewalls, except for CHX-I, as far as I can determine. Anyone know otherwise, please post with documentation.
Maybe Stephan will reply.

[Kerodo]

I can't post documentation (because I'm lazy :)), but many of the other firewalls have SPI or pseudo SPI for UDP also. A few examples are Kerio 4, Jetico, ZA, Outpost Pro, there are also more I'm sure. It is more common to have than to not have these days...

[dholiday]

I'm lazy too, lol.
I'm going to try Sygate with CHX's SPI for ICMP and UDP only, with all packet rules deleted. Have you tried this?

[Kerodo]

If you want simple for CHX, I'd try downloading the sample rule set on their web site, and then turn on SPI for TCP/UDP/ICMP (and logging) in Interface Properties. That will allow all outbound and only what SPI allows inbound. You can control outbound with Sygate's app control.

[snowboard]

Thanks everyone for your input but can someone tell me exactly (step-by-step) on how to block icmp by making a advanced rule.

Regards,

snowboard

[snowboard]

Does Outpost Firewall Pro has an option to block icmp/ping attacks? Or do you have too make a rule for that?

Regards,

snowboard

[Kerodo]

Snowboard - Outpost Pro has the option of turning on or off all the various icmp types without having to use rules. It's very simple.

Sorry, I can't give you a step-by-step for Sygate since I'm not running it now and don't remember all the options and so on.

[snowboard]

-{ Quote: "Snowboard - Outpost Pro has the option of turning on or off all the various icmp types without having to use rules. It's very simple.

Sorry, I can't give you a step-by-step for Sygate since I'm not running it now and don't remember all the options and so on." }-

Is Outpost Personal Firewall Pro better than Sygate Personal Firewall Pro?

Regards,

snowboard

[Kerodo]

That's a tough question. My vote would be yes..

[CrazyM]

-{ Quote: "Thanks everyone for your input but can someone tell me exactly (step-by-step) on how to block icmp by making a advanced rule." }-
You still have not mentioned if something is currently being permitted you do not want. Do you need an advanced rule at this point, or modification of one of you application rules?

Rules wizards are usually fairly intuitive and for Sygate should be something like:
Tools > Advanced Rules > Add > Deny Inbound > Ports and Protocols > ICMP

Regards,

CrazyM

[snowboard]

I need for someone to help me make a advanced rule for blocking icmp attacks.

Regards,

snowboard

[snowboard]

I just switched over to Outpost to try. And I see the ICMP settings, now what is a good way to set that up?

Regards,

snowboard

[Kerodo]

The defaults are pretty good. You might just go with that and see how it goes...

[snowboard]

-{ Quote: "The defaults are pretty good. You might just go with that and see how it goes..." }-

Is that the way you have it? Right now im on defaults.

Regards,

snowboard

[Kerodo]

I'm not running Outpost now, but that should be fine...

[snowboard]

-{ Quote: "I'm not running Outpost now, but that should be fine..." }-

ok :)

Regards,

snowboard

[dholiday]

To Snowboard:
"I need for someone to help me make a advanced rule for blocking icmp attacks."
Are we now talking about Outpost or Sygate?

[snowboard]

-{ Quote: "To Snowboard:
"I need for someone to help me make a advanced rule for blocking icmp attacks."
Are we now talking about Outpost or Sygate?" }-

Didnt you see my post that said..

-{ Quote: "I just switched over to Outpost to try. And I see the ICMP settings, now what is a good way to set that up?

Regards,

snowboard" }-

I only need help if someone has a better way to setup the ICMP settings on Outpost, than the default settings it already has.

Regards,

snowboard

[Kerodo]

The Outpost forum has some nice tips/faqs and helpful people there also.. If you like Outpost, you might try checking it out:

http://www.outpostfirewall.com/forum/

[snowboard]

-{ Quote: "The Outpost forum has some nice tips/faqs and helpful people there also.. If you like Outpost, you might try checking it out:

http://www.outpostfirewall.com/forum/" }-

Thanks ill look into this :)

Regards,

snowboard

[CrazyM]

You might also find this helpful:
http://www.outpostfirewall.com/guide/

Regards,

CrazyM

[snowboard]

-{ Quote: "You might also find this helpful:
http://www.outpostfirewall.com/guide/

Regards,

CrazyM" }-

Thanks ;)

Regards,

snowboard

[Tassie_Devils]

snowboard hi :)

This may/may not be of any use to you, but this is how I set up rules using Kerio PFW4 regarding ICMP with no illeffects.

Cheers, TAS

[dholiday]

-{ Quote: "If you want simple for CHX, I'd try downloading the sample rule set on their web site, and then turn on SPI for TCP/UDP/ICMP (and logging) in Interface Properties. That will allow all outbound and only what SPI allows inbound. You can control outbound with Sygate's app control." }-
Why do I need their sample rule set if I am just using CHX for a stricter SPI?
I am using it along side Sygate with no packet filter rules and with Interface Properties: Deny Incoming Fragments, Deny TCP Packets Containing CWR ECE Flags, and TCP, UDP, and ICMP SPI.

[Arup]

Hope Stefan clarifies this but for CHX, unless there are filters in place, the interface is not in effect, at least this is what I understand from the CHX help file.

[dholiday]

To Arup:
Thanks for the info. Maybe Stephan will set us straight. (IMO, a CHX forum is badly needed.)
In the meantime I have downloaded the sample rule set and have imported the file. I've also changed the Interface Properties, just allowing SPI for TCP, UDP, and ICMP.

[snowboard]

-{ Quote: "snowboard hi :)

This may/may not be of any use to you, but this is how I set up rules using Kerio PFW4 regarding ICMP with no illeffects.

Cheers, TAS" }-

I just made 0,3,11 coming inbound and 3,8 going outbound like yours. Thanks ;)

Regards,

snowboard

[dholiday]

-{ Quote: "I just made 0,3,11 coming inbound and 3,8 going outbound like yours. Thanks ;)

Regards,

snowboard" }-

I did likewise with Sygate in the Advanced Rules, and no "ill effects".

[Arup]

-{ Quote: "To Arup:
Thanks for the info. Maybe Stephan will set us straight. (IMO, a CHX forum is badly needed.)
In the meantime I have downloaded the sample rule set and have imported the file. I've also changed the Interface Properties, just allowing SPI for TCP, UDP, and ICMP." }-


dholiday,

What kind of activity do you see in your CHX logs? Also check out http://members.shaw.ca/bind-pe_and_ics/chxi.htm

Start with the basic 2.6 filters and then you can check out the newer TW ICS filters, there are certain things you can take out of them like the ICS and TW filters but otherwise, quite well written and also incorporates an effective Deny Trojan filter.

[Kerodo]

-{ Quote: "Why do I need their sample rule set if I am just using CHX for a stricter SPI?
I am using it along side Sygate with no packet filter rules and with Interface Properties: Deny Incoming Fragments, Deny TCP Packets Containing CWR ECE Flags, and TCP, UDP, and ICMP SPI." }-
Dholiday - With no rules, CHX does nothing. It allows all traffic in/out by default when there are no rules in place. I would recommend a good reading of the online documentation. It's worth the time spent to understand how CHX works...

[Jaws]

-{ Quote: "To Arup:
Thanks for the info. Maybe Stephan will set us straight. (IMO, a CHX forum is badly needed.)
" }-

Yes I agree, but people are so hung up on outbound app control and firewall leaktests that I don't think that will happen. But if you post your questions here their are people like Kerodo, Jazzie, Arup and Diver who are knowledgeable and can help you out.

As a matter of fact, IIRC, Phantom said he may write some rules when he's got time in a previous thread. In the mean time go with Arups suggestion and use some of the filters already out there and experiment. That's what I did and I'm by no means an expert in figuring out filters and rules for firewalls.

Regards,

Jaws

[dholiday]

-{ Quote: "dholiday,

What kind of activity do you see in your CHX logs? Also check out http://members.shaw.ca/bind-pe_and_ics/chxi.htm" }-

I had the logs turned off but have enabled them.
I have seen the link you provided, but don't know of how much help it would be to me as I no longer use Treewalk, and I am not on a LAN/ICS.

[dholiday]

-{ Quote: "Dholiday - With no rules, CHX does nothing. It allows all traffic in/out by default when there are no rules in place. I would recommend a good reading of the online documentation. It's worth the time spent to understand how CHX works..." }-
Thanks for clariying the need for rules.
I've read the documentation twice. Maybe I should read it more slowly. I'm not sure on some options, for instance "Deny All Incoming Packets" and "Deny TCP Packets Containing CWR ECE Flags".

[Stefan_R]

-{ Quote: "Thanks for clariying the need for rules.
I've read the documentation twice. Maybe I should read it more slowly. I'm not sure on some options, for instance "Deny All Incoming Packets" and "Deny TCP Packets Containing CWR ECE Flags"." }-


Perhaps the documentation is somewhat confusing and it needs some polishing.

TCP state options are applied on all traffic traversing the interface, regardless of the presence of static rules. So is the UDP&ICMP pseudo-state feature and IP frag analysis & CWR/ECE flags.

In the case of TCP state analysis sessions are always allowed to be created bi-directionally( by a SYN segment) and any subsequent segment that does not "belong" to a particular session is discarded.

In the case of UDP/ICMP pseudo-state the behavior is different since we must impose a "direction" with respect to each interface. Thus - only outgoing (on each interface) UDP/ICMP packets create "pseudo-sessions" and incoming packets are discarded if they do not have a match in their respective pseudo state tables.

Hope this clarifies things a little and apologies for the confusion the manual might have generated.

Best regards,

Stefan.

[dholiday]

-{ Quote: "Perhaps the documentation is somewhat confusing and it needs some polishing." }-

Docs confusing? Somewhat, yes. Using Kerio 2.15, where I learned how to write rules, "teaches". CHX-I demands much of a novice or even someone, like me, who has worked with Kerio for years.
But this reply is one of the clearest explanations you've provided, atleast for me. I thank you for the time you've spent replying to this question, and I'm sure other CHX-I users will second that.

[Arup]

Hi Stefan,

At the cost of being redundant, any dates for the new CHX 3?

[Kerodo]

-{ Quote: "Docs confusing? Somewhat, yes. Using Kerio 2.15, where I learned how to write rules, "teaches". CHX-I demands much of a novice or even someone, like me, who has worked with Kerio for years.
But this reply is one of the clearest explanations you've provided, atleast for me. I thank you for the time you've spent replying to this question, and I'm sure other CHX-I users will second that." }-
I am apparently wrong then.. Thanks to Stefan for clarifying about the SPI and rules, and my apologies dholiday for my incorrect statements. I was under the impression that rules needed to be present for SPI to be functional.

[dholiday]

-{ Quote: "dholiday,

What kind of activity do you see in your CHX logs?" }-
To Arup:
After several hours with CHX-I and Sygate running in tandem CHX-I is logging these:
Incoming - UDP - Out of Connection
Outgoing - TCP - Ack Fin - Out of Connection
Incoming - TCP - Ack Syn - Invalid Flags

[dholiday]

-{ Quote: "I am apparently wrong then... and my apologies dholiday for my incorrect statements." }-

No problem Kerodo. We are both learning, so mistakes can be expected.

[Kerodo]

-{ Quote: "To Arup:
After several hours with CHX-I and Sygate running in tandem CHX-I is logging these:
Incoming - UDP - Out of Connection
Outgoing - TCP - Ack Fin - Out of Connection
Incoming - TCP - Ack Syn - Invalid Flags" }-

I would say that the outgoing and incoming TCP with flags is normal enough (just CHX's stricter SPI), but the incoming UDP should not be seen in the CHX logs. Sygate should have blocked this. Perhaps CHX is getting the packets first on your system?? On mine, Sygate (and other firewalls) always got the incoming packets first before CHX, so I could view the CHX logs to see what the other firewall was missing. Perhaps this is not happening on your system though..

I have found though, that Sygate will allow packets thru to listening ports, sometimes without permission or asking. It's possible that you are seeing this also...

[CrazyM]

-{ Quote: "After several hours with CHX-I and Sygate running in tandem CHX-I is logging these:
Incoming - UDP - Out of Connection
Outgoing - TCP - Ack Fin - Out of Connection
Incoming - TCP - Ack Syn - Invalid Flags" }-
Without more detail, it is hard to say why you are seeing these.
You need to look at your connection history and the entire log entry: protocol, source/destination port/service, source/destination IP.
Was there a connection established by you to any of these IP's?
Were the incoming packets unsolicited, or just late packets (out of state/connection) being dropped by the SPI?

Regards,

CrazyM

[dholiday]

-{ Quote: "I have found though, that Sygate will allow packets thru to listening ports, sometimes without permission or asking. It's possible that you are seeing this also..." }-
You are correct. Sygate was allowing UDP scans on ports 1026 and 1027 to pass through, never asking for permission. I've implemented some changes in Sygate's "advanced rules" and am no longer seeing the packets in CHX's log. Without CHX running in tandem with Sygate this situation would not have been discovered. You're right too about Sygate fitering packets before CHX.
In case anyone is interested, here are some other packets being blocked by CHX:
Outgoing - TCP - Rst - Out of connection
Incoming - TCP - Ack Rst - Out of Connection
Incoming - TCP - Ack Pish Fin - Invalid Sequence no.

[CrazyM]

-{ Quote: "You are correct. Sygate was allowing UDP scans on ports 1026 and 1027 to pass through, never asking for permission. I've implemented some changes in Sygate's "advanced rules" and am no longer seeing the packets in CHX's log. Without CHX running in tandem with Sygate this situation would not have been discovered." }-
If these were unsolicited inbound UDP packets did you check your existing rules for anything that may have been permitting them?

Regards,

CrazyM

[dholiday]

-{ Quote: "Was there a connection established by you to any of these IP's? Were the incoming packets unsolicited, or just late packets (out of state/connection) being dropped by the SPI?

Regards,

CrazyM" }-
Regarding the UDP packets, no connection established by me, and the incoming packets were unsolicited. As far as the TCP packets, I agree with Kerodo, that CHX has stricter SPI, especially with the IP frag analysis & CWR/ECE flags.

[dholiday]

-{ Quote: "I've implemented some changes in Sygate's "advanced rules" and am no longer seeing the packets in CHX's log." }-
Not so. I am now seeing the same UDP packets (incoming to ports 1026, 1027) in both CHX and Sygate logs.

[dholiday]

-{ Quote: "If these were unsolicited inbound UDP packets did you check your existing rules for anything that may have been permitting them?

Regards,

CrazyM" }-
Yes, nothing. I only allow two UDP ports: 53 for DNS, and 123 for NTC. These are allowed in "advanced rules", and restricted to their specific IPs and ports.
The next UDP rule blocks all IPs and all applications, except for Automachron (which uses 123 for NTC), and blocks all ports except 53 and 123.

[CrazyM]

-{ Quote: "Yes, nothing. I only allow two UDP ports: 53 for DNS, and 123 for NTC. These are allowed in "advanced rules", and restricted to their specific IPs and ports.
The next UDP rule blocks all IPs and all applications, except for Automachron (which uses 123 for NTC), and blocks all ports except 53 and 123." }-
While the advanced rules should have priority over application rules, have you checked all you application rules to ensure the permit server (inbound) has been disabled?

[dholiday]

-{ Quote: "While the advanced rules should have priority over application rules, have you checked all you application rules to ensure the permit server (inbound) has been disabled?" }-
Only one program requires "act as server" - Automachron. I checked again and that is the only allowed to do so. I've removed the program from the applications and will see if that stops the incoming on 1026 and 1027. I doubt it.

[CrazyM]

-{ Quote: "Not so. I am now seeing the same UDP packets (incoming to ports 1026, 1027) in both CHX and Sygate logs." }-
Are they both logging the same events? Same source port/IP, same destination port/IP?

Regards,

CrazyM

[Kerodo]

-{ Quote: "Only one program requires "act as server" - Automachron. I checked again and that is the only allowed to do so. I've removed the program from the applications and will see if that stops the incoming on 1026 and 1027. I doubt it." }-
dh - I think you will find that one of the programs giving you problems is Sygate itself, or Smc.Exe. Sygate (Smc.exe) listens typically on port 1026 or 1027, in that range. And you will find that it let's random inbound UDP packets thru to it's own listening port. To stop this, you will need to find out exactly which port Sygate is listening on and then create an advanced rule to block UDP to that port from any address and then select Smc.Exe in the applications tab. Then block it inbound only. That will stop the packets coming in to one of those ports. The other one you will have to research and see what program or service is listening on that port.

I use a program called Active Ports to see what's listening on what port. If you run this, you should be able to find out. You'll see Sygate there (Smc) as one of them.

[djg05]

I was wondering if you install CHX-1 as is, would it log anything being missed by the f/w or do some rules have to be put in?

[Kerodo]

I don't have CHX-I installed right now, so I can't check or try it, but my understanding was that you would need some rules to do any meaningful blocking and hence logging. But since Stefan made his comments on the SPI being active even without rules, I'm not so sure. What I typically do is import my rules, turn on all SPI via the Interface Properties tab, and that's it. My best suggestion is to try it both ways and see what you get... :)

[Jaws]

Boy, did Snowboard and his/her question get hijacked or what!
LOL

[Kerodo]

Looks like the discussion has mutated beyond recognition.... ;D

[dholiday]

-{ Quote: "dh - I think you will find that one of the programs giving you problems is Sygate itself, or Smc.Exe. Sygate (Smc.exe) listens typically on port 1026 or 1027, in that range. And you will find that it let's random inbound UDP packets thru to it's own listening port." }-
Your are correct once again. See here:
http://www.issociate.de/board/post/209951/Sygate_listening.html

Read the last post in the thread, which says a lot. I'm back to just CHX-I and SSM.

-{ Quote: "I use a program called Active Ports to see what's listening on what port. If you run this, you should be able to find out. You'll see Sygate there (Smc) as one of them." }-
I use Active Ports also, a must have. IMHO.
Thanks everyone for your help.

[dholiday]

-{ Quote: "Looks like the discussion has mutated beyond recognition.... ;D" }-

Yes indeed, that is why we need a CHX forum, and why not here?

[Kerodo]

-{ Quote: "I'm back to just CHX-I and SSM.
" }-
A wise choice. :)

[dholiday]

-{ Quote: "I don't have CHX-I installed right now, so I can't check or try it, but my understanding was that you would need some rules to do any meaningful blocking and hence logging. But since Stefan made his comments on the SPI being active even without rules, I'm not so sure. What I typically do is import my rules, turn on all SPI via the Interface Properties tab, and that's it. My best suggestion is to try it both ways and see what you get... :)" }-

With no filters, meaning no rules, even with all of the SPI rules activated, you willl fail the GRC scan, you'll be wide open. Verify this by disabling all of your filters and then scan.

[Kerodo]

That is what I thought also.. If you just install CHX out of the box, it will do basically nothing...

[dholiday]

-{ Quote: "That is what I thought also.. If you just install CHX out of the box, it will do basically nothing..." }-
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.