profxadke/captive.whump.shanti-portal
1
0
Fork 0
mirror of https://codeberg.org/prof_x_pvt_ltd/captive.whump.shanti-portal synced 2024-08-14 22:46:42 +00:00
Code Issues Projects Releases Packages Wiki Activity

document the recent changes

Browse source
This commit is contained in:
Stefan Midjich 2017-11-15 18:48:44 +01:00
parent 8316a43805
commit ca75f7670d
1 changed files with 21 additions and 9 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

30
README.md
View file

@ -51,18 +51,19 @@ See examples in docs/examples directory, along with all the cfg examples in the
First and foremost all traffic in a network must be routed through the server running this software stack. First and foremost all traffic in a network must be routed through the server running this software stack.
* IPtables * IPtables & ipset
* Captiveportal portal web app * Captiveportal portal web app
* Associated tools must be setup here * Associated tools must be setup here
## Portal web app ## Portal web app
All this is of course triggered by the portal application written in Python using Bottle. All this is works with the portal application written in Python3 using Bottle.
1. A clients redirected HTTP traffic puts them in the portal webpage. 1. A clients redirected HTTP traffic puts them in the portal webpage.
2. They send a POST form to the /approve url. This can be with user info, personal info, or simply an approve button for a EULA. 2. Hijacked DNS ensures that all their HTTP requests end up on the portal server, also triggering wifi hotspot prompts on devices.
3. The portal executes its plugins in the order that their config section appears in plugins.cfg. 3. They send a POST form to the /approve url. This can be with user info, personal info, or simply an approve button for a EULA.
4. Each plugin is passed the request object from Bottle which contains form values among other things. 4. The portal executes its plugins in the order that their config section appears in plugins.cfg.
5. Each plugin is passed the request object from Bottle which contains form values among other things.
## IPtables ## IPtables
@ -71,8 +72,9 @@ At the heart is iptables doing the following.
1. Labeling all traffic with the number 99 in the mangle table. 1. Labeling all traffic with the number 99 in the mangle table.
2. Labeled ICMP, DNS and HTTP traffic is redirected to the portal server in the nat table. 2. Labeled ICMP, DNS and HTTP traffic is redirected to the portal server in the nat table.
3. All other labeled traffic is dropped. 3. All other labeled traffic is dropped.
4. Authenticated clients are jumped out of the mangle table before being labeled, using the RETURN target. 4. Authenticated clients are put into an ipset.
5. Authenticated clients are also deleted from conntrack after having their exception rules created in the mangle table. 5. Any packet matching an IP in the ipset is jumped out of the mangle table before being labeled, using the RETURN target.
6. Along with adding or removing IPs to an ipset, the IP is also handled by conntrack to ensure that no old connections linger.
## Plugins ## Plugins
@ -94,11 +96,21 @@ Also with plugins there are options to connect other authentication methods like
### Available Plugins ### Available Plugins
There's only one relevant plugin right now, iptables. But the idea is that you could add RADIUS plugins or other services. The mandatory flag in plugins.cfg decides if a plugin must pass before a client is authenticated. So you can string several plugins together for several actions that must be performed. The idea is that you could add RADIUS plugins or other services. The mandatory flag in plugins.cfg decides if a plugin must pass before a client is authenticated. So you can string several plugins together for several actions that must be performed.
Each plugin responds with JSON. Each plugin responds with JSON.
#### iptables plugin #### iptables
**DEPRECATED IN FAVOR OF IPSET**
1. Executes the ``iptables_cmd`` defined in plugins.cfg, with arguments being the client IP and potentially the client MAC address. 1. Executes the ``iptables_cmd`` defined in plugins.cfg, with arguments being the client IP and potentially the client MAC address.
2. Ensures the exit code of ``iptables_cmd`` is 0, if not 0 it sets a failed flag in its JSON response. 2. Ensures the exit code of ``iptables_cmd`` is 0, if not 0 it sets a failed flag in its JSON response.
The only thing this plugin does, besides run the iptables command, is that it also attempts to lookup a HW address of the client through arp.
In the environment I made this app for the arp thing was impossible and iptables command is not concurrent so I've abandoned this plugin.
#### ipset
This plugin is also basically a wrapper around executing the ipset command but it makes no attempt to lookup a HW address in arp.