README.rdoc in firewool-0.1.1 vs README.rdoc in firewool-0.1.2
- old
+ new
@@ -1,32 +1,35 @@
== Firewool
Firewool is an IP firewall for rails. You set what IPs to block and what IPs to allow. Specifics below.
== Why would I need this?
-- A layer 7 firewall is too expensive.
-- Anonymous authentication doesn't equate to all access authorization.
+Using authentication to protect your app is great but sometimes you just want to do some simple IP filtering. Firewool can help you in the following use cases:
+- You have a report job that needs to hit /users/report and you want to restrict access without authentication, ie: you don't want to create a "report" user which might get reported on or otherwise makes you a sad panda.
+- A simple firewall with IP/ports (layer 3) can't protect rails URLs.
+- A layer 7 firewall which can protect URLs is too expensive / hard to set up.
- Belt and suspenders style double security check.
+- You killed your network guy and no one knows.
== Install
gem install firewool
- Tested on rails 3.0.4.
+- Tested on ruby 1.9.2 / 1.8.7.
- Untested on rails 2.x. Probably won't work because no engines.
== Configuration
-Add firewool and dependency to Gemfile:
+Add firewool dependency to Gemfile:
gem 'firewool'
- gem 'ipaddress'
Create a configuration file in config/firewool.yml
# config/firewool.yml
# changing any valves requires app server restart (apache/webrick/etc)
development:
ip_restriction: true
- allow: [ 192.168.0.0/16 ]
+ allow: [ 127.0.0.1 ]
test:
ip_restriction: false
production:
@@ -61,35 +64,38 @@
IPs can be spoofed so in the case of strong security, you'll want to use this with one or more factor authentication.
== Quick Network Primer
So how do I write the rules when I'm not a network guy? No problem, let's go through some examples.
-First, the IP is four numbers separated by periods. Each number is called an ocet. The slash number (like /16 up above) is how many octets match. So to match every usable IP from 10.0.0.1 to 10.0.0.254, we can just say:
- 10.0.0.0/24 (matches 10.0.0.*)
- 10.0.0.1 (match)
- 10.0.0.204 (match)
- 10.0.1.1 (no match)
- 7.8.9.10 (no match)
+First, the IP is four numbers separated by periods. Each number is called an ocet. The slash number (like /16 up above) is how many octets match. So to match every usable IP from 10.0.0.1 to 10.0.0.254, we can just say: 10.0.0.0/24 instead of naming all 253 ips one at a time.
+10.0.0.0/24 matches 10.0.0.* so the following happens:
+ 10.0.0.1 (match)
+ 10.0.0.204 (match)
+ 10.0.1.1 (no match)
+ 7.8.9.10 (no match)
+
If we just want to match one IP we can use the /32 or just specify the IP by itself.
192.168.0.1/32 (matches only 192.168.0.1)
- 192.168.0.1 (matches only 192.168.0.1, same meaning as /32)
- 5.0.0.0/8 (matches 5.*.*.*)
- 5.6.0.0/16 (matches 5.6.*.*)
- 5.6.0.0/24 (matches 5.6.0.*)
- 5.6.7.0/24 (matches 5.6.7.*)
+
+Some more examples:
+ 192.168.0.1 (matches only 192.168.0.1, same meaning as /32)
+ 5.0.0.0/8 (matches 5.*.*.*)
+ 5.6.0.0/16 (matches 5.6.*.*)
+ 5.6.0.0/24 (matches 5.6.0.*)
+ 5.6.7.0/24 (matches 5.6.7.*)
-These are the simplest examples of this notation (called CIDR if you want to read more) but it's enough to build a few use cases. Let's say we want to allow anyone from our company network but block anyone coming from Evil Hackers' Inc. Our company's external network is 5.6.7.* (ie: what users see when they go to whatismyip.com from inside their network) and let's say that Evil Hackers' proxy is 58.14.0.0. This would be our firewool.yml config:
+These are the simplest examples of this notation (called CIDR if you want to read more) but it's enough to build a few use cases. Let's say we want to allow our customers in but block anyone coming from Evil Hackers' Inc. Our customer's external network is 5.6.7.* (ie: what they see when they go to whatismyip.com) and let's say that Evil Hackers' proxy is 58.14.0.0. This would be our firewool.yml config:
production:
ip_restriction: true
allow: [ 5.6.7.0/24 ]
deny: [ 58.14.0.0/16 ]
-Now we'd want to be careful that 5.6.7.* was really where our users are coming from. If people that we want to keep out are coming from 5.6.7.200 then we'd want to tighten up our rule a little bit and not allow all of the 5.6.7.0 network in. Maybe we research what our IP block really is, or add only the IPs we know about as /32 IPs.
+Now we'd want to be careful that 5.6.7.* was really where our users are coming from. If another group of people that we want to keep out are coming from 5.6.7.200 then we'd want to tighten up our rule a little bit and not allow all of the 5.6.7.* network in because .200 is in 5.6.7.*. So we would research what our customer's IP block really is, or add only the IPs we know about as individual IPs.
-As a special case, 0.0.0.0 means *.*.*.*, or all IPs.
+As a special case, 0.0.0.0 means *.*.*.*, or all IPs. Also a special case, 127.0.0.1 means localhost which is good to leave in your development allow section so you can develop your app with firewool on.
-== Pretty up
+== Pretty Up
If 403.html doesn't exist in your public directory, then a blocked user will simply see "Public Access Denied." which isn't that great. Create a 403.html file in public, you can use this {403.html template as an example}[https://github.com/squarism/firewool/blob/master/test/dummy/public/403.html].
== Thanks to
-Bluemonk for his awesome ipaddress gem.
+{Bluemonk}[https://github.com/bluemonk] for his awesome ipaddress gem. And {sinisterchipmunk}[https://github.com/sinisterchipmunk] for his help in understanding how to test rails 3 gems quickly.