Who wants another firewall?

Well, the more competition the better for us end users.

 

My feelings exactly! Sandboxing the malware should be the last line of defense, only coming into play if the user and/or security package was unable to prevent it from getting onto their system, then was unable to prevent it from executing. I'm convinced that the only way some people will ever put their focus on pre-empting or preventing an attack instead of trying to contain it is to put out a nasty rootkit and tell them that it's a new leaktest, then hold their system hostage for a week or so.

 

memory is cheap these days, and 64-bit systems have the capacity for more of it than any firewall or av should need. the problem is that firewalls and av's that use lots of memory and cpu also tend slow down the system more than their "lighter" counterparts, even when there's memory and cpu to spare... i mean all else equal, shouldn't a firewall that uses lots of resources (max outs and bottlenecks aside) perform its functions faster than a firewall that does the same job (same output) with lower input (resource) requirements? answer = yes in theory, but not in practice, presumably because high resource usage is directly proportional to inefficiencies in coding.

so yes, i want another firewall, or just an improvement in existing firewalls (and av's), to let the user choose to dedicate more resources to the program in return for faster performance (quicker boot times, quicker launching and running of programs).

 

392meg meory and no more slots, or 1 gig memory and no more slots (or pointless to add), 32 bit, and can't afford, or don't want to have anything over WinXP, a small FW such as fast and efficient Kerio is a lifesaver. Something consuming 30meg or 100meg is unacceptable. But the vendors on the bandwagon of leaktests aren't listening. You gotta have more features, says marketing. And more features. And more features, however they might be worded, to match the competition in whatever another buzzword is created to compete over.

@ Stem, noone_particular
No, an ideal, simple firewall will not make money, so this is all academic

Thank you guys for sensible teaching us/me!

 

That's how I view Sandboxie... the last line of defense. And like all last lines, it had better be a good one, which in this case, Sandboxie is.

 

Since I'm a total noob on firewall front
Where can I start to learn packet filtering?
And what firewall should I use to learn that?

Reading stem statement makes me eager to learn more

 

What is the name of the new firewall?

Thanks

 

Of course not. This wasn't the point. I was looking to see if there be a decent demand (academic or of any other nature) to justify a considerable amount of development effort. After all, a developer doesn't just create software for the love of writing beautiful code, right?

 

What kind of demand do you consider decent enough to justify pursuit of this endeavor?

 

At the top of the firewalls section is a post titled
"Useful Links and Recommended Threads."
In it are links to several learning threads. Many of these cover packet filtering rules for different firewalls, what they do and how they work. Several firewalls are covered.

 

Thx for the info, any firewall recommendation ? The one that I can use easly to learn packet filtering?

 

I'd say Kerio 2.1.5 is best for that, however, I don't know if it'd run/install/work on Win 7....

 

Agreed. I doubt that it'll work on Win 7 though. Is there anything even remotely similar that will?

 

I'm not sure this is the right forum to investigate this topic. I know that I would be interested in such an app, Stem and a couple of others maybe, but the rest are now "stealthted" behind home routers, so packet filtering is (sadly) of no interest to them. You would have to be a real enthusiast to embark upon such an endeavor.

EDIT:

How about something vastly superior than Kerio, such as L'n'S?
Anyway, I don't think installing an app is the right way to start learning packet filtering.

Cheers,

 

But what about things that move away from the safety of the home routers - laptops, notebooks, etc.

 

Not that I know of... to my mind, there is just nothing like Kerio 2.1.5. It's a classic.

 

I have to disagree. The user should start with reading up on the basics, the format of IP addresses, what the basic protocols are (TCP, UDP, ICMP), what ports are and what the commonly used ones are for (port 53 DNS, port 443 secure HTTP, etc) understanding that inbound and outbound aren't referring to data flow, but the direction from which the connection was established. After the user starts getting a grasp on the basics, there's no substitute for reading and interpreting a connection request, detemining exactly what it's for, and making a rule to either allow or deny it. Building a firewall ruleset from scratch gives the user the opportunity to see how it all works and can teach them more about their system and the basic functioning of the internet and local network than just reading about it. There's no substitute for hands on experience. Kerio's design makes it an excellent teaching firewall. I've never tried LnS so I have no idea what it's like. I stopped looking at other firewalls once I found Kerio. I have no plans to get Win-7 or Vista, so Kerio will fill my needs for as long as IPv4 is in use.

 

Would you elaborate a little on that?
When I view a FW rule on my pc, I see, for example:
SpywareBlaster.exe TCP OUT 80
I figured that meant the SpywareBlaster executable was connecting out via TCP protocol on port 80, but you're saying that a request from outside was received and granted, and that it signifies data flowing IN?
Man, I've got to rethink this whole scene.

 

If you quoted a rule, there ought to be some indication of whose port 80 - local or remote.
If you quoted a log, doesn't the log show direction? Should be outgoing. If it's incoming, start worrying.
If you use Kerio, watch the alerts and the log. It's a cool way to learn few things.
If the log or the rules are unclear, ditch that firewall.

Anyway, the line you quote is likely outgoing. This means SpywareBlaster was connecting to a SpywareBlaster download (or other) address and to their http port 80. They are not connecting to you. You connect from Local port, dynamically assigned by Windows, usually 1024-4999, others being suspicions. Once connected, the data flows to your computer on whatever port Windows designated in that 1024-4999 range. If you have a LAN, you may want to limit this range of ports to something higher, such as 1029-4999 to permit 1024-1028 just to be just for the LAN. At least that's how I understand it (or not).

"Connecting" - it's like on the phone. You call someone. You make the connection. Then the words between both parties flow, conversation goes both ways. Hope this helps some. Hope I'm correct

Take a look at the 4 pages by CrazyM about "Customizing firewall rules"
https://www.wilderssecurity.com/showthread.php?t=24415

 

As far as a firewall is concerned, traffic direction (inbound or outbound) is determined by where the connection request comes from. When it's your browser or another app on your PC, it's an outbound request. A connection request from the web or another PC is inbound. Think of it in terms of a door that's only opened from one side. Once it's open, data can flow in both directions, but it can only be opened from the side that the firewall rules allow.

What you describe is an outbound connection. The app on your PC initiated the connection. If the connection request came from their server to the Spyware Blaster app on your PC, that would be an inbound connection.

 

Haven't liked any since Kerio 2.1.5

Everyone keeps adding garbage that isnt needed in firewalls = bloat and not worth installing at all.

 

If you wish to learn how to create rules for common application-layer services, then personal firewall like Kerio is a nice learning tool. But if you wish to understand packet filtering (and leartn how to deal with various attack vectors), you would have to dig a bit deeper below this layer. It is nice to have control over ports and IPs for a given process, but a spoofed MAC address will bypass Kerio in a blink of an eye. Not much to learn there from our golden oldie, except the notion that we need a better firewall.

I believe this was referring to CHX payload filtering (based on user defined payload rules). I am unaware of any firewall that currently implements this feature (InJoy?)

 

Hi Seer,

Injoy does have payload filtering(or DPI, as it is described).

I did look at the payload filtering in CHX-i 3, but either I did not fully understand its implementation (I blame that on lack of information), or there where some bugs, as I was getting unpredictable results. As development had ceased on CHX, and there was no current discussions I could find on the subject, I gave up.

LnS does have limited payload filtering, limited in that you need to set actual locations(offsets) within the payload for checking, you cannot search a stream.


- Stem

 

Hi.

I haven't looked at it in years. Sad, but InJoy looks like another abandonware, it's still at v4.1. I see now they introduced a new licensing scheme, for a minute I thought the personal version would be free...

Yes, it was a new feature in v3, and I simply deduced that "it does not work yet". Then CHX died. Oh well.

That's nice, I thought you can offset fixed bits only. Not very practical way to do DPI though, but better than nothing. I am using LnS currently on one of my PCs, but did not yet find time (or will) to play with RAW rules plugin properly. Thanks for the headsup.

Cheers,

 

Rules for applications and services are a good place for one to start. For someone wanting to learn, digging below that to start would be an overload for them. Learn the basics, then move deeper, if the user is so inclined. You didn't start learning about Windows by first studying Kernel APIs, did you?

I disagree. What we need is a good firewall that doesn't suffer from "feature-itis" and the desire to make one app do everything, including wash your dishes. Controlling traffic on an application level still goes a long way towards protecting your system. I've always found it to be quite sufficient, especially with a separate HIPS to back it up and web content filtering to remove unwanted code from what is allowed. But something as simple as:
app A can connect out,
app B has no internet access,
app C can receive incoming from this IP address only,
All web apps can use this protocol on this port to this IP

These basics of traffic control are neglected in favor of leaktest results, which IMO assume that you've already failed to control traffic and process execution. Most of the new "features" in firewalls would be redundant if the basics were applied to start with.