ports stealthed in Kerio 2.15

Hi !

still no find out how to stealth ports in Kerio... can you give a clue? downloaded manual from kerios website

just ran an online scanning test... they said "ports closed - non stealthed"

non-stealthed: 123, 146, 623, 901, 902, 903, 1243, 1560, 2001, 2002, 2800, 3000, 3700, 5151, 6776, 7000, 7410, 9696, 10100, 10528, 11051, 12345, 12346, 12348, 12349, 15094, 17569, 20034, 25685, 25686, 27374, 31337, 34763, 35000.
... PCFlank

tkz

 

Its either Your Rules, the test is giving false results, or its scanning a different device. Do you fully understand what your rules allow, and how your networked?

From that many ports it appears you have made a huge hole in your firewall rules, or they are scanning the wrong target aka not your computer.

 

in this connection our ISP gave us a private ip 10.x.x.x then we have a router managing LAN connection, of course 192.168.1.x

can you give an example of "good security rules" in kerio, plz? or at least the most common related

using> KPF 2.15, Mozilla 1.4, NAV 2001, Spywareblaster, MRU Blaster, SpywareGuard, SpyBot S&D, TDS3.

OS: Win98SE, i hate this one but need it for compatibily reason. we have a software that use a sockcaps app

 

You want rules for Kerio? Well, BZ is an excellent source. You might want to check out his recent thread in the Tiny-Kerio forum at DSLR. BZ's thread is at http://www.dslreports.com/forum/remark,8023708~root=kerio~mode=flat and the general entry point to that Forum is at http://www.dslreports.com/forum/145

Read through BZ's entire thread over there; you'll find lots of explanations and elaborations by others for special cases. (And, besides, BZ has made it very clear how he'd like to handle follow-up queries on additional issues within the thread itself.)

Then, at least browse through some of the other threads pertinent to KPF 2.15.

As for Win 98 SE, I'm running that myself at the moment with Kerio 2.15. For the most part, you're going to find more authoritative advice in that Forum than you can get from me. Still, if you've got additional issues after working through that mass of information, don't hesitate to ask -- both there and here.

 

Okay, that helps a bit in elaborating upon BZ's original comment. Your ISP has effectively placed you on a private IP address space (e.g., 10.x.x.x), and then (by using a router yourself), you've put yourself on a second private IP address space (192.168.y.y).

BZ's point is that it's incorrect to automatically assume that the test results from PCFlank necessarily indicate a problem with your software firewall. You need to do a bit more investigative work before you can reach that conclusion.

And there are lots of possibilities.

• For some reason, PCFlank may not be actually scanning these ports at all; it may just be reporting 'results' for tests that really aren't getting run. Yes, this has happened happened sporadically with any numer of well-known sites. It's usually quite sporadic and typically gets fixed within a matter of days, at most.
• As BlitzenZeus mentions, there is also a possibility that the test site really isn't probing your machine at all. A problem I've found with some sites is that they end up probing the caching web server that my ISP uses for popular sites (and PCFlank could certainly fall into this category)
• Your ISP may be blocking certain ports (or 'blackholing them, but that's a bit rare). And many ISPs do this routinely, but the list is generally a lot shorter than what you're describing here (too much overhead for long lists, especially on an ISP with lots of subscribers.) This could be happening at your ISP's Internet gateway or somewhere in the chain of 10.x.x.x routers between you and that gateway. My ISP apparently did this at one time, checking for specific IDS signatures that it had flagged.
• For that matter, the problem could be happening on that router you've used to then define your 192.168.y.y subnet (especially if you're not all that positive about exactly how it's configured.
• Finally, and I've probably overlooked a couple of other possibilities, there could be a problem with how your software firewall is configured on the machine from which you ran the tests.

Now, that's a lot of possible answers and checking them all out can be done in various ways.

You're generally going to have to consider the first three options by exclusion. You probably don't have access to your ISP's logs, so you're going to need to take a look at the logs on that router that you used to define the 192.168.y.y subnet.

• If you see no PC Flank probes in that log when you run the test, that's a pretty good indication that they're actually probing another IP address other than your own -- probably a web caching server used by your ISP.
• If you can see some probing by PCFlank, but not for these specific ports, that may well indicate that, for some reason, that your ISP is blocking some of these ports upstream from you
• Still, it's very hard to differentiate between the first and third options I've indicated and I'm going to defer going into that at the moment.

I'm going to have to come back to analyzing the fourth and fifth options a bit later. (I've got a dog that wants to take me for a walk, at the moment. )

