FirewallLeaktester and Sunbelt Kerio Firewall

I've a LAN with several PCs all running Win2K (but several languages) and a Zyxel 2602H-63 ADSL modem/router.

I've installed Sunbelt KPF and would like to harden the system so first I run Shieldsup!! (all stealth)and also run the "Risk Audit" and "Basic Audit" of Securityspace.com (no real probelms) so I thought "let's try

formatting link
" to see if it passes those tests. SEVERAL of those tests show the firewall has NOT been configured well right out of the box. BEFORE I installed SKPF I ran those tests using Sygate (I've used that before) and that firewall did not pass several OTHER of those tests. Example : Sygate did pass the 1st leaktest (Leaktest) but NOT the 3rd (Firehole) test, while SKPF does NOT pass the

1st but DID pass the 3rd.

So my question, can anybody tell me how to set up SKPF in such a way it will pass the tests at

formatting link
. Of course PARTLY solutions that improve security are welcome as well

Reply to
JackRnl
Loading thread data ...

formatting link
"Stealthing" is nonsense.

You seem not to understand. You don't need "outbound control". It's just the next marketing nonsense.

AFAIK it's not possible. But: it's not necessary either.

Yours, Volker Birk

Reply to
Volker Birk

Just check out the test overview page at

formatting link
and push the "view results" button at the bottom to see how PFW's in general perform as far as outbound control is concerned.

Not possible. Not even in it's most recent version.

IMHO, for something to be considered a security meassure, it must be reliable to a certain (high) degree. The ability of PFW's to control outbound connections does'nt seem to meet that criteria.

Reply to
B. Nice

there's an interesting idea here..

formatting link
rules to restrict who svchost can contact.

If some other process makes an outgoing, you could see it in netstat , you could tell if it shouldn't be doing that.

Reply to
q_q_anonymous

This will not work.

Yours, VB.

Reply to
Volker Birk

I disagree, if I understand what "outbound control" is supposed to mean. For my outbound (and for the systems of others that I manage), I specify about bunch of allowed out bound destination ports, and log (or block) anything that isn't on my list.

Certainly blocking and logging any outbound netBIOS stuff is a good idea. I recommend it to others. Think of it as part of intrusion detection and limiting damage to the rest of the net from a compromise on your machine.

-j

Reply to
Jeffrey Goldberg

why?

Reply to
q_q_anonymous

Exactly that is very unlikely to happen. This requires very dumb malware, which is hacked by authors, who never have heard from a "Personal Firewall".

Yours, VB.

Reply to
Volker Birk

OK, to be more precise and to avoid misunderstandings: what are you exactly wanting to achieve?

The problems I'm seeing are:

  1. netstat makes no logging, it just gives you a snapshot. This is not enough to get into control

  1. blacklist filtering for svchost will not be enough, whitelist filtering cannot work without losing conncetivity

But: perhaps I'm too fast, and after you explained, I might change my mind.

Yours, VB.

Reply to
Volker Birk

blocking certain outgoing in such a way as to improve security. Specifically, restricting svchost.exe So that malware is limited to using other processes. if I see the client process mybrowser.exe with an established connection with some site i'm not browsing, then i've caught it. Similarly with myemailclient.exe . Especially if the window of the client process is closed!

a snapshot from time to time works 'cos malware tends not to run as a server for short periods. so netstat does pick it up. malware servers don't tend to stop every time I am about to run netstat. and there is netstat style software (TCPview, "active ports") that may not log and give date/time, but it monitors permanently, better than making a snapshot.

agreed

I don't see why.

the guy on that URL "says he" did it, Say you whitelist the whole microsoft.com range of ips (if that's even necessary). What else does svchost.exe need to contact for you not to lose connectivity? I'm sure it's a limited set and would not be an arbitrary ip each time.

thanks

Reply to
q_q_anonymous

Ah. I see the problem. I'm old fashioned, and for me firewall means network firewall instead of host-based (or personal) firewall. I haven't lurked here long enough to get used to the fact that people are mostly talking about personal firewalls (a term I wasn't familiar with until a few days ago). But reading back in this thread PFWs were what were being discussed.

Of course you're right. A PFW is pointless once the host has been compromised.

For network firewalls, however, controlling outbound traffic remains a very good idea.

Cheers,

-j

Reply to
Jeffrey Goldberg

From the discussion in "my" threat (thanks to all!) I understood the following a) I almost don't know anything about "security" and (of course) I should follow what people who do know much more about it conclude and suggest, but still keep asking myself questions "WHY is this or that such or so and is it needed"

b) c> >

