Firewall rework
Rationale
The firewall module is one of the most criticised and controversial parts in eBox. Abstracting the firewall configuration is a tricky work, we tried our best, and it seems our approach can be improved.
The main reason for this rework is extending its capabilities to make it more flexible. We do not want our potential users to discard eBox as a solution just because they cannot add rules to the OUTPUT chain.
Our initial conception was to design the firewall as much strict as possible. On the one hand, users could only add rules to the FORWARD chain, and for connections coming from the LAN to the Internet, and on the other hand, INPUT and OUTPUT chains were managed by ebox modules. That is, if there is a dns module which needs to access the external world to resolve names, the module itself will be in charge of configuring the firewall for such a purpose. This design is nice, and from a security point of view the way to go. The problem arises when the user needs to install another service on the eBox machine which is not provided by module. The fact that the user cannot add a rule from the web interface might be a showstopper to install eBox. That's one of the things we would like to face at this stage.
Design
Services
Add custom services: the user will be able to add new services each service will contain the following fields using the generic Ajax table:
- Description: []
- Protocol: [TCP, UDP , TCP/UDP, ICMP, ANY]
- Source port: from [1] to [65536] 1 and 65536 will be the default ports
- Destination port: from [] to []
Filter rules
- Access rules from LAN to Internet. They will contain the following fields:
- Description: []
- Decision: [ACCEPT, DENY]
- Service: [ANY, LIST OF AVAILABLE SERVICES]
- Source: [ANY = ALL LANs, LIST OF AVAILABLE OBJECTS, IP/Netmask, INTERNAL INTERFACES]
- Destination: [ANY, LIST OF AVAILABLE OBJECTS, IP/Netmask, INTERFACES]
- Log: log rule or not
