Kimai2: Request GeoIP authentication policy framework

[miketubby]

Is your feature request related to a problem? Please describe.
With Working From Home (WFH) teams have to be able to access development and administration systems over the public internet. It would be a "really good feature"(tm) to implement a GeoIP based authentication policy so that username/password + country of origin are considered at login.

Describe the solution you'd like
There are several GeoIP providers like Maxmind and DBIP.
DBIP has a couple of advantages:

1. Its highly optimised database schema makes it really fast
2. It comes with a PHP class that wappers all the functionality making it quick and easy to add to PHP based systems

Describe alternatives you've considered
Creating a Nginx+PHP based frontend/proxy with DBIP

Additional context
Doing GeoIP at the application layer - as part of authentication policy is more flexible and less resource hungry than trying to implement it at the packet layer, i.e. firewall, and is universal across all platforms.

[adrianrudnik]

Just doing a sanity check here: It sounds fine at first but what is the exact benefit from this when everyone could just buy a VPN or virtual server with router into the targets country? Both Maxmind and DBIP are paid services to analyse a source IP, not to provide an additional layer of security.

Any other solution would provide much more security than this approach:

a) let every employee dial in a VPN and route kimai specific target address through it
b) deploy SSO
c) deploy 2FA

As someone who dealt with people near country borders and roaming in the past, this has been a hassle and I'm not sure this would solve or improve something.

[miketubby]

On 03/05/2020 21:36, Adrian Rudnik wrote:
>

Just doing a sanity check here: It sounds fine at first but what is
the exact benefit from this when everyone could just buy a VPN or
virtual server with router into the targets country? Both Maxmind and
DBIP are paid services to analyse a source IP not provide additional
security.

Any other solution would provide much more security than this approach:

a) let every employee dial in a VPN and route kimai specific target
address through it
b) deploy SSO
c) deploy 2FA

As someone who dealt with people near country borders and roaming in
the past, this has been a hassle and I'm not sure this would solve or
improve something.

Due to Coronavirus and Working From Home, we need flexibility for work
force to work from work, home broadband, mobile broadband, mobile
devices like never before.

With email we have both mail relays and our end-point server
(mail.example.com) on the public internet.  Endpoint server
mail.example.com runs Dovecot+Exim and we have implemented GeoIP as an
additional security layer:

    * Dovecot already has an Authentication Policy Server (APS)
hard-wired into the code - all I had to do was provide a web services
backend

    * Exim didn't have an APS built in but had an extensible
authentication framework so it was a small amount of work to mimic the
APS that Dovecot uses

both of these now check username/password and 'remote IP address'.

We started using Maxmind but switched to DBIP.  Both Maxmind and DBIP
provide community (free) and full (paid for) editions.  DBIP is easier
to use as it comes with a PHP Class that does the heavy lifting.

We now authenticate email users (IMAP and SMTP) on a tuple:

    Username
    Password
    Country of origin

As Kamai is a web service, placing it at work, but hosted on the public
internet, seems to be an obvious thing to do at this time when everybody
needs access, i.e. with a site like:

    https://timesheet.example.com

as it means that people (employees) can use desktop, tablet and mobile
phones - from any vendor - with any OS - from any (authorised) place.

The primary issue - as we see it - is that providing easy-to-use widely
available platform access opens up system to extensive probing and brute
force attacks that are easily mitigated by way of authentication policy

• for example 'country of origin' and hence the feature request.

The secondary issue, is that if you are implementing systems that are
compliant to ISO27001 you need to provided a range of 'controls' and
'monitoring'.  Implementing an authentication policy frame work goes a
long way towards satisfying the requirements for controls and monitoring.

The problem is that, these days, you need to implement security in
"strength and depth".  One useful factor is country of origin.  For
example I have no employees in Russia, Thailand, China, South Africa,
Brazil or the United States of America.  So simply denying logins from
these locations goes a long way towards an integrated security policy.

I have included a small excerpt of the info that we log currently on our
mail server - I have excluded successful logins  - it shows that logins
failed due to policy and the origin country.  Users' domain replaced
with example.com to protect the innocent.

This access policy achieved with a web services call from Dovecot or
Exim to a policy server that I wrote in a few lines of PHP with the free
version of DBIP.  Happy to share the source code.

Regards

Mike Tubby

