$Id: TODO,v 1.19 2005/04/03 21:48:04 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. ==> DONE <==

8.  A Web interface for configuring FireHOL.

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

10. 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

11. FireHOL services should be left to an external directory
    when installation programs could just drop in files for
    adding services to FireHOL. ==> DONE <==
    
    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.

12. 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...)

13. 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.

14. 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.

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

16. 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.

17. Support for TCPMSS action.
    ==> DONE <==

18. Support for ULOG as rule parameter.

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

20. Support for logging only NEW connections so that
    only connection attempts will be logged. Not every
    packet.

21. Support for POLICY-ACCEPT - DROP EXPLICITLY type
    of firewalls when the interface policy is 'accept'.
    This can be done only for interfaces, when the
    interface policy is 'accept' and should be implemented
    by ignoring the source ports of the request.

22. Support for ratelimiting NEW connections on ACCEPT.
    This can be done with something:

    server smtp accept with limit 10/s 50

    ==> DONE <==

23. Allow limit as a second parameter to policy:

Instead of this:

interface ...
   policy drop

   ...

   server any myreject reject limit 5/s 5


Allow something like this:

interface ...
   policy reject limit 10/s 10 then drop


24. Add the ability to log only specific states, for example to
    log only new requests.

25. Remove the need to have all the helpers at the top, and then
    the interface/router blocks.

26. Allow a firewall to be build in multiple runs of FireHOL, so
    that we can split the configuration in multiple files and
    process them individually.

27. Support newer netfilter modules:

NETMAP
The CONFIG_IP_NF_TARGET_NETMAP provides a target for the nat table. It creates
a static 1:1 mapping of the network address, while keeping host addresses
intact. It can be applied to the PREROUTING chain to alter the destination of
incoming connections, to the POSTROUTING chain to alter the source of outgoing
connections, or both (with separate rules).

Examples:
iptables -t nat -A PREROUTING -d 1.2.3.0/24 -j NETMAP --to 5.6.7.0/24
iptables -t nat -A POSTROUTING -s 5.6.7.0/24 -j NETMAP --to 1.2.3.0/24


IPRANGE
This patch makes possible to match source/destination IP
addresses against inclusive IP address ranges.

Examples:
iptables -A FORWARD -m iprange --src-range 192.168.1.5-192.168.1.124 -j ACCEPT
iptables -A FORWARD -m iprange --dst-range 10.0.0.0-10.255.255.255 -j ACCEPT


SAME
CONFIG_IP_NF_TARGET_SAME is similar to SNAT/DNAT depending on chain: it takes a
range of addresses (`--to 1.2.3.4-1.2.3.7') and gives a client the same
source-/destination-address for each connection.

It has a --nodst option to make it not use the destination-ip in the
calculations when selecting the new source-ip

It has support for multiple ranges, including 1-address ranges.


NOTRACK
This option adds a new 'raw' table to iptables.  The raw table is the very
first in netfilter (it even precedes the conntrack subsystem) and uses the
PREROUTING and OUTPUT built-in chains.

The NOTRACK target can be used to select which packets *not* 
to enter the conntrack/NAT subsystems. Please keep in mind:
if you mark a packet with NOTRACK, then

- all the conntrack functionalities are lost for the packet
  (ICMP error tracking, protocol helpers, etc)
- all the NAT functionalities are also lost.

Packets marked with NOTRACK can be matched by the 'UNTRACKED'
state using the state or conntrack matches. Example

# Very busy webserver
iptables -t raw -A PREROUTING -d 1.2.3.4 -p tcp --dport 80 -j NOTRACK
iptables -t raw -A PREROUTING -s 1.2.3.4 -p tcp --sport 80 -j NOTRACK
...

# filter rules
iptables -A FORWARD -m state --state UNTRACKED -j ACCEPT


SCTP
This module helps to match SCTP packets based on the following criteria

Destination Port: --dest-port 
Source Port:      --source-port 
Chunk Types:      --chunk-types (all|any|only) <chunk types:flags>
		  The flag letter in upper case indicates that the flag is to match if set,
		  in the lower case indicates to match if unset.

iptables -A INPUT -p sctp --dest-port 80 -j DROP
iptables -A INPUT -p sctp --chunk-types any DATA,INIT -j DROP
iptables -A INPUT -p sctp --chunk-types any DATA:Be -j ACCEPT


REALM
realm match: uses realm key from routing as match criteria similiar to
             one in packet classifier

/** snip from packet classifier documentation */
Routing tables based classifier
CONFIG_NET_CLS_ROUTE4
  If you say Y here, you will be able to classify outgoing packets
  according to the route table entry they matched. If unsure, say Y.
/** end snip **/


# Example
# add route
/sbin/ip route add 194.29.194.0/24 via 194.29.192.1 realm 10

# source realm is in realm with mask 0xFFFF0000,
# destination is in realm with mask 0x0000FFFF

# match destination realm
/usr/local/sbin/iptables -A OUTPUT -m realm --realm 10 -j LOG

# match realm of source, this is also determinated by routing,
/usr/local/sbin/iptables -A INPUT -m realm --realm 655360 -j LOG

THIS PATCH REQUIRES CONFIG_NET_CLS_ROUTE TO BE SET

Note: With 2.6 CONFIG_NET_CLS_ROUTE is automatically selected.