Package: rfw
Remote firewall with REST API.rfwis the RESTful server which applies iptables rules to block or allow IP addresses on request from a remote client.rfwmaintains the list of blocked IP addresses which may be updated on the fly from many sources.rfwalso solves the problem of concurrent modifications to iptables since the requests are serialized.Typical use casesYou 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 thetutorial with exampleFeaturesblock/allow IP addresses with iptables on request from remote hosthandle individual IP or CIDR ranges (xx.xx.xx.xx/mask)apply action permanently or with expiry timeoutkeep IP/range whitelist - actions related to whitelisted IPs are ignored what prevents locking out the legitmate clientsserialize requests to prevent concurrency issues with iptablesREST APIsecured with SSLauthenticated with basic authentication over SSL and by client IP addressidempotent - actions resulting in duplicate entries are ignoreddo not interfere with more general iptables rulesExamples:rfw REST APIiptables commandPUT /drop/input/eth0/11.22.33.44Block 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 DROPDELETE /drop/input/eth0/11.22.33.44Delete the above rule. Translates to:iptables -D INPUT -i eth0 -s 11.22.33.44 -j DROPPUT /accept/output/any/192.168.0.0/24Allow outgoing traffic to 192.168.0.0/24 subnet on any interface. Translates to:iptables -I OUTPUT -d 192.168.0.0/24 -j ACCEPTPUT /accept/forward/ppp/1.2.3.0/24/eth0/5.5.5.5Allow 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 ACCEPTPUT /drop/input/any/11.22.33.44/?expire=600Block incoming packets from 11.22.33.44 on any interface for 10 minutes:iptables -I INPUT -s 11.22.33.44 -j DROPGET /list/inputReturn 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": ""}]DeploymentRequires Python 2.7Install from PyPI:pip install rfwor from tarball:tar xf rfw-X.X.X.tar.gz
cd rfw-X.X.X
./setup.py installGenerate keys and certificates with config/deploy/rfwgen:./rfwgen <server_ip>Seerfwgen READMEfor 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 -vTest with curl:curl -v --cacert config/deploy/client/ca.crt --user myuser:mypasswd -XPUT https://<server_ip>:7393/drop/input/eth0/1.2.3.4or 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.4or whenlocal.serverenabled there is no authentication:curl -v -XPUT http://localhost:7390/drop/input/eth0/1.2.3.4Run rfw without installingYou still need to be root. Unzip tarball, cd to project folder:sudo bin/rfw -f config/rfw.conf --logfile=rfw.logFAQQ: Why not use chef/puppet/ansible/salt/fabric/ssh for remote management instead?For a couple of reasons: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.PerformanceHandle frequent and concurrent requestsNo dependencies and easy to talk to from any platform and language via REST APIProtection against locking yourself out by applying wrong ruleNote 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 ruleswhitelisting selected IP addresses to prevent lock outserializing iptables modificationsSecurity of rfw was the primary concern from the very beginning and influenced these design decisions:simplicityno fancy featuresno external dependencies except iptableslimited functionalityno generic rulesnot performance-optimal but conservative choice of time-proven crypto: 2048-bit RSA based SSL with HTTP Basic AuthenticationLicenseCopyrite (c) 2014SecurityKISS Ltd,
released under theMIT LicenseYes, Mr patent attorney, you have nothing to do here. Find a decent job instead.Fight intellectual “property”.CHANGESv0.0.1,  2014-03-05 – Initial release.v0.1.2,  2014-03-25 – Deployment ready.v0.1.19, 2014-03-26 – Multiple fixes: non-restful mode, README, PUT/DELETE actions, error handlingv0.2.2,  2014-04-08 – Fixes: umask, remove install warnings. Docs: link to the tutorial