(Updated Tue, 04 Jan 2005 07:49:03 GMT)
Newly requested features will be
Some ideas about what will be included in a new 'Application Module'
are posted here
See what has yet to be done in the new 'to do' list
# Submitted by project admin
? Specific details need to be finalised
- This project aims to be something "similar" to Kerio2x
- This project will not emulate features commonly found on
enterprise-level hardware firewalls.
- This project will not aim to be "enterprise-class" by any means. The
aim will for the time being is to be a 'personal' firewall product, for
use mainly on home machines and small (or at max medium) size networks.
- This project will not aim to be a replacement for the use of
- This project will not aim to be a replacement for an IDS
- This project aims to be a rule-based firewall, where firewall rules
are read top-to-bottom in a linear fashion. (Although a way to process
rules in NlogN will hopefully be done in the future)
- This project does not aim to be a conversion of *nix/BSD etc kernel
level filters for the Windows platform. eg. IPfilter, Netfilter,
- This product aims to have very little 'artificial intelligence'
whatsoever - it will specifically follow clearly defined user rules.
Full SPI may be added eventually, but this will be after a number of
|Included modified changes over Kerio 2x:
|- # Microsoft
Networking Tab removed
- # Any option to check for program updates
- No FUD terms like 'ACK
attack'. Just state the facts - 'Out of
sequence ACK packet' or something even shorter. The option to
log 'Suspicious packets' will be removed entirely.
- ? If you have a port listening on tcp only, kerio will prompt
for any udp
packets on the same port even though nothing is listening on udp.
Ghost Personal Firewall will have a changeable option on by default to
packets without prompts if nothing is listening on UDP.
- When opting not to have a
"stealth" setup, the OS fingerprint should match the underlying
operating system. There should not be a Ghost Personal Firewall
able to be obtained as is the case with Kerio 2x.
- User priveleges are followed
correctly in input/export open dialogs; can handle large volumes of
- 'Don't resolve port names' under
Settings of the Status Window will be removed. Port names will never be
- The last four columns of the
Status Window will be removed (Rx Bytes, Rx Speed, Tx Bytes, Tx Speed).
Likewise the status bar will no longer display transfer speeds.
- Remote Admin from the Status
Window will no longer be available.
|Included additions (over Kerio 2x):
|- # Independent firewall
driver (not dependent on Netbios). This should remove a lot of niggly
issues and conflicts
- The ability to export, and import only selected rules to/from another
file. [Screenshot] (Needs to be
- ? Checkbox to deny all fragmented packets, on by default.
- # ? Improved rule editor. [Screenshot]
One click on the copy button creates a copy of the selected rule
underneath the one selected. 'Any' text larger and easier to read. Undo
reverses the last single rule
modification. Restore last changes everything to the way it was on the
last time the changes were applied. Double-arrows shifts the selected
rule up or down by a user set amount. [Screenshot]
Another option is to only have endpoint arrows which send the selected
rule straight to the top/bottom of the ruleset without a user set
- # ? Ability to create multiple custom address groups. [Screenshot] Add and Edit function
as in the original Kerio 2.15. Undo reverses the last modified address.
- # User setting to control double click behaviour for the tray icon [Screenshot]
- The ability to filter by either
IP address OR dns address
- # ? A better right-click context menu for the systray icon [Screenshot]
- As well as syslog, an option to
send logs to the Event Log on XP/2000
- Ability to specify log size
- A quick enable/disable rule function in the right-click systray menu
with no password required. Only 0 or 1 rules can be put in this menu,
in truncated form. (No rule is here by default). In the following [Screenshot]
the rule is 'IE traffic
including 443'. The fact that no password needs to be given
regardless if one is set should be explicit within the help file.
- Termination protection within the executable itself (not separate)
from the most used termination methods (at max ~3 methods). See here.
- Right-click menu in Status window
when clicking on a connection endpoint > Close connection.
(Forcefully closes the (TCP) connection; similar to TCPview function)
- Some 'grouping' of rules. Here is a rule creation Advanced [Screenshot].Here is the new rules
editor [Screenshot]. A separate
setting will allow the user to select the defaults to avoid going
through the advanced button:
(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.
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 group of separate rules if
they cannot be done in a single one. (An application will not be able
to belong to multiple groups)
- Local address can be 'This
computer' or user defined
| Features included in later milestones
|- IPv6 filtering
- ? Funky statefulness
- Some kind of certification (ICSA etc). Someone has suggested PC
Firewall Criteria (Self Managed).
- A separate (optional) module to implement termination protection
(resistant to all of these
attacks instead of just the most common ones)
- # Remote Administration using
user defined "port knocking"
- SNMP Trap Message sending
beyond the mandate of Ghost Personal Firewall (not included)
|- TCP flag filtering
|Ruled out indefinitely
- Content filtering, HTML local proxy-type filtering like Proxomitron
- OS fingerprint masquerading
- Application sandboxing similar to
- A plug-in architecture.
- # Ability to have rules be allowed only if another rule has been
detected in a previous set time period.
- Any kind of major admin/user separation (apart from the usual
administration password etc)
- Any kind of "zoning" system. This includes any kind of 'Internet
Zone' and 'Local Zone' or 'Admin Zone' or 'User Zone'. There will be
multiple custom address groups already included.
- # ? "NOT" type of filtering. eg.
Only allow X if the remote port is
- Any kind of function to do with even more detailed parts of packets.
This includes something like TCP flag filtering, dumping to file of the
full contents of a packet. Anything which is more related to the
function of a packet sniffer than a firewall. As a general rule,
anything which is in the class of features that would be included in a
enterprise level, hardware firewall.
- Any kind of regular expression type filter rules
|- ? 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
- # 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
- 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
- Hostname filters: From this host
(www.x.com not a.x.com), Links on this
domain (*.x.com), Links containing, Exact link (x.com/index.html)
- As part of the 'Application
Protection' module: An option to randomly swap the position of
Permit and Deny buttons in rule prompts
To do list -
problems which must solved in a generic way:
- A way to eliminate multiple alert window 'stacks'
- Temporary/expiring or similar rules
- "Non-stealthing" ability - fake closed port responses etc.
Done - Some kind
of user defined default for rule prompts
Done - Some kind
of use of rule groups. From user feedback, this seems to do
with a second rule editing interface for rule groups and/or related to
defining defaults for rule prompts
- Some kind of a) file checksum action and b) monitoring of application
As a general rule if it is not related to network activity Ghost
will not get a checksum for it.
Any kind of application sandboxing similar to KPF 4 will not be
This may not preclude monitoring messages sent between applications if
they can be seen as network related. eg. LSPs
As far as the file checksum action goes, I am currently against the
idea of finding the checksum (MD5 etc) for non-executable components
used by an executable. The type of checksum to be used has not been
decided upon. Either has the encryption method for encrypted rules and
remote administration. "NSA paranoid" schemes like SHA-512 hashing with
AES 256 bit encryption are unlikely to be chosen. I am currently
getting advice on the best encryption/hash function to use for this
At present there seems to be some
demand for an optional "application protection" module as part of the
firewall. The admin does not want to turn this project into a full
application sandbox; he is of the opinion that the "application
protection" included in KPF4 is too much. As you would expect, some
kind of application monitoring without going down a slippery slope path
to application sandboxing is difficult. The following are some
completely optional features (most if not all will be off by default)
that could be included because they specifically related to
"leaktest-like" behaviour and network behaviour itself.
- Do not allow any application other than explorer.exe to launch IE (or
a user defined browser list)
- Do not allow hidden windows to establish Internet connections
- Do not allow dll injection from apps other than explorer.exe
- Only allow DNS on port 53
- Do not allow fragmented DNS packets (the Do not allow fragmented
packets feature will override this feature if it is already ticked)
- Reject threads not created by the same application
- Do not allow memory to be modified by another process
- Do not allow recursive DNS queries