But the logs are all-important in resolving this issue. By that, I mean both your local router logs and your software firewall logs. You need to have access to both and you need to confirm that they're set up properly so that you can do this and this is not always as simple as it may sound.

Back later. Nature calls.

 

JVMorris has already explained it, and if your interent provider gives you a 10.x ip address that means you don't really know what your external ip even is. You are routed through at least two separate networks, and any one of them could be doing it. A really simple test is pick one of those ports reported closed at random, and make a rule to block it inbound with logging. If you run, the same test, and it doesn't log, its completely out of your control. PC Flank has given false readings many times before, its publicly known, and I have also seen those false results so I don't trust it as a scanner anymore.

A closed response is as good, if not better than being stealth. In all reality stealth is snake oil, but so many care about it these days its almost pointless even explaining it to people who won't care. Even most software firewalls are 'stealth', and many of those use terms like 'attack' when they are just blocking normal traffic.

As JVMorris pointed out I have a thread where I made a default replacement ruleset, but its only a starter template which covers some basic configurations. There are many FAQs out there, and there are many different styles of setting up rule based firewalls so learning what your rules permit/block along with knowing that the order of your rules is very important are some things you need to understand.

 

Yep, that's a good simple test and an excellent illustration of my rather quick comment that there are alternative ways to do this. I would just make a couple of suggestions:

• Pick one of the more obscure ports previously detected.
• Move the rule to the top of the rules list and make sure it's enabled.
• And it really wouldn't be a bad idea to specify the remote IP addresses of the testing site(s) you intend to use -- just in case.

BZ, I'm assuming here that even the latest versions of KPF 4.x don't have the equivalent of the old AG "IGNORE" rule action that would allow for passive monitoring?

Yes, I've had that experience myself. But, in all fairness, I've also had it happen on GRC and there's currently a report on DSLR Security about a guy with this problem on the Symantec test site. For that matter, I've had this problem on Zhen-Xjell nMAP scans which were constantly getting directed off to the caching proxy server used by my ISP.

In this context, Randy Bell made a good point over there: Run a whole slew of scans on different test sites (I think Randy routinely lists about ten); if this only happens on one site, then it's most likely some sort of anomaly in your specific connection to that test site.

Then, you can add the more extensive investigation of what the precise problem is to your "Things to Do When There's Nothing to Do" list.

And thanks, also, for re-emphasizing that in your own words! That dog was drivin' me nuts yesterday when I was composing my response.

 

thank you !!
iam learning a lot with your reply. i really apreciate it

tell you later how is it going...

cya my good friends !!

 

KPF 4.0 Pcflank

Packet' type Status
TCP "ping" stealthed
TCP NULL stealthed
TCP FIN stealthed
TCP XMAS stealthed
UDP stealthed

 

Even Tiny/Kerio 2x didn't have this feature, and as were both old AtGaurd users you know I have missed that feature. However I wasn't willing to run Norton, and you already know most of my opinions of Norton.

4x has problems logging packets to non-listening ports, and even if you enabled the internet gateway setting it still doesn't make the traffic flow freely like it should. They finally fixed a huge issue(after being reported multiple times, and not being fixed over many revisions) of rules blocking ports with no attached application were not logging, or alerting so you also couldn't tell if they were even working correctly. So overwall if you wanted to log inbound packets to tcp 80, but didn't have any program listening on that port, it would never log any traffic even if you were being bombarded by tcp 80 packets unless the IDS logged it.

Snort may have been a good product, but the IDS in Kerio 4x is horrible. You can't edit/delete/add IDS rules through the GUI, and you can only allow or deny a group of IDS rules which is a horrible concept. I have it disabled as it caused problems with my configuration in 4x, and I wasn't willing to allow that block of ids rules inbound.

I currently don't see Kerio 4x as a serious security product, you may try it one day if you like, but overall from the way the program has ran, along with problems in development not being resolved I can't really suggest anyone use it to protect their computer.