1 Linux:Secure Authentication
2 ===========================
3 :author: Aaron Ball
4 :email: nullspoon@iohq.net
5 :git: https://oper.io/src/nullspoon/
6
7
8 == {doctitle}
9
10 **Edit**: I wrote the script for automating this finally. It can be found on my
11 link:{git}/keymanage.git[Git page].
12
13 In my experience, Linux authentication seems to be one of those problems with
14 so many answers. It's hard to define even a range of methodologies that could
15 be considered right, let alone narrowing it down to one or two. I've been
16 dealing with this one at work quite a bit recently at work and would like to
17 post here an idea I had. Just to be warned, this idea was not accepted for our
18 solution, despite no one being able to give me more than one reason to not use
19 it, which I will detail at the end of this post along with any other exploits I
20 can imagine for this authentication methodology.
21
22 [[in-a-perfect-world...]]
23 == In a perfect world...
24
25 In a perfect world, chroot environments would work securely and our app
26 developers and third party vendors would write code on par with apache or
27 openssh which could be started as root and spawn child processes in user space
28 for security. All application files would fit nicely into the defined standards
29 for Linux filesystem organization so we could package everything up nicely and
30 deploy using repo servers. To top it all off, all applications would roll their
31 own logs instead of filling up /var/log or somewhere on / since they rarely
32 follow standards. However, this is rarely if ever the case (I've never seen it
33 at least).
34
35 What I've seen up to this point is third party applications that install
36 themselves exclusively in /opt; applications that are hard coded to not start
37 unless running as uid 0 (root); binary startup scripts that situate themselves
38 in /etc/rc.d/init.d/ (wtf guys?), and just general stubborness as to where the
39 program is located.
40
41 [[securing-an-application-server]]
42 == Securing an Application Server
43
44 The first step I typically take to securing applications is to run them in user
45 space as a service account with access only to its directory in the /apps mount
46 point. I put that one to use on my own servers and it has served me very well.
47 However, with this we have a few problems.
48
49 [[accessing-service-accounts]]
50 == Accessing Service Accounts
51
52 While security does tend to introduce complications and interruptions into
53 workflow, it shouldn't be catastrophic. If your security measures are so
54 strict, your users can't do what they need to, you're doing it wrong. Simply
55 running in userspace introduces several problems. A few for example...
56
57 1. How do your users get to their service accounts in a secure way (no shared
58 passwords or keys)?
59
60 2. How do your users transfer files to and from their servers since they can't
61 directly access the service accounts?
62
63 3. How do you manage this web of shared account access without it consuming
64 much of your time?
65
66 Specifically, a solution is needed for the users to access their service
67 accounts in an accountable and auditable way without hindering their ability to
68 do their jobs [too much].
69
70 This has been a problem myself and some fellow engineers have struggled with
71 for a while now. Here's a few common service account authentication mechanisms
72 that I'm sure we've all seen that aren't necessarily the greatest.
73
74
75 [[service-account-passwords]]
76 === Service Account Passwords
77
78 1. They need to be shared for multiple users to have access
79
80 2. They can be shared without the admins knowing (no accountability)
81
82 3. They have to be routinely changed which causes a huge headache for everyone
83 involved, os and app admins alike
84
85
86 [[service-account-keys]]
87 === Service Account Keys
88
89 1. They need to be shared for multiple users to have access
90
91 2. They can be shared without the admins knowing (no accountability)
92
93 3. They have to be routinely changed which causes a slightly lesser headache
94 than passwords for everyone involved, os and app admins alike
95
96
97 [[sudo]]
98 === Sudo
99
100 Sudo provides a pretty clean solution to the problem. It allows you to
101 limit who has access to the service account as well log who uses it and
102 when. Just put your application admins into their own group and give
103 that group explicit access to run ONE command...
104
105 [[sudo-su---service_account]]
106 ==== sudo su - service_account
107
108 This one is tremendously popular for very obvious reasons. However, despite
109 using sudo, this one still has problems
110
111 1. Your end users can't perform file transfers between their boxes since can't
112 directly access their service accounts without a key or password
113
114 2. We still lack accountability. Once the user is in a sudo'd shell, their
115 commands are no longer logged.
116
117 3. Managing this across an environment can be a very time consuming thing
118 unless you have a source on a server that you propogate out, but then you
119 have to deal with server compliance.
120
121 Granted, there is a pretty obvious _Unixy_ solution to this, but it involves
122 your users all being in the same group as your service account, mucking around
123 with umasks that unset themselves on reboot unless explicitely set, and making
124 sure your sticky bit sticks.
125
126 There is another way though.
127
128 [[my-poorly-formed-idea]]
129 == My Poorly Formed Idea
130
131 My idea uses a combination of the crontab, jump hosts, ssh keys, and segregated
132 networks.
133
134 Start with two (or more) segregated networks: one for administration, and
135 several for operations. You will probably want three for operations:
136 production, QA, and dev.
137
138 From there, you put your servers in your operations networks and set up
139 firewall or routing rules to only allow ssh (port 22 or whatever port you
140 prefer) traffic between the administration network and the operations networks.
141 Your operations networks should now only be accessible for users using the
142 applications and admins coming in from the administration network using ssh.
143
144 Next, build out a jump box on your administration network. One per application
145 would be ideal for seperation of concerns, but one for all apps should work
146 well also. For sake of simplicity, we'll assume a single jump host.
147
148 Next, put all of your service accounts on that jump host with their own home
149 directories in /apps. This assumes you have defined and reserved UIDs and GIDs
150 for each of your service accounts so they can be on one system without
151 conflicts. Provide sudo access to each user group to _sudo su -
152 <service_account>_ into their respective service accounts on the jump host.
153
154 At this point, the application admins/owners still don't have access to their
155 service accounts on the operations servers. Here's where they get that access
156 using rotating ssh keys. Write a script to generate ssh keys (I'll post the
157 source for mine later), ssh out to a box using the key to be replaced, push the
158 new key, and remove the old key and any others while using the new key. This
159 allows you to schedule key changes automatically using cron. With that in
160 place, just have the script swap out each service account's key every x minutes
161 (15 or 30 is what I have in mind). Once you've got the key exchange working,
162 modify the sshd_config files throughout your environment to disallow all user
163 login over ssh with passwords, that way if your users do set a password to try
164 to circumvent your security, it won't be accepted anyways. You can also just
165 disable password changing.
166
167 [[pros]]
168 == Pros
169
170 [[operations-networks-become-a-black-box]]
171 === Operations Networks Become a Black Box
172
173 With this method, there is only one way in to every single operations
174 box. That one way in is in a secured subnet, presumably accessible only
175 through a vpn or when on site.
176
177 [[file-transfers-are-seamless]]
178 === File Transfers are Seamless
179
180 Users can use scp or sftp to transfer files seamlessly using the jump host as
181 the medium. If the keys are always regenerated as id_rsa, or the ssh config
182 file is set up for each account, key regeneration won't affect anyone because
183 it takes milliseconds to overwrite the old key with the new one, so any new
184 connections out will use the new key. End users shouldn't even see an effect.
185
186 [[safety-despite-turnover]]
187 === Safety Despite Turnover
188
189 If your company has any measure of turnover, you've undoubtedly gone through
190 the password and key change process after an employee leaves the team. With
191 this method, you're automatically changing the key every X minutes, so even if
192 they do get the key, it'll only be valid for a very short while.
193
194 [[lower-licensing-costs]]
195 === Lower Licensing Costs
196
197 Many companies, through the use of additional software such as Open LDAP,
198 Samba, or some other third party product, put their Linux/Unix servers on their
199 Windows Domain. A perk of this is it provides access to Linux to your AD users
200 without having to manage a few hundred or thousand passwd, group, and shadow
201 files. The downside to this is that if a third party product is used, it costs
202 a lot of money in licenses. With the jump host rotating key model, you can put
203 just the jump host(s) on the domain, and leave all operations servers off of
204 the domain. It saves on licensing costs, maintainence time, and software
205 installs. It also removes yet one more service running on your operations boxes
206 which removes one more access point for exploitation. Additionally, the fewer
207 pieces of software running on a server, the less chance an update will break
208 the applications it's hosting.
209
210
211 [[clean-home-directories]]
212 === Clean Home Directories
213
214 Next up, clean home directories. If you have an entire team of developers
215 and/or application admins logging into every operations system, /home is going
216 to be very large on lots of systems, costing money for backups (if you back
217 home directories up that is), wasting storage space (which is fairly cheap
218 these days though), and adding spread to your users's files, making it
219 cumbersome for everyone to manage, including non system admins. With the jump
220 host rotating key method, all of your home directories are on one host, so file
221 management for the support staff is much easier.
222
223
224 [[cons]]
225 == Cons
226
227
228 [[single-point-of-failure]]
229 === Single Point of Failure
230
231 This is the one objection I heard from people at work. This can be
232 mitigated in at least two ways. One is by having one jump host per
233 application. It still beats putting hundreds or thousands of systems in
234 AD and all the management and licensing costs that goes with that.
235 Another way to mitigate this is to have a seconday jump host and set up
236 rsync to synchronize the primary jump host with the backup, using the
237 backup as a hot standby.
238
239
240 [[single-point-of-global-access]]
241 === Single Point of Global Access
242
243 This is the one problem with this idea that I think is most relevant and
244 potentially exploitable. However, if your administration boxes are on a network
245 that is not reachable from anywhere but controlled locations, this shouldn't be
246 too big of a deal. However, if a mistake is made in the networking security or
247 routing and a malicious user gets to a jump host, they still have to get into
248 the service accounts which are inaccessible except through sudo, which means
249 the malicous user has to exploit an existing account. Without that account's
250 password though, they can't sudo so they would only have access to that one
251 user's files. Even if they could sudo though, they will still only have access
252 to the service accounts that user works with, so their impact would be minimal
253 unless that user works on very high profile applications. To sum it up, there
254 are three very solid security measures in place (network segretation, user
255 accounts, limited sudo access requiring passwords) that the malicious user has
256 to get through before having any really impacting access.
257
258
259 Category:Linux
260 Category:Security
261 Category:Authentication
262
263
264 // vim: set syntax=asciidoc:
|
