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
|
<!DOCTYPE html>
<html lang=en>
<head>
<title></title>
<meta charset="utf-8"/>
<link rel="shortcut icon" href="favicon.ico"/>
<link rel='stylesheet' type='text/css' href='style.css'/>
<meta name="viewport" content="width=device-width, initial-scale=1">
</head>
<body>
<header><h1 class=pagetop>Projects</h1></header>
<main>
<h2>mfa</h2>
<p><em>Check out the source code here - </em>
<a href=https://git.chudnick.com/mfa>git.chudnick.com/mfa</a></p>
<p><strong>mfa</strong> is a system for out-of-band multi-factor authentication with PAM.
My original reason for working on this was to get MFA functionality for a Postfix/Dovecot
mail server that uses PAM for authentication. Solutions such as pam_oath are not feasible
for this purpose because a mail client has no way of exposing an interface for the oath
challenge-response. Therefore a way to circumvent the original application to get the request
to the user is needed, which is what mfa does.</p>
<p>The design of mfa is not novel, it works the same way as Cisco's Duo. Duo does have open
source modules for achieving this objective, but all the authentication requests are
sent back to their proprietary "cloud" service. I'm sure that most free software
enthusiasts see this as a major red flag, especially for small personal use cases.</p>
<h3>Design</h3>
<p>mfa is primarily composed of three parts - the server, the client, and the PAM module.
The server listens for connections from both clients and PAM modules. The server receives a
request from a PAM module that includes the username of the user attempting to authenticate,
the hostname of the computer, and the service being accessed. The server then correlates the
combination of user, host, and service to a particular client, and attempts to push a request.
The server will then evaluate the client's response, and either return to the PAM module that
the user is authenticated or denied.</p>
<p>The server itself consists of two parts that I've called <strong>mfad</strong> and
<strong>mfac</strong>. mfad is the program responsible for doing what I've described above.
mfac is a command line utility that the administrator uses to configure the server. mfac is used
to enroll clients in the system and to provision applications. A client is enrolled by using the
--add-client option and providing an alias for that user. The server then assigns that user an
identifying key that is used to connect and a TOTP secret key. With the client enrolled, the
administrator can then assign applications to that client. With the --add-app command, the
administrator ties a username, hostname, and service combination to a client alias, so that
when that combination is seen the server knows who to ask for authentication. The administrator
also identifies which MFA methods are valid for this combination (currently either or both of
push and/or totp). The example below shows the process of enrolling a new client called
'tux' and then provisioning MFA for SSH attempts to tux@linux.example.org.</p>
<pre><code><em># Enroll a client named tux</em>
mfac --add-client tux
alias: tux
client key: VA32LB3SF2HG2FDWJS5XIOFVWTMBQYRSQ3PK3OOPA3FBIQMSMJZCXYJQCYKYUWUU
totp secret: TGGG3QCXA4MR2S2X6B33GSYN
uri: otpauth://totp/tux%40mfad?secret=TGGG3QCXA4MR2S2X6B33GSYN
<em># Provision MFA for SSH tux@linux.example.org allowing for both push authentication or TOTP</em>
mfac --add-app --user tux --host linux.example.org --service sshd --alias tux --methods push totp
</code></pre>
<p>The PAM module of mfa also consists of two parts: the actual PAM module
<strong>pam_mfa.so</strong> that gets called in the PAM stack and a helper
program that interacts with mfad. The job of pam_mfa.so is to retrieve the
necessary information (user and service) from PAM and then invoke the helper
program with that data. It then waits for the MFA process to complete, retrieves
the result, and returns either success or failure to the PAM stack. The helper
program initiates a connetion to mfad when run and then passes username, hostname,
and service information to the server. It too receives a success or failure response
and then relays that information to the PAM module. Here is an example of using
pam_mfa.so in the PAM stack for sshd.</p>
<pre><code><strong>/etc/pam.d/sshd</strong>
auth requisite pam_mfa.so</code></pre>
<p>The client program is what the end user interacts with to provide authentication responses.
Currently it is only a very simple terminal program but expanding on this is high on the
TODO list. The client opens a connection to the server and identifies itself with the client
key that was generated during enrollment. The client waits for a prompt from the server, and
when it receives one, informs the user. The client receives the users input and sends it back
to the server. The client performs this loop continuously until it is closed.</p>
<h2>clibrary</h2>
<p><em>Check out the source code here -</em>
<a href=https://git.chudnick.com/clibrary>git.chudnick.com/clibrary</a></p>
<h2>mail-tools</h2>
<p>
<a href=https://git.chudnick.com/mail-tools>git.chudnick.com/mail-tools</a>
</p>
<h2>deploy-scripts</h2>
<p>
<a href=https://git.chudnick.com/deploy-scripts>git.chudnick.com/deploy-scripts</a>
</p>
<h2>server-scripts</h2>
<p>
<a href=https://git.chudnick.com/server-scripts>git.chudnick.com/server-scripts</a>
</p>
</main>
<footer><a href=index.html>www.chudnick.com</a></footer>
</body>
</html>
|
