how-to block ads
|
|
Uniqs:
8306 |
Share Topic
 |
 |
|
 gt7697cPremium
join:2001-02-16
The Hive | reply to ghost16825
Re: [Kerio 2.x] Kerio 2.2 Features (request) I don't see how naming your firewall "Ghost Firewall" is in violation of anything to do with Symantec's Ghost. The two products do very different things. If they did like functions then I could see where a problem would be, but they wouldn't be similar. I can see if you named your product "Ghost" without qualifying it with "Firewall" that Symantec might get their Panties in a knot.:D
As to suggestions, I am not sure if this has been mentioned, if it has please forgive, improving the Custom IP Group in relation to the filter rules. Meaning the ability to have different Custom IP Groups do different things in relation to filter rules.
More suggestions:
1. Make the firewall logs compatible with Log Viewer by Sven Schaefer. Or anything other than Tiny Logger.
2. Rule displaying and exporting. If you are familiar with AtGuard and the early versions of NIS, then you are familiar with "Rules Viewer" by Albert Janssen. It would be nice if one could use this utility with the firewall you are improving, or maybe a like utility. The utility would/could output the rules the way they are processed by the Firewall, and maybe also output the way they are displayed to the user.
3. You may want to add some sort of built in support for proxy filtering software like Proxo.
4. Have some sort of organizational pattern for the rules that the firewall displays to the user. Rather than no organizational pattern at all. This does not mean that the firewall processes the rules in the order displayed.
Will this improved firewall be free, or paid?
--
Just my 2 bits. | |
Steve_M
join:2004-09-14
Schenectady, NY | said by gt7697c:Will this improved firewall be free, or paid? It's open source software. See »sourceforge.net/projects/kerio/ | |
| reply to gt7697c
said by gt7697c:I don't see how naming your firewall "Ghost Firewall" is in violation of anything to do with Symantec's Ghost. The two products do very different things. If they did like functions then I could see where a problem would be, but they wouldn't be similar. I can see if you named your product "Ghost" without qualifying it with "Firewall" that Symantec might get their Panties in a knot.:D You may be right, but why push it? It is just asking for trouble and confusion.
said by gt7697c:More suggestions: 1. Make the firewall logs compatible with Log Viewer by Sven Schaefer. Or anything other than Tiny Logger. 2. Rule displaying and exporting. If you are familiar with AtGuard and the early versions of NIS, then you are familiar with "Rules Viewer" by Albert Janssen. It would be nice if one could use this utility with the firewall you are improving, or maybe a like utility. The utility would/could output the rules the way they are processed by the Firewall, and maybe also output the way they are displayed to the user. I use both LogViewer and Rules Viewer with AtGuard (I am the AtGuard beta tester for LogViewer). Unfortunately, the default log loading is geared to the AG/NIS log format. However, LogViewer can load comma-delimited (CSV) logs manually. That is one reason I suggested that format. I can't promise anything without talking to Sven, but if we stick to that format, it should be possible to include the new firewall log as an option for default loading.
As for Albert, I don't even know if he is still maintaining or updating his utility. It has already been suggested elsewhere that a means to export and import rules be included in the new firewall. | |
gt7697cPremium
join:2001-02-16
The Hive | I agree, some may not want to walk the thin red line.:)
I think you might be confusing with what I was suggesting with another suggestion. What I am suggesting, is not something that actually does anything in regard to the firewall or how it operates. The utility would just pull the Rules down in a text format, either organized the way the firewall processes the rules or organized the way the rules are displayed to the user. I suggested Albert's utility as a format (or base line standard) for a new utility. I don't believe you would want this utility to import rules into the firewall, it may be too complex or less secure. It might be much better to leave the import and export tools as they are, and then have this utility as a stand alone.
Of course having the rules displayed to the user in an organized fashion would also help. This does not mean the firewall processes rules the way they are displayed to the user. Having them displayed in a organized fashion would make maintaining the firewall easier for the user, and would/could make helping someone with their firewall easier.
Also you may want to explore how the firewall processes the rules, for speed. There may be a better way for the firewall to process rules that is more organized and faster. This should not be confused with having the rules displayed to the user in an organized fashion, this is a separate matter. In fact you might consider a way for Advanced Users to tweak this setting.....just a thought.
I suggested Log Viewer because it is a very nice easy program. I would prefer that someone consider a good Log Viewing program to go along with this firewall. Tiny Logger really is not that feature rich and can be a confusing pain at times.
HTH.:)
--
Just my 2 bits. | |
| reply to ghost16825
said by ghost16825:On an unrelated note, I hope I am not using the dslreports Kerio Forum the wrong way; this thread has sort of become the 'All things related to the Kerio-like open source project' thread. Nah, I don't think so. If Sveasoft-related threads and posts (and HyperWrRT too) are allowed in the LinkSys forum, then KerioKlone/Ghost Personal Firewall/whatever posts should be allowed too, I would hope. I might only suggest stickying it to the top, to segregate it from more "day to day" topics.
I also had an interesting revelation when I woke up today - if the features for: 1) maintaining stateful rules, 2) allowing dependent rules, both on stateful rules, and other rules, 3) rules allowing the logging of or the creation of traffic, 4) rules that allowed the creation of rules, were all allowed, then that forms the minimal basis needed to implement a stored-program computer, a Von Neumann machine. I also had the idea of implementing a Chess program, entirely within the ruleset of the firewall. :P Crazy, I know. But it might serve as an interesting performance benchmark. I'm not saying that should actually be included in GPF, of course, but it's a tantalizing prospect to implement in the rules-engine.  | | |
|
ghost16825Use security metricsPremium
join:2003-08-26
1 edit | reply to ghost16825
Progress Update Fri, 24 Dec 2004 00:46:47 GMT
Rule creation Advanced | | 
New rules editor |
A separate setting will allow the user to select the defaults to avoid going through the advanced button:
Default:
(Local and remote endpoints) OR Group (Select which group)
If local and remote endpoints - does the user want any or the remote/local port used select by default.
As the screenshots stand now - selecting show X group will disable up/down/copy buttons. New rule will open a rules creation dialog without the application part. This means a group rule will not be able to include a bunch of rules if they cannot be done in a single one, if you get what I mean.
Re: Rules by hostnames
The 3 allowable filters I have in mind -
Links containing
From this host (www.x.com not a.x.com
Links on this domain *.x.com
Perhaps links containing ... is moving more towards regular expression filtering, which I do not want.
Re: Application control
It is evident that there is some demand for application control, even if it is just to satisfy leaktests.
Going through all the leaktests out there, I tried to find some common criteria with which to include.
The following will be completely optional, off by default.
As you would expect, trying to counteract these leaktests without turning into a complete sandbox and protecting Windows from itself is difficult. Here are my suggestions for the optional Application control component:
- Do not allow any application other than explorer.exe to launch IE (or user defined browser list)
- Do not allow hidden windows to establish Internet connections
(This doesn't stop anyone from using already used windows, as this code comment apparently says:
Such methods can even be used on pre-existing
// Internet Explorer windows; we don't need to have created them
// ourselves. In that way, we could pass information even if some
// goofy firewall vendor decides to block programs with top-level
// hidden windows from establishing Internet connections, or some
// such silly thing.
- Do not allow dll injection from apps other than explorer.exe
- Only allow DNS on port 53
- Do not allow fragmented DNS packets (covered by do not allow frag packets)
- Reject threads not created by the same application
- Do not allow memory to be modified by another process
- Do not allow recursive DNS queries
This leads to a post from the webpage:
said by the webpage:
- # ? Later milestone feature: Deeper rule filtering. eg. A created rule: For outgoing port 80 only http is allowed, (ftp will be denied)
I really do not want to go down this path, as it requires the firewall being able to recognise every protocol under the sun. What I do think is important is some safeguards for DNS, which I believe is becoming quite popular as a covert channel.
------------------------------
The following are recent feature ideas I had:
Option: Rule prompts always on top
Option: Log frag packets (as well)
Options: For Deny unknown setting and Allow unknown setting - some form of logging for them
"Official" Program Name in rule prompts from the part embedded in the exe.
Most of the above ideas will be posted on the website shortly. | |
gt7697cPremium
join:2001-02-16
The Hive | Great work so far.:)
Was just sitting back and thinking about how I am using Kerio now and came up with 1 more suggestion.;)
1. Protected Firewall driver service in windows. There was a problem with a website that once kerio encountered it, it would crash. The work around was to set, in the Services Tab, the Kerio Service to Auto Restart. Once that was set the problem, if encountered, was minor and sometimes did not repeat itself. Maybe it would be worth while to investigate the problem.
HTH.:)
--
Just my 2 bits. | |
| reply to ghost16825
Re: [Kerio 2.x] Kerio 2.2 Features (request) Assuming the project gets the basics of packet filtering operational, I'd like to have an "extension" capability.
Let me develop a DLL that gets loaded and called by the firewall.
- Call an API into the DLL to determine its configuration options. The DLL should be able to add menu options. The extension DLL's should handle their own configuration files.
- When called for filtering, a DLL function should have access to data such as:
• Protocol
• Port
• SYN status to indicate if TCP initiating
• Inbound / Outbound direction
• Raw packet content & size
• Remote IP and port
• Program name involved
- Option 1: Before any normal rules get invoked, call a function in the extension DLL. A return code from the DLL or status flag in a structure indicates whether to Permit, Deny, or to continue looking for other rules.
- Option 2: A special rule which indicates to invoke an extension DLL. This rule may be moved Up / Dn like other rules to indicate relative priority with other conventional rules.
- Option 3: After all other firewall rules are applied and if nothing else has denied the communication, then call the extension DLL.
Why extensions? Because nodoby knows what everybody wants to do now, or will want to do in the future. Building all desirable features into one program can yield a bloated mess. Some of the things already listed in this thread may be better offered as an extension instead of hard-wired into the base firewall.
Example extensions:
• IP Group access based on various Active Directory membership.
• Time of day & parental control of certain applications.
• Bandwidth throttling based on applications - the DLL call may sleep() before returning so incorporate a good threading model.
• Port Triggers, such as allowing IDENT only to support POP3/SMTP processes, and shutting it off at all other times.
• IDS.
• Temporary allowance during events such as self-invoked GRC scans.
• Application groups - "Browser" permission may apply to IE, Opera, Firefox, and others without building individual rules for each one. Similarly, I use several email programs on this PC and had to build the same set of Kerio rules for each of them.
• Summary of I/O byte & packet counters by application.
• Syslog, SNMP Traps, EventLog, and other forms of logging.
• Interfaces to LinkLogger.
If there is a good structure for where 3rd party extensions can be invoked within the firewall, the future of the product may be assured. Like Firefox: some like it "light" while others thrive on many of the available extensions.
But extensions will be worthless unless the heart of the firewall is secure, robust, and reliable under pressure. | |
ghost16825Use security metricsPremium
join:2003-08-26 | reply to ghost16825
Re: The name of the project
I would prefer something which straight away gives the impression that this is a "rules-based" firewall, otherwise a fancy sounding name is the next best thing. | |
 Khaine