+-------+---------------------+----------+----------------------------+----------------------------------------+---------+---------+---------------+
| id    | datetime            | protocol | username                   |
remote_ip                              | country | auth_ok | policy_reject |
+-------+---------------------+----------+----------------------------+----------------------------------------+---------+---------+---------------+
| 82261 | 2020-04-30 23:34:08 | IMAP     | mike.[email protected]     |
183.88.234.59                          | TH      |       0 |             1 |
| 82266 | 2020-04-30 23:47:28 | IMAP     | mike.[email protected]     |
61.91.164.142                          | TH      |       0 |             1 |
| 82282 | 2020-05-01 00:16:57 | IMAP     | mike.[email protected]     |
107.5.156.222                          | US      |       0 |             1 |
| 82284 | 2020-05-01 00:19:51 | IMAP     | mike.[email protected]     |
185.221.253.95                         | AL      |       0 |             1 |
| 82292 | 2020-05-01 00:35:04 | IMAP     | mike.[email protected]     |
61.6.201.210                           | BN      |       0 |             1 |
| 82338 | 2020-05-01 01:56:36 | SMTP     | [email protected]            |
178.176.175.100                        | RU      |       0 |             1 |
| 82428 | 2020-05-01 04:39:03 | IMAP     | james.[email protected]    |
171.100.10.250                         | TH      |       0 |             1 |
| 82434 | 2020-05-01 04:48:13 | IMAP     | james.[email protected]    |
184.176.166.17                         | US      |       0 |             1 |
| 82443 | 2020-05-01 05:01:25 | SMTP     | [email protected]     |
178.176.175.100                        | RU      |       0 |             1 |
| 82500 | 2020-05-01 06:39:54 | IMAP     | james.[email protected]    |
202.137.141.243                        | LA      |       0 |             1 |
| 82528 | 2020-05-01 07:23:28 | IMAP     | james.[email protected]    |
115.84.112.138                         | LA      |       0 |             1 |
| 83114 | 2020-05-01 16:51:12 | SMTP     | [email protected]            |
178.176.174.234                        | RU      |       0 |             1 |
| 83282 | 2020-05-01 23:20:27 | SMTP     | [email protected]            |
171.103.56.54                          | TH      |       0 |             1 |
| 83283 | 2020-05-01 23:20:31 | SMTP     | sam                        |
171.103.56.54                          | TH      |       0 |             1 |
| 83284 | 2020-05-01 23:20:56 | SMTP     | [email protected]            |
171.103.56.54                          | TH      |       0 |             1 |
| 83285 | 2020-05-01 23:21:01 | SMTP     | sam                        |
171.103.56.54                          | TH      |       0 |             1 |
| 83379 | 2020-05-02 04:37:02 | SMTP     | [email protected]     |
178.176.174.213                        | RU      |       0 |             1 |
| 83392 | 2020-05-02 05:18:49 | SMTP     | [email protected]     |
188.162.43.83                          | RU      |       0 |             1 |
| 83393 | 2020-05-02 05:27:16 | SMTP     | [email protected]     |
188.162.43.83                          | RU      |       0 |             1 |
| 83514 | 2020-05-02 10:34:23 | IMAP     | [email protected]          |
92.115.19.96                           | MD      |       0 |             1 |
| 83516 | 2020-05-02 10:40:17 | IMAP     | [email protected]          |
220.156.161.77                         | NC      |       0 |             1 |
| 83538 | 2020-05-02 11:24:48 | IMAP     | chris.[email protected]      |
177.43.251.153                         | BR      |       0 |             1 |
| 83561 | 2020-05-02 12:13:54 | IMAP     | chris.[email protected]      |
41.210.49.98                           | GH      |       0 |             1 |
| 83602 | 2020-05-02 14:11:10 | IMAP     | chris.[email protected]      |
61.91.180.82                           | TH      |       0 |             1 |
| 83607 | 2020-05-02 14:13:52 | SMTP     | [email protected]            |
188.162.199.198                        | RU      |       0 |             1 |
| 83615 | 2020-05-02 14:18:58 | IMAP     | [email protected]            |
213.154.11.207                         | AZ      |       0 |             1 |
| 83630 | 2020-05-02 15:18:13 | IMAP     | sam.[email protected]     |
183.89.212.68                          | TH      |       0 |             1 |
| 83645 | 2020-05-02 15:56:28 | IMAP     | [email protected]          |
183.89.237.126                         | TH      |       0 |             1 |
| 83682 | 2020-05-02 17:00:03 | IMAP     | chris.[email protected]      |
183.89.212.168                         | TH      |       0 |             1 |
| 83684 | 2020-05-02 17:03:44 | IMAP     | [email protected]          |
220.156.167.132                        | NC      |       0 |             1 |
| 83694 | 2020-05-02 17:33:47 | IMAP     | [email protected]            |
113.21.120.198                         | NC      |       0 |             1 |
| 83711 | 2020-05-02 18:31:04 | IMAP     | sam.[email protected]     |
102.67.19.2                            | NG      |       0 |             1 |
| 83721 | 2020-05-02 18:56:58 | IMAP     | [email protected]            |
183.89.212.90                          | TH      |       0 |             1 |
| 83753 | 2020-05-02 20:17:11 | IMAP     | [email protected]            |
177.135.101.5                          | BR      |       0 |             1 |
| 83783 | 2020-05-02 21:55:24 | IMAP     | [email protected]        |
171.103.8.214                          | TH      |       0 |             1 |
| 83823 | 2020-05-02 23:42:13 | IMAP     | [email protected]           |
188.191.235.237                        | UA      |       0 |             1 |
| 83830 | 2020-05-03 00:15:27 | IMAP     | andy.[email protected]     |
177.43.251.153                         | BR      |       0 |             1 |
| 83847 | 2020-05-03 01:24:08 | IMAP     | andy.[email protected]     |
183.89.237.234                         | TH      |       0 |             1 |
| 83852 | 2020-05-03 01:44:22 | IMAP     | andy.[email protected]     |
202.72.243.198                         | MN      |       0 |             1 |
| 83855 | 2020-05-03 01:53:20 | IMAP     | [email protected]        |
105.255.158.250                        | ZA      |       0 |             1 |
| 83879 | 2020-05-03 03:19:03 | IMAP     | [email protected]           |
200.175.104.103                        | BR      |       0 |             1 |
| 83886 | 2020-05-03 03:59:00 | IMAP     | [email protected]           |
113.161.151.29                         | VN      |       0 |             1 |
| 83939 | 2020-05-03 06:56:28 | SMTP     | mike.[email protected]     |
212.98.158.226                         | LB      |       0 |             1 |
| 83940 | 2020-05-03 06:56:29 | SMTP     | mike.[email protected]     |
212.98.158.226                         | LB      |       0 |             1 |
| 83941 | 2020-05-03 06:59:16 | IMAP     | [email protected]           |
14.232.243.231                         | VN      |       0 |             1 |
| 83959 | 2020-05-03 07:44:36 | IMAP     | andy.[email protected]     |
220.156.166.179                        | NC      |       0 |             1 |
| 83963 | 2020-05-03 07:50:06 | IMAP     | [email protected]           |
183.89.212.15                          | TH      |       0 |             1 |
| 83973 | 2020-05-03 08:36:20 | IMAP     | andy.[email protected]     |
220.124.240.66                         | KR      |       0 |             1 |
| 83984 | 2020-05-03 09:10:26 | IMAP     | [email protected]           |
203.147.64.98                          | NC      |       0 |             1 |
| 83991 | 2020-05-03 09:32:41 | IMAP     | [email protected]           |
109.166.89.83                          | SA      |       0 |             1 |
| 83993 | 2020-05-03 09:34:11 | IMAP     | andy.[email protected]     |
174.76.35.25                           | US      |       0 |             1 |
| 84002 | 2020-05-03 09:55:54 | IMAP     | [email protected]           |
187.58.134.87                          | BR      |       0 |             1 |
| 84003 | 2020-05-03 09:55:54 | IMAP     | [email protected]           |
203.147.64.159                         | NC      |       0 |             1 |
| 84019 | 2020-05-03 10:41:15 | IMAP     | [email protected]           |
171.100.51.90                          | TH      |       0 |             1 |
| 84137 | 2020-05-03 17:16:27 | IMAP     | mike.[email protected]     |
54.89.143.171                          | US      |       0 |             1 |
+-------+---------------------+----------+----------------------------+----------------------------------------+---------+---------+---------------+

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/kevinpapst/kimai2/issues/1666#issuecomment-623177619,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAMCA2PZVXYA56C5KQVE27DRPXIUPANCNFSM4MRJFU6Q.

