$Id: TODO,v 1.12 2004/03/25 23:11:51 ktsaou Exp $

The following is a list of features I plan to add to FireHOL,
assuming that my time permits and there is demand for them.

The list appears in no particular order.

1.The ability to have multiple versions of the firewall in memory and "activate"
  them on demand. This can be done if each "start" of FireHOL produces all the
  iptables rules in one "numbered" iptables chain (in each build-in table and
  chain) and then switching by "firehol activate 1" and "firehol activate 2".
  This will also solve the issue that FireHOL allows all traffic during firewall
  activation.

  This will also provide a method for dynamic configuration of firehol, so that
  changes would be applied without stopping and restarting the whole firewall.

2.Protections on interfaces should operate only when the firewall is going to
  allow the traffic.
  Now, protections operate on a per network interface basis, before the
  firewall rules, which means that an attacker could just produce a denial of
  service attack on http by SYN-FLOODing port 32000.
  Of course, the attacker can always SYN-FLOOD the http service to make the
  firewall drop temporarily all connections anyway.
  So, this ToDo item is more like a "should be the optimum way", without
  meaning that it is not right now.

3.Extend HELPME to guess network broadcast network addresses too.

4.Bandwidth accounting support per firehol element.

5.Show the currently active connections from the connection tracker
  (like a network top). There are a few other tools for this, but ideally, our
  solution should show the active connections categorized according to firehol
  rules, not iptables rules.
  
6.Protections should be able to applied to each firehol element
  individualy.

7.Support groups of services. Today, an interface or a router is much like
  a group. Ideally, we should also support subgroups that will allow the
  sharing of common protections and src/dst restriction and in the future
  common NAT and bandwidth shapping values.

8.Ideally I would like to achieve a situation where FireHOL
  directives will be something like:
  
  interface eth0 internet maxbw 1Mbps queue-type htb
	server smtp accept	\
		maxbw 128kbps	\
		priority low 	\
		dnat mailhost.domain.com
		
	server http accept	\
		maxbw all	\
		priority med	\
		dnat "1.1.1.1 2.2.2.2" # this is load balancing
	
	client ssh accept priority hi

  I guess the only way to implement this is by making heavy use of the
  MANGLE table and MARKing uniquely each FireHOL rule. This will allow all
  iptables tables (mangle, nat, filter) and iproute to share the same traffic
  categorization (through the MARK id on each packet). Some research has to be
  done to find out if this is possible.

9.  A Web interface for configuring FireHOL.

10. A secure mechanism for centralized control of a large number
    of Linux hosts and routers.

11. There should be a simple way to produce service variations.
    For example, "I need an http server running on port 81".
    
    Possibly with:
    
    server http/80=81 accept

12. FireHOL services should be left to an external directory
    when installation programs could just drop in files for
    adding services to FireHOL.
    
    Ideally, this should also allow a "service documentation
    navigrator", something like a dynamic services.html (from
    the web site) based on the services installed on the
    machine.

13. FireHOL's speed on processing configuration directives
    could be significantly improved if the rule() function
    is written in C.
    
    This will improve processing of FireHOL directives and
    will allow the rest of FireHOL to be compatible with
    faster sh versions (like ash).
    
    However, the absolute speed improvement will be
    accomplished only if the rule() is written in C and
    instead of producing iptables statements, it talks to
    the kernel to activate them at once (thus eliminating
    iptables user-land programs altogether...)

14. Split FireHOL into multiple programs each providing
    some of the functions already supported. The idea
    is that there should be a "library" of shell functions
    and then a few drivers that provide the functions
    of the current command line arguments to FireHOL.

15. Isolation of parts of the firewall and separate
    management for each.
    
    For example, the master configuration should state
    about interfaces and routers that all come from
    different files, and each of those could be started
    stopped and altered indepedently of the other.
    
    This will be very usefull for providing delegated
    administration to dedicated server hosting
    environments where each customer can control his own
    part of the firewall through a simple web interface.

16. Add support for psad by replacing the default log
    strings of the DROPs at the end of interfaces and
    the firewall to "DROP".


17. Change the way "debug" mode is handled so that the
    generated debug file can be run without FireHOL
    installed. This requires a change in the way FireHOL
    configuration settings are processed and the way it
    is inlined/sourced, since a few configuration
    settings affect the standard header ruleset
    generated.

18. Support for TCPMSS action.

19. Support for ULOG as rule parameter.

20. Support pre-defined rules to be loaded when the
    firewall is stopped.

