-
Notifications
You must be signed in to change notification settings - Fork 0
/
ChangeLog
executable file
·128 lines (88 loc) · 7.47 KB
/
ChangeLog
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
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
Changelog
---------
2015-05-02:
========================
Reorganizing https handdling:
Created the struct ssl_connection in /tls/tls.c. All related fields that where incorrectly located in http_request are here now.
2015-02-10:
Changes in function peer_arp_dns so now it returns a non null value, which is th MAC of the client terminal it's been asked for. In previous version it passed the
MAC value in a pointer passed.
The initialization of NFQUEUE interface was changed to a single function (initialize_queue), to which is passed as parameters the queue number as well as a callback function.
Starting to work on support for https:
queue nfq_ssl_callback in user space for keeping a relational table between client connections and real server ip. This is for ussing later in the sniffing proccess.
In the redirect to port 5281 it's lost the real server ip.
Added two servers:
- first on port 5281 listening on port 443.
- second on port 5282 of lo. A bridge is created to this from the previous for intercepting ssl and capture the SNI.
As a start the needed fields to work with https where added to the structure http_request, which is not correct because an https connection is not part of an
http request. This will be fixed in next version.
2014-11-01:
========================
Lot of fixes. First version for production.
2014-10-05:
========================
Going back to previous approach of grace / punishment periods. Yet keeping the use of iptables queue handdling in user space to make decisions (not DNS, this has been removed)
Some other changes:
- Added traffic counters to better determine the punishment to the client. The idea is that if the traffic is not from outside the authentication server urls then probably the
delay is just because bad network conditions or the client not paying attention for whatever reason, so it makes no so much sense to punish.
2014-10-02:
========================
Removing the grace and punishment periods. First "functional" testing version based in the new approach.
2014-09-15:
========================
Implementing a new approach on how to control the access of the client to Internet based on tracking the url / ips the client is requesting,
and comparing against a known table of authorized url for the phase the client is currently. This table is populated with the own DNS requests from
the client.
The software need to have a table of known urls the client will be authorized to access during the different authentication phases. This table will be provided
by the central server using the websocket interface on device start (and probably actualized periodically). Let's say this device will implement "facebook
authentication", then the central server will be provided a list like: www.facebook.com, m.facebook.com, p.facebook.com, etc. to populate the table. The urls of the
central server will exist in this table always, as it will always be necessary that the client access the central server in the first stages of the auth proccess.
When the client ask for dns information about an url, lets say www.facebook.com, the answer to the request is checked against the known urls table and if in the
later there exists a record for that url then the ip is stored in the table. For each url in the table could be several ips, as is logic.
When later the client makes any http request, the ip packages are intercepted and it's destination address is checked against the allowed urls table, if the corresponding
url for the ip is allowed for the current authentication phase in which the client in on, then the packet is allowed.
The previously implemented periods will continue to exist as well as the punishment functionality.
2014-09-09:
========================
Added the "punishment" function to clients who navigate during the grace period without being authenticated. If the grace period passes and the client
has not been authenticated on the server (the device has not received the signal that the client performed the authentication correctly) the client is
disabled for a period of time determined by the variable in the configuration file "LoginPunish" and on any attempt to connect to the internet via http,
it's shown a page informing him that must wait for the punishment time before trying to connect again.
This function is controlled by the "AllowPunishment" variable of the configuration file, which defaults to 0 (the function of punishment).
2014-09-03:
========================
Changed the mechanism for checking the connection time of users to the system. Now the program does not have a control of the connected users
but in the "access.fw" file, when the rules are added to iptables that allow the user to pass through the firewall, these are
setted with a validity time, using the "time" module of iptables with its variables "timestart", "timestop" and "kerneltz":
iptables -t mangle ... -m time --timestart $ start --timestop $ end --kerneltz ...
iptables -t filter ... -m time --timestart $ start --timestop $ end --kerneltz ...
This time of validity depends on whether it is in time of authentication (LoginGrace) or fully authenticated (LoginTimeOut).
This new variant allows that if the program crash, the users that are connected at that moment, are kept completely controlled, since
the connection time control is still in iptables.
4 tables were created in iptables: NoCat_Inbound0 and NoCat_Inbound1 in replacement of NoCat_Inbound in the filter table, and NoCat0 and NoCat1 in substitution
of NoCat in the mangle table. This is to selectively eliminate the rules of the users that are becoming obsolete. For this a function was created
of timeout that is executed at a time: "LoginTimeOut + 1 minute" and that changes the active tables for the insertion of the new rules. Before a table is activated,
it is completely cleaned. That the time of change of tables is "LoginTimeOut + 1 minute" guarantees that when a table is cleaned in it there is no rule of an active user:
LoginTimeOut + 1m LoginTimeOut + 1m LoginTimeOut + 1m
-------------------------------------------- -------------------------------------------- --------------------------------------------
| table NoCat_Inbound0 active | table NoCat_Inbound1 active | table NoCat_Inbound0 active |
-------------------------------------------- -------------------------------------------- --------------------------------------------
| | |
| | |
|_________________LoginTimeOut_______________| |
|
X user allowed in firewall |
|
|
V
Here the table NoCat_Inbound0 gets cleaned before
been used again. The user X will have spend it's
connection time because it will pass more than
LoginTimeOut.
A check was made as to whether the program ended correctly or not before loading the firewall rules at the start of the program. This is to avoid
restarting the iptables firewall rules in case the program crash, so that the rules of active clients are maintained.
This check was implemented based on a file that is created in the / tmp directory, which in mikrotik devices is in operational memory.
The only way this file is deleted is if the device is reset (or if the program closes correctly, which should not happen during the
normal work of this).
A memory usage check was created, if it passes from a higher limit set in the memlimit variable of the configuration file the program will be
close, giving m'argen for the csicatd daemon to restart the program.