c) PFWs do not handle it (well) for the moment, but when you discover several leaks in a boat you're in I think it is better to repair as many as possible (so maybe you're lucky to recah the shore) instead of doing nothing

d) My "feeling" tells me limiting svchost SHOULD catch a lot allthough not ALL probably. Defining a rule that blocks all actions that are not allowed and another rule defining all actions that ARE allowed and a 3rd one asking what to do for the others... should IMO make it possible in a reasonable amount of time to identify what to block and what to allow.

Maybe I think of it too easy, but why SHOULD I don't care about outbound connections if ways exist to exploit them?

Reply to
JackRnl

You don't have to. But it's not a bad idea.

Asking such questions is a good way to learn. And if you read some of the previous threads in this group the topic has been repeatedly debated. Read those debates, read also other sources (and I personally don't consider the web-sites of security software vendors to be reliable sources), be critical and form your own opinion.

Why do you want to block it instead of removing it?

Maybe it would be easier if you gave a specific example of something you would want to block.

Maybe it would have been better to check the boat before setting to sea :o)

BTW, a leaky personal firewall (as far as outbound is concerned) will normally not lead to "sinking" unless you stop "thinking".

Because, IMO only malware would make outbound connections you would need to stop. And malware is'nt something you should try to "control". It is something you should not run at all. And if you do, you should get rid of it a.s.a.p. (preferably by reverting to a known clean state

- not by using removal tools).

Reply to
B. Nice

Is this a misunderstanding or is this polemics? ;-)

This is one of the most common security lies.

People who don't understand security and are chosing the wrong (insecure) provisions like to tell you so when you're showing them that.

It often is a cat and mouse game, _because_ you have the wrong provisions.

If you're checking the traffic from an host with a network sniffer like Ethereal, then only an idiot or a layperson would run the sniffer on the host itself.

Please try to find out what svchost.exe is.

Yours, VB.

Reply to
Volker Birk

We're not talking about "controlling outbound" or something like that. We're talking about preventing a particular machine from communicating with other machines, for example. If you're implementing that in a sensible way, you can do that.

And we're talking about IDS, and that type of IDS, which is not compromized when an host is compromized.

Yours, VB.

Reply to
Volker Birk

I think the context has been lost here. I was talking abotu netstat on a compromised host.

what is like snake oil? I see 2 possibilities, both appear strange !

using netstat on a compromised host? or the malware?

I think the context there was using netstat on a compromised host. You weree saying what if they falsify netstat results.

seems to me like security is a cat and mouse game. There are new firewalls and servers , and exploits for them, patches for the exploits. Tom finds a way to attack, Jerry defends. Jerry finds a way to defend, Tom attacks. *cat and mouse* ! I would have said blackhat and whitehat but those aren't the right words.

I'm sure many network administrators would say that their system last year is not safe this year. So they stay up-to-date. Poor old Jerry.

not at all. If you find something suspicious, then you got it!!

If you don't find something suspicious, don't assume you're ok. You should do a better test - checking externally. Like I suppose checking from an OS router, But you need the equipment to do that, like a *nix based router. Only If you have that set up already then it's stupid to check from the host

if you have that set up, then you shouldn't sniff from the host in the first place.

Some windows services (prob in DLL form) use svchost.exe And based on that site I referenced, maybe it contacts windows update. If it contacts any old site then that is suspicious. And should be blocked. And one wouldn't "lose internet connectivity" for blocking it from doing so.

Right now i'm browsing the web. svchost.exe is not establishing any connection. It may listen, and if I use file and printer sharing then it may establish a connection with a computer ony my network. But it isn't establishing a connection with another machine on the internet.

