Add a rather rudimentary README
This commit is contained in:
parent
3c25cbe88a
commit
b6c191e2ce
45
README.md
Normal file
45
README.md
Normal file
|
@ -0,0 +1,45 @@
|
|||
# FRIwall
|
||||
|
||||
Web application for managing the main firewall at FRI.
|
||||
|
||||
## Operation
|
||||
|
||||
The firewall consists of two servers (or “bricks”) in active–backup configuration, using weighted BGP routes for failover. Traffic filtering and VPN are done with nftables and WireGuard. Both are configured exactly the same on both servers. The settings are managed with this application.
|
||||
|
||||
On each configuration change, a tarball of relevant files in `/etc` is generated and pushed via SSH to both nodes. This happens for instance each time an IP set or a forwarding rule is modified, or a VPN key is added or removed. Firewall nodes and the current configuration version for each are stored in `nodes.json`.
|
||||
|
||||
## IP sets
|
||||
|
||||
Names and IP prefixes for physical networks are configured in NetBox and stored in `networks.json`, which is never modified by the application. Custom IP sets used for forwarding rules may be defined at `/ipsets`, as well as NAT addresse and VPN access for all networks. These settings are stored in `ipsets.json` and added to static definitions in `networks.json` when generating firewall configuration.
|
||||
|
||||
## Rules
|
||||
|
||||
Forwarding rules are configured at `/rules` and toggled at `/rules/manage`. Enabled rules are included directly in the nftables configuration. For each rule, one or more manager groups can be set; users in these AD groups may toggle the rule without admin access. This is used for instance to allow teachers to disable Internet access in classrooms.
|
||||
|
||||
## VPN
|
||||
|
||||
WireGuard is used for remote access. Domain users can self‐register new keys at `/vpn`. The key database `wireguard.json` is a dictionary of entries like
|
||||
|
||||
"10.0.0.26": {
|
||||
"key": "ABC…XYZ=",
|
||||
"ip6": "aaaa:bbbb:cccc:dddd:1a::/80",
|
||||
"time": 1682166836.88937,
|
||||
"name": "machine1",
|
||||
"user": "user@domain"
|
||||
}
|
||||
|
||||
IP addresses for new keys are assigned automatically from the subnets defined in `wg_net` and `wg_net6` settings. When generating firewall configuration, each IP is placed in the nftables sets based on its user’s group and settings in `ipsets.json`.
|
||||
|
||||
### Custom keys
|
||||
|
||||
Administrators can define custom keys with access to specified networks at `/vpn/custom`. These keys are used to connect machines into secure networks where users are not allowed to attach arbitrary devices themselves.
|
||||
|
||||
Custom keys are stored in the same database, but with a `networks` entry in place of `user`, for instance
|
||||
|
||||
"10.0.0.27": {
|
||||
"key": "FOO…BAR=",
|
||||
"ip6": "aaaa:bbbb:cccc:dddd:1b::/80",
|
||||
"time": 1682166836.88937,
|
||||
"name": "machine2",
|
||||
"networks": ["net1", "net2"]
|
||||
}
|
Loading…
Reference in a new issue