-
Notifications
You must be signed in to change notification settings - Fork 66
/
TODO.txt
61 lines (54 loc) · 5.07 KB
/
TODO.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
TODO
---------------------------------
- GET / - list rules - implement GET and formatting output rules list. JSON export format. 'Accept:' http header.
- curl GET, PUT, DELETE, POST examples with various headers (like Accept: json or xml or text for GET)
- both remote and local interface: SSL secured that can listen on any available network interface and plain HTTP that can listen only on localhost
- local client (rfwc) with syntax identical to iptables which acts as the iptables guard
- consider user/passwd authentication for localhost server
- rfwc comment: "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. Be careful when using local rfwc where you have the full power of iptables at hand."
- Describe the above in docs: "To prevent nasty surprises we explain here how rfw interacts with iptables. The impact is as minimal as possible. At start rfw inserts the following rules:
- on INPUT/OUTPUT insert block all IPs to/from the tcp rfw port
- on INPUT/OUTPUT insert allow white.list IPs to/from tcp rfw port
- use iptables state module to accept/block ESTABLISHED connections
- iptables - why use connection tracking?
- review README
- tidy up REST verb functions on sslserver, add the bulk update role for POST
- use PUT and DELETE - should be idempotent. Give the option on non-restful requests with GET and additional ?verb=PUT/DELETE param in query
- Clarify responsibilities of rfw and rfwc
- rfw need to store credentials in config file so it shouldn't be mixed with rfwc
- rfwc should be the lightweight http client submitting jobs to rfw
- rfwc may take arguments in 2 forms:
- single line rule to mimic iptables interface
- multiline bash scripts with iptables commands
- rfw/rfwc should guarantee executing multiline scripts in order while being uninterrupted by other rfw requests
- both rfw and rfwc should accept -v/-h options
- show examples of using rfwc as iptables replacement:
- as rfwc <iptables args> - should be synchronous to be able to report errors
- as symbolic link for global iptables substitution - synchronous
- as rfwc without command line options but reading scripts from standard input - asynchronous
- as above but with -b batch_file.sh option instead of standard input - asynchronous
- if you want the 2 above make synchronous i.e. to wait for the rfw to finish processing iptables commands, simply call rfwc again with --wait flag. There should be a special call to rfw that does not return response until the queue is empty.
- expand documentation, more use cases
- run as daemon (check fail2ban code), add --non-daemon option at rfw startup
- create symlink in bin folder by setup.py
- bulk updates in order to sync client blocklist with rfw status - ??
It doesn't seem to be a good idea. Keep it simple, move sync responsibilty to the client. Let the client GET the rules list and PUT the missing ones.
- when available use ipset for high performance
- test and document using rfw with fail2ban
- initialize iptables with static set of rules - ?? not sure if needed
- consider adding REST command 'do not accept new connections' which inserts -m state connection tracking rule. Potential problems: must obey extended whitelist - other legitimate clients/IPs should be included. Requires intensive testing. /input/eth/freeze. Seems useful for VPN with long lasting connections but not so much for stateless web traffic.
- consider adding option for narrowing down the scope of block/allow IP command with port range. It should be optional in query params: ?port_start=1&port_end=1023 It may be useful for blocking
low port scanning by ShieldsUp like services, while not blocking the website itself - however it should work anyway without IP range because port scanning hits the INPUT chain while website browsing hits FORWARD chain (after SNAT).
- how about symmetric rules? When blocking IP on INPUT we also want to block on OUTPUT chain. Add /io/ chain? Apply connection tracking? Better no. Additional dependency on ip_conntrack module.
- consider enhanced REST API (+target, +ranges, +flags) :
/drop/input/eth0/1.2.3.4/32/?expire=120
/accept/io/any/3.3.3.3/24/?established_only=true
/reject/input/any/4.4.4.4/
DELETE /drop/input/eth0/1.2.3.4/16 - should it delete existing more specific rules? KIS: No, simply report no such rule
established_only and other possible flags should be implemented as plugins OR make it more generic: flags SYN, RST, ACK in query parameters
- note that unfirewalled, closed ports respond with RST ACK on SYN
- warn in docs that rfw is applying INSERTs and not APPENDs - this order is more convenient for going from general rules to more specific. The new overlapping rule supersedes the old one.
- consider scenario:
- adding the same rule with expiry timeouts
- adding the second one will trigger duplicate warning
- client may want to reset expiry timeout (reset_expire=...) - update entry in expiry_queue