rfw - remote firewall

Remote firewall with a 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.

Typical use cases

1. 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.
2. 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.
3. You forward ports to various devices in your network. Each of the devices has a local installation of fail2ban and the rules need to be propagated to the edge router.

Features

• 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

Examples

There are two endpoints; /rule and /chain

Chains

Create

PUT /chain

Body:
{
  "name": "chain0"
}

Delete

DELETE /chain

Body:
{
  "name": "chain0"
}

Rules

Create

PUT /rule

Body:
 {
    "chain": "f2b-test",
    "target": "REJECT",
    "prot": "all",
    "opt": "--",
    "inp": "eth0",
    "out": "*",
    "source": "1.2.3.4",
    "destination": "0.0.0.0/0",
    "sport": null,
    "dport": "ssh"
  }

Will create a rule in the f2b-test chain rejecting ssh requests from 1.2.3.4.

Delete

DELETE /rule

Body:
 {
    "chain": "f2b-test",
    "target": "REJECT",
    "prot": "all",
    "opt": "--",
    "inp": "eth0",
    "out": "*",
    "source": "1.2.3.4",
    "destination": "0.0.0.0/0",
    "sport": null,
    "dport": "ssh"
  }

Will delete the rul you just added above.

Run rfw without installing

You still need to be root. Unzip tarball, cd to project folder::

sudo bin/rfw -f config/rfw.conf --logfile=rfw.log

FAQ

Q: 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.
• 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

License

Copyrite (c) 2014 SecurityKISS Ltd (c) 2018 Alok G Singh released under the MIT License

Yes, Mr patent attorney, you have nothing to do here. Find a decent job instead. Fight intellectual "property".