[BeckeBauer]

Might be off topic but have you considered to use fail2ban to improve security? I've been using it together with the kimai fail2ban plugin so that brute force attacks are not a big deal.
By the way, using kimai also on timesheets.mydomain.de but haven't noticed much attacks compared to the mail server with is daily attacked. Assuming that hacking a timesheet account is less intressting than a mail account.

[adrianrudnik]

That sounds valid, but as you mention it yourself: Would be an integration towards an external Authentication Policy Server (APS) not be preferable? So SSO would be still be preferable?

We started using Maxmind but switched to DBIP. Both Maxmind and DBIP
provide community (free) and full (paid for) editions. DBIP is easier
to use as it comes with a PHP Class that does the heavy lifting.

They are both commercial and provide "excellent support", i.e. maxmind also comes with composer related classes geoip2/geoip2 and is event supported officially through https://www.php.net/manual/en/book.geoip.php.

ISO27001

that's a pretty hard and harsh requirement. You either certify for that or dont right? You still need an audit for that and that would never be a part of this project but of an external auditor if I'm not mistaken? Sure, you could just say you support it, but to get it really done, you need external auditors checking your whole net, not just this app.

Also, as you already mentioned it yourself, Nginx would come with http://nginx.org/en/docs/http/ngx_http_geoip_module.html which allows for fast and accelerated geo ip blocks, not relying on a php frameworks bootup time to reject invalid requests.

I might sound harsly critic. I'm all for improving security, but this project is not about that and is easily passed through a reverse proxy that could resolve this topic on corporate scale.

This is just to prevent a simple misassumption that a small open source projects should handle corporate requirements for a coherent security concept outside of username / password / 2fa. If you want to deploy it, would'nt it fit to every application you move to home office requirements?

[plutocrat]

"Doing GeoIP at the application layer - as part of authentication policy is more flexible and less resource hungry than trying to implement it at the packet layer, i.e. firewall"
Almost exactly the opposite in fact! Much less resource intensive to stop it before it hits the application! I'd vote for implementing this through firewall rules (eg CSF), or an external device, a reverse proxy, or apache/nginx modules/rules rather than complicating the code.

[kevinpapst]

Thanks for all of your interesting inputs!

I have no plans of implementing such a feature, so I am going to close here.