Remote firewall with REST API.
rfw is the RESTful server which applies iptables rules to block or allow IP addresses on request from a remote client. rfw maintains the list of blocked IP addresses which may be updated on the fly from many sources. rfw also solves the problem of concurrent modifications to iptables since the requests are serialized.
- You manage a group of machines which are deployed/controlled/monitored from a central server or admin panel. You need to react quickly/automatically to abuse/DDOS with the rules generated by the intelligence/analytics/geolocation-aware server. You push the IP blocklist updates to other machines in real time.
- You build the Peer-to-Peer network of servers or Distributed Autonomous Organization (see Ethereum). The DAO, apart from running contracts on Ethereum, may need to run a P2P network. The servers cannot rely on the centralized firewall. With rfw the peer servers can share info about botnet IP sets and current sources of abuse to more efficiently protect against DDOS and other attacks.
See the tutorial with example
- block/allow IP addresses with iptables on request from remote host
- handle individual IP or CIDR ranges (xx.xx.xx.xx/mask)
- apply action permanently or with expiry timeout
- keep IP/range whitelist - actions related to whitelisted IPs are ignored what prevents locking out the legitmate clients
- serialize requests to prevent concurrency issues with iptables
- REST API
- secured with SSL
- authenticated with basic authentication over SSL and by client IP address
- idempotent - actions resulting in duplicate entries are ignored
- do not interfere with more general iptables rules
| rfw REST API | iptables command |
|---|---|
| PUT /drop/input/eth0/11.22.33.44 | Block incoming packets from 11.22.33.44 on eth0. In other words: Insert the DROP rule on INPUT chain to drop packets with source IP 11.22.33.44 on network interface eth0. Translates to the command: iptables -I INPUT -i eth0 -s 11.22.33.44 -j DROP |
| DELETE /drop/input/eth0/11.22.33.44 | Delete the above rule. Translates to: iptables -D INPUT -i eth0 -s 11.22.33.44 -j DROP |
| PUT /accept/output/any/192.168.0.0/24 | Allow outgoing traffic to 192.168.0.0/24 subnet on any interface. Translates to: iptables -I OUTPUT -d 192.168.0.0/24 -j ACCEPT |
| PUT /accept/forward/ppp/1.2.3.0/24/eth0/5.5.5.5 | Allow forwarding packets with source address in subnet 1.2.3.0/24 and destination address 5.5.5.5 from any ppp interface to eth0. Translates to: iptables -I FORWARD -i ppp+ -o eth0 -s 1.2.3.0/24 -d 5.5.5.5 -j ACCEPT |
| PUT /drop/input/any/11.22.33.44/?expire=600 | Block incoming packets from 11.22.33.44 on any interface for 10 minutes: iptables -I INPUT -s 11.22.33.44 -j DROP |
| GET /list/input | Return the list of existing rules in JSON format. Sample output: [{"chain": "INPUT", "num": "1", "pkts": "0",
"bytes": "0", "target": "DROP", "prot": "all",
"opt": "--", "inp": "*", "out": "*",
"source": "22.22.22.0/24",
"destination": "0.0.0.0/0", "extra": ""},
{"chain": "INPUT", "num": "2", "pkts": "0",
"bytes": "0", "target": "DROP", "prot": "all",
"opt": "--", "inp": "*", "out": "*",
"source": "11.22.33.44",
"destination": "0.0.0.0/0", "extra": ""}]
|
Requires Python 2.7
Install from PyPI:
pip install rfw
or from tarball:
tar xf rfw-X.X.X.tar.gz cd rfw-X.X.X ./setup.py install
Generate keys and certificates with config/deploy/rfwgen:
./rfwgen <server_ip>
See rfwgen README for more details.
Fill blanks in configuration file /etc/rfw/rfw.conf and /etc/rfw/white.list.
Run in verbose mode with default config file:
rfw -v
Test with curl:
curl -v --cacert config/deploy/client/ca.crt --user myuser:mypasswd -XPUT https://<server_ip>:7393/drop/input/eth0/1.2.3.4
or when testing on localhost you can skip certificate verification:
curl -v --insecure --user myuser:mypasswd -XPUT https://127.0.0.1:7393/drop/input/eth0/1.2.3.4
or when local.server enabled there is no authentication:
curl -v -XPUT http://localhost:7390/drop/input/eth0/1.2.3.4
You still need to be root. Unzip tarball, cd to project folder:
sudo bin/rfw -f config/rfw.conf --logfile=rfw.log
Q: Why not use chef/puppet/ansible/salt/fabric/ssh for remote management instead?
- Security, trust and permission management. The above tools require giving a remote client the ssh root acces. Often we want to allow the IP analytics server to be able to block selected IPs without giving admin rights.
- Performance
- Handle frequent and concurrent requests
- No dependencies and easy to talk to from any platform and language via REST API
- Protection against locking yourself out by applying wrong rule
Note that when the rules come from variuos sources they may interact badly. For firewalls the order of rules matters. That's why the functionality of remote rfw is limited to blocking individual IPs inserted in front of the ruleset.
Q: rfw limits REST client access by IP whitelisting. What if I need to connect from dynamic IP?
rfw is intended for hosts with static IP addresses. It includes both servers and clients. For clients it is not as strong requirement as it seems since in typical rfw deployment the client is a data center collocated machine with static IP. If you really need to use REST client from various locations or from dynamic IP, you have a couple of options:
- If you have any server with static IP with SSH access use it as a gateway client to rfw.
- If you have dynamic IP from particular address pool assigned to your Internet Service Provider you may whitelist the entire address range.
- You can connect through VPN with static IP and whitelist that IP.
Q: Is it secure?
Tampering with the core firewall should never be taken lightly. rfw must be run with root privileges in order to modify iptables so it requires a lot of trust in the software. Sometimes there is no choice and you have to automate firewall actions across individual boxes anyway. Then rfw makes it more secure because the remote client does not need to have full access to the host and can only block/allow IP addresses using rfw API. While rfw is designed with distributed system in mind, it may also improve security even for a single box by:
- limiting iptables functionality to only simple rules
- whitelisting selected IP addresses to prevent lock out
- serializing iptables modifications
Security of rfw was the primary concern from the very beginning and influenced these design decisions:
- simplicity
- no fancy features
- no external dependencies except iptables
- limited functionality
- no generic rules
- not performance-optimal but conservative choice of time-proven crypto: 2048-bit RSA based SSL with HTTP Basic Authentication
Copyrite (c) 2014 SecurityKISS Ltd, released under the MIT License