join:2003-03-03
Australia | reply to inTulsa
said by inTulsa:Assuming the project gets the basics of packet filtering operational, I'd like to have an "extension" capability. Let me develop a DLL that gets loaded and called by the firewall. I asked for the firewall to be built with a plugin architecture in mind, so that it could be expanded easily like you suggest, but that was shot down. Maybe a reconsider is in order | |
ghost16825Use security metricsPremium
join:2003-08-26 | reply to ghost16825
Progress Update Sun, 26 Dec 2004 03:39:28 GMT said by Khaine:
I asked for the firewall to be built with a plugin architecture in mind, so that it could be expanded easily like you suggest, but that was shot down. Maybe a reconsider is in order
Ok. Here it is.
1) Firstly I think some may be overestimating the power of plugins. One thing to remember is that plug-ins can only get data which the underlying core part a) acquires anyway/supports acquiring and b) is referenced well so a plugin can easily reference a particular feature.
If for all of those listed below:
said by inTulsa:
# IP Group access based on various Active Directory membership.
# Time of day & parental control of certain applications.
# Bandwidth throttling based on applications - the DLL call may sleep() before returning so incorporate a good threading model.
# Port Triggers, such as allowing IDENT only to support POP3/SMTP processes, and shutting it off at all other times.
# IDS.
# Temporary allowance during events such as self-invoked GRC scans.
# Application groups - "Browser" permission may apply to IE, Opera, Firefox, and others without building individual rules for each one. Similarly, I use several email programs on this PC and had to build the same set of Kerio rules for each of them.
# Summary of I/O byte & packet counters by application.
# Syslog, SNMP Traps, EventLog, and other forms of logging.
# Interfaces to LinkLogger.
a plugin can perform the work by itself without modifying a 'core' engine just by getting the following:
said by inTulsa:
# Protocol
# Port
# SYN status to indicate if TCP initiating
# Inbound / Outbound direction
# Raw packet content & size
# Remote IP and port
# Program name involved
then a plugin architecture is feasible.
Then the only question is "How much of a difference will such a thing make to complexity and resources used by the core application?"
And if the answer is very little, then I would have no hesitation in including a plugin architecture.
However here's what I think:
1) A plugin architecture would require much more data which would not be used in the core app at all, increasing resource-usage and size.
2) By not accommodating plugins, (no extra data, very little 'clearly referenced' core features) yet creating a plugin architecture use for plugins is limited. Perhaps a log viewer and very little else could be a plugin.
---------------------------------------
Just a reminder, any kind of feature more likely suited to high-end hardware firewall will not be included in this project - it is an open-source project after all.
As seen on the webpage, »kerio.sourceforge.net/finalfeaturesspec.html the following are still being decided upon:
- ? A way to automate the process of getting rid of unnecessary/removed applications hashes. One idea could be an option to remove MD5s if the app had not been used for X days. On the Xth day not used the firewall could perform a simple check that the present hash was the same as that stored, than remove the stored hash.
- ARP filtering
- # ? Later milestone feature: Deeper rule filtering. eg. A created rule: For outgoing port 80 only http is allowed, (ftp will be denied)
- A Prompt timeout setting. Timeout (sec) Action (Deny and Log will be the default)
- # Filter: ICMP outbound for specific applications. Is this possible? Is this a waste of time?
- # Ability to choose rule prompts to be 'Always on top' or not
- The ability to neither Allow/Deny a rule but simply prompt when matched
- A checkbox to log rule prompts in the same filter.log file (or no option just log)
- A checkbox to log both local and remote admin attempts to filter.log (or no option just log)
- Create log in csv format
- User set time limit for logs
- Anti-DNS covert channel/hijacking countermeasures
Option: Log frag packets (as well)
Options: For Deny unknown setting and Allow unknown setting - some form of logging for them
At present my thoughts are as follows:
- The application hash removal method listed above seems reasonable
- ARP filtering - unsure, probably won't include
- Deeper rule filtering etc - not likely
- ICMP outbound linked to applications - unsure
- Rule prompts on top - include
- Logging everything to the same filter.log file
- CSV format for logs only - this seems to be the most universal format; everything else I have seen seems a proprietary format
- Time limit for logs - unsure. Probably included.
- Anti-DNS covert... - unsure
- Log frag packets - unsure, probably not.
- Any form of logging for allow unknown, deny unknown settings - probably won't include.
I hope to tackle the problem of temporary rules next. | |
Khaine
join:2003-03-03
Australia | said by ghost16825: said by Khaine:
I asked for the firewall to be built with a plugin architecture in mind, so that it could be expanded easily like you suggest, but that was shot down. Maybe a reconsider is in order
Ok. Here it is. 1) Firstly I think some may be overestimating the power of plugins. One thing to remember is that plug-ins can only get data which the underlying core part a) acquires anyway/supports acquiring and b) is referenced well so a plugin can easily reference a particular feature. That is true, but it really depends how you design the firewall
HYave a merry Christmas all | |
gt7697cPremium
join:2001-02-16
The Hive | reply to ghost16825
Very quick question:
said by ghost16825:
Just a reminder, any kind of feature more likely suited to high-end hardware firewall will not be included in this project - it is an open-source project after all.
Just so no one is confused or may become confused in the future, Kerio 2.1.5 is the base line feature set for this firewall project, correct?????
And therefore, it would be reasonable to assume that someone using Kerio 2.1.5 right now would see all the features of Kerio 2.1.5 in your firewall project plus improvements and/or new features????
There is no such thing as a dumb question, except the question that was never asked.
--
Just my 2 bits. | |
ghost16825Use security metricsPremium
join:2003-08-26 | reply to ghost16825
Progress Update Mon, 27 Dec 2004 04:47:07 GMT Some minor modifications has been made to the Final Feature Specification on the webpage ( »kerio.sourceforge.net/finalfeaturesspec.html ).
said by gt7697c:
Just so no one is confused or may become confused in the future, Kerio 2.1.5 is the base line feature set for this firewall project, correct?????
That is correct...but leading to your next question...
said by gt7697c:
And therefore, it would be reasonable to assume that someone using Kerio 2.1.5 right now would see all the features of Kerio 2.1.5 in your firewall project plus improvements and/or new features????
Most but not all. Specifically, see the features listed under the 'Included modified changes over Kerio 2x' heading of the webpage. | |
ghost16825Use security metricsPremium
join:2003-08-26 | reply to ghost16825
Opinions on how to implement session rules I've been thinking about how to implement some kind of "session"/temporary rules in a neat and generic way. What I'm not clear on is the way most people would like to use it.
Here are ways most Kerio2x users would use this feature as I see it, from most common to least common:
1) Use a temporary rule to allow outbound traffic for a single application to any address any remote port any local port
2) Use a temporary rule to allow outbound traffic for a single application to a single IP any remote port any local port
3) Use a temporary rule to allow outbound traffic for a single application to any address any local port to a single remote port
4) Use a temporary rule to basically turn off any outbound application filtering for all applications for a set time period
5) Other ways, a mixture etc. eg. perhaps temporarily make an application have a 'group' rule.
(Disregard logging issues for the moment)
(Clearing the 'temporary rules' will be discussed later. Temporary rules will be like a brand new rule table, read in a top-down fashion above existing rules)
Which would be the most common way you would use 'temporary rule creation'? | |
| reply to ghost16825
Re: Progress Update Mon, 27 Dec 2004 04:47:07 GMT Regarding "Local address can be 'This computer' or user defined"
Assuming "user defined" means user specified IP, thank you. But can you clarify "This computer?" "This computer" could be WAN, LAN, Localhost, 0.0.0.0, or all of the above. Would "Any address" be a better choice?
Not complaining, just confused. | |
Steve_M
join:2004-09-14
Schenectady, NY | reply to ghost16825
Re: Opinions on how to implement session rules said by ghost16825:I've been thinking about how to implement some kind of "session"/temporary rules in a neat and generic way. What I'm not clear on is the way most people would like to use it. Why not leave it up to the Administrator. The temporary rule could be setup in the same manner as all rules, only it would belong to the temporary group. | |
ghost16825Use security metricsPremium
join:2003-08-26
1 edit | reply to ghost16825
Progress Update Fri, 31 Dec 2004 01:10:31 GMT said by Stockbridge:
Assuming "user defined" means user specified IP, thank you. But can you clarify "This computer?" "This computer" could be WAN, LAN, Localhost, 0.0.0.0, or all of the above. Would "Any address" be a better choice?
In short 'My computer' will behave in a Kerio 2x-like fashion - yes I think that would mean all of the above.
said by Steve_M:
Why not leave it up to the Administrator. The temporary rule could be setup in the same manner as all rules, only it would belong to the temporary group.
Ok. So here is where our opinions diverge. I was thinking very short time frames - 5 mins, 20 mins, 1 hour, 2 hours max with no rule editing at all, only the ability to flush all temporary rules. I was also thinking about another right-click context menu on the systray, similar to the rule-toggle feature, with the time limit (and maybe 1-5 of my previous post) already preset. I'm unsure of what you're trying to describe but it could be more like a separate group which is "permanent" but can be taken out and interchanged at will. This is more to do with rule-editing, no?
-------------
As far as progress goes, things have slowed down a bit lately. We are getting down to the near finished Final Feature Specification. However I am undecided as to whether to come up with specification for remote administration now or later.
One thing about local administration needs to be decided on however. As Kerio 2x handles password protection at the moment, I believe that this password applies only to the interface not to the actual rules file itself. This means that rules can be exported and read elsewhere regardless of the password. If this open source project were to emulate this, it would mean a 'hash + salt' method as I believe Kerio 2x has done. If users want the rule-sets themselves to be protected, this would mean a full-blown encryption method on top of some kind of 'salted hashing' (encrypted ruleset, no password). What path should this project take?
I will see about posting a rough GUI soon as I can, but at the moment I am trying to iron out teething software troubles.
On an unrelated note, I considered the idea of posting all related project discussion in a new thread every so often to keep them ~ 1 page long and avoid people having to trawl thorough posts but decided against it for the time being. | |
Steve_M
join:2004-09-14
Schenectady, NY
1 edit | said by ghost16825:said by Steve_M:
Why not leave it up to the Administrator. The temporary rule could be setup in the same manner as all rules, only it would belong to the temporary group.
Ok. So here is where our opinions diverge. I was thinking very short time frames - 5 mins, 20 mins, 1 hour, 2 hours max with no rule editing at all, only the ability to flush all temporary rules. I was also thinking about another right-click context menu on the systray, similar to the rule-toggle feature, with the time limit (and maybe 1-5 of my previous post) already preset. I'm unsure of what you're trying to describe but it could be more like a separate group which is "permanent" but can be taken out and interchanged at will. This is more to do with rule-editing, no? I just feel that any temporary rule that would let a application past the firewall should be under the control of the Administrator. This way, any such rule would be as tight or loose as the Administrator sees fit. I have major concerns about any rule being built into a firewall that would let any application out on any port using any protocol. Even if it is time limited, it is still a breach of security, and in the wrong hands could possibly cause harm to a system.
I guess the real question is if the only people who will ever use this firewall will also be aware of how viruses, trojans and spyware work and communicate on the net. Because if this built in temporary rule, which is user accessible, ever falls into the hands of someone that does not know about the above threats, I guarantee you it will only be a matter of time before they let something through that they should not.
The key is that this temporary rule is "User Accessible", and that means any user can allow anything out.
Personally, if I was going to use such a temporary rule, I would want to be able to tighten it up as much as possible. This Generic "one rule fits all" is just to loose. It would be no different than having a Any application out on any port using any protocol rule in your rule set. Other than it would be temporary. It just doesn't make any sense.
One thing you might consider. Have one rule that when configured, is accessible from the tray applet and/or the right click menu. If it needs to be time limited, then this can be set from the rule editor as an option. Like wise, a time limit before the temporary rule is flushed could be set as a option. Maybe even have a separate tab just for the configuration of the built in temporary rule. This way you can still have the temporary rule in place, but the way in which it is used could be decided by the Administrator. | |
ghost16825Use security metricsPremium
join:2003-08-26 | reply to ghost16825
News update Tue, 04 Jan 2005 07:54:23 GMT A small number of additions have been posted to »kerio.sourceforge.net/finalfeaturesspec.html
The above page is not polished by any means, so if you are worried that a feature you want is listed but the specifics vague, do not worry yet.
said by the features specification page:
- # ? Later milestone feature: Deeper rule filtering. eg. A created rule: For outgoing port 80 only http is allowed, (ftp will be denied)
- The ability to neither Allow/Deny a rule but simply prompt when matched
I'm leaning towards these features being ruled out indefinitely, the others seem feasible enough. The first is probably just outside the mandate of what this project sets out to achieve in terms of complexity, if only slightly. The second seems to be a feature that very, very few will use.
In regard to temporary rules, I think I have a general idea of how they will be implemented (not listed in the features spec yet). Temporary rules will have one of 1-5 of my previous post user preset, a user preset lifetime, no editor for them, a right click menu admin-only method of saving a temporary rule and a "flush" option.
Which leads to...
said by the features specification page:
- "Non-stealthing" ability - fake closed port responses etc.
This is perhaps one of the last implementation concepts I will have to come up with before a full GUI specification and full architecture specification can be released.
If anyone has any new last minute ideas about what could be included in this firewall, while keeping to the guidelines listed on the webpage, now is the time to send them to me.
Again I would to reiterate that users not be concerned if the general concept of the feature they are after is listed in a vague way on the website. What is important is to bring up feature requests which have not been touched on at all.
As always your feedback for any feature is welcome.
--
Admin of the Kerio 2x-like open source project:
http://sourceforge.net/projects/kerio/
http://kerio.sourceforge.net/
| |
|