Were you saying that to stop svchost.exe from establishing a connection with a machine on the internet I would lose internet connectivity? Or that by providing a whitelist for it, i'd not have a free internet?!, and it'd be like in China? I don't see what any of that has to do with svchost. If right now I blocked svchost from contacting anywhere on the internet, then I would most certainly not lose internet connectivity or lose my freedom!

All of the services are incoming , svchost listens, maybe it shouldn't be making outgoing anyway! Maybe I was wrong and all it does is receive incoming, and it can't be used to make an outgoing. In which case blocking it from making outgoing would do nothing. But you were saying it'd restrict me like chinese internet access, and you were saying i'd lose internet connectivity.

Reply to
q_q_anonymous

Trying to explain:

It is a big difference between provisions, which cannot work by concept, and between technical implementations of good concepts, which maybe have exploits.

The first cannot ever work, the latter will work until an exploit is being found - and not fixed.

Unfortunately, most of the technical implementations for provisions in IT security aren't implemented using proofed software, so exploits often are possible.

This is why "don't use software bloat, at least not for security provisions" is a good idea.

Oh, yes.

Just sniff with a second host.

No. Whitelist filterng for svchost.exe only for Microft's network could stop your conncetivity i.e. to other LAN hosts.

Yours, VB.

Reply to
Volker Birk

I discovered that at least SOME of the tests on FirewallLeahtester (including test-1 Leaktest by grc) can be discovered by changing the default rule of SKPF for "Network Security | Applications | "Any other application" to "ASK" for "Internet Out" instead of "permit"... Writing the event to the log also brings info of course. So THAT kind of outbound actions can be blocked... one less to go

Reply to
JackRnl

You're missing the point.

If you want to compare this with a cat and mouse game, then you should know:

- Tom (the "Personal Firewall") only wins, if he manages to control everything without missing one single hole.

- Jerry (the attacker) wins, if he manages to abuse anything, one single hole is enough.

The game isn't fair. And: did you ever watch Tom winning?

Yours, VB.

Reply to
Volker Birk

Why do "we" bother about peace in this world? Everybody knows throughout history SOMEWHERE in this world we've had war ALL the time. Does it mean we should not try to achieve peace??

I DO get your point we do NOT catch all FOR NOW (and maybe never), but if we won't try and investigate we will NEVER be able to. Even Icarus succeeded to a certain point but was beaten afterwards by the sun as he didn't take something into account. Nowadays we ARE able to fly, but not without efforts of people who DID try and learned it the hard way.

BTW I saw some outbound connections seem to be possible by using "unopened ports". I blocked outbound connections for SVChost and created rules for the applications that DO need it. I Also logged "Log packets going to unopened ports" and I see these are actually USED

[05/Aug/2006 10:49:05] "Network" action = 'permitted', descr = 'Unopened port', proto = 6, laddr = 192.168.1.99, raddr = 216.40.240.52, lport = 2130, rport = 80, direc = 'in', ruleId = 0, proc = 'N/A' [05/Aug/2006 10:49:05] "Network" action = 'denied', descr = 'Unopened port', proto = 6, laddr = 192.168.1.99, raddr = 216.40.240.52, lport = 2130, rport = 80, direc = 'out', ruleId = 0, proc = 'N/A' [05/Aug/2006 10:51:20] "Network" action = 'permitted', descr = 'Unopened port', proto = 6, laddr = 192.168.1.99, raddr = 81.93.166.200, lport = 2205, rport = 80, direc = 'in', ruleId = 0, proc = 'N/A' [05/Aug/2006 10:51:20] "Network" action = 'denied', descr = 'Unopened port', proto = 6, laddr = 192.168.1.99, raddr = 81.93.166.200, lport = 2205, rport = 80, direc = 'out', ruleId = 0, proc = 'N/A'

Allthough I don't know for SURE the rule blocking outbound connections for SVChost caused the "denied" (it has NOT been indicated in the log) I SEE the outbound connection has been denied.

Can't they go around? For sure, but NOT this way.

But I would like to know how to block incoming as well for unused ports without losing connectivity If I made mistakes in the router of my ADSL modem (Zyxel 2602H-63), or but doing something stupid in my SKPF, I would like to know what to do.

Reply to
JackRnl

Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.