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
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
|
<HTML>
<HEAD>
<TITLE>Linux Security 101 Issue 14</TITLE>
</HEAD>
<BODY bgcolor="#FFFFFF">
<H4>
"Linux Gazette...<I>making Linux just a little more lovable!</I>"
<IMG ALIGN=MIDDLE SRC="../gx/heart.gif"> </H4>
<P> <HR> <P>
<!--===================================================================-->
<center>
<H2>Linux Security 101</H2>
<H4>By Kelley Spoon,
<a href="mailto:mars@loeffel.txdirect.net">
mars@loeffel.txdirect.net</a></H4>
</center>
<P> <HR> <P>
You can jump down to the section on<a href="#tcpd"> tcpd </a><br>
Or take a peek at the other<a href="#other"> stuff </a>you need to keep an
eye on.<p>
</center>
<hr>
<p>
Ok. You've got Linux beat. You finally got AfterStep set up the way you want
it, you've managed to set up ip masquerading for your home LAN, you've managed
to set up a cool issue for people to see when they log in, you managed to
convert a couple over to the One True OS, and chicks really dig you because,
as we all know, Linux geeks are sexy.
<p>
One night as you're peeking at <i>/var/adm/messages</i>, you notice that
someone from some place you've never heard of before tried to make 5 ftp
connections, 6 telnets, and even an nntp connection. What's up with that?
<p>
Well, Linux (and all Unix type OS's in general) were designed to be a
programmer's paradise. The same qualities that makes Linux such a wonderful
networking and hacking operating system also expose a few security holes.
There are a few programs that you probably rely on or use daily that can be
used to gain root access (which is a Bad Thing). What's worse, the commercial
distributions that many Linux users depend on have these programs with
security holes inside packages that are installed as part of the base
system.
<p>
That's the bad news. The good news is that we can make it tougher for the
Bad Guys to do their dirty deeds. By checking the
<a href="http://www.aoy.com/Linux/Security/"> Linux ALERTS </a>
page, you can find out what the holes we <b>know</b> about are, and how to
temporarily plug them up or even fix them up for good. There is also a nice
little tool that is probably on your system that we can use to keep them
from even having access to our machine.
<p>
And that's what I'm going to focus on. My belief here is that if we can
keep the Remote Bad Guys (people who don't have legitimate access to our
machines) out, then we only have to worry about the Local Bad Guys (if any).
Plus it gives us a chance to fix anything on our machine that is a security
hole the RBG's can use.
<p>
<hr>
<h2><center><a name="tcpd">tcpd</a></center></h2>
<hr>
<p>
There's a daemon that's probably been installed on your machine that you don't
know about. Or at least, you're not aware of what it can do. It's called
<i>tcpd</i>, and it's how we shut off access to some of the basic services
that the Bad Guys can use to get on our system.
<p>
Since <i>tcpd</i> can be pretty complex, I'm not going to go into all the
details and tell you how to do the fancy stuff. The goal here is to keep the
mischievous gibbons from knocking down what it took so long for use to set
up.
<p>
<i>tcpd</i> is called into action from another daemon, <i>inetd</i>, whenever
someone tries to access a service like in.telnetd, wu.ftpd, in.fingerd,
in.rshd, etc. <i>tcpd</i>'s job is to look at two files and determine if
the person who is trying to access the service has permission or not.
<p>
The files are <i>/etc/hosts.allow</i> and <i>/etc/hosts.deny</i>. Here's
how it all works:
<p>
<ol>
<li> Someone tries to use a service that <i>tcpd</i> is monitoring.
<li> <i>tcpd</i> wakes up, and makes a note of the attempt to the syslog.
<li> <i>tcpd</i> then looks <i>hosts.allow</i>
<ul>
<li> if it finds a match, <i>tcpd</i> goes back to sleep and lets the user
access the service.</li>
</ul>
<li> <i>tcpd</i> now takes a look at <i>hosts.deny</i></li>
<ul>
<li>if it finds a match, <i>tcpd</i> closes the user's connection</li>
</ul>
<li> If it can't find a match in either file, or if both files are empty,
<i>tcpd</i> shrugs, guesses it's OK to let the user on, and goes
back to sleep.</li>
</ol>
<p>
Now, there are a couple of things to note here. First, if you haven't edited
<i>hosts.allow</i> or <i>hosts.deny</i> since you installed Linux, then
<i>tcpd</i> assumes that you want to let everyone have access to your machine.
The second thing to note is that if <i>tcpd</i> finds a match in
<i>hosts.allow</i>, it stops looking. In other words, we can put an entry
in <i>hosts.deny</i> and deny access to all services from all machines, and
then list ``friendly'' machines in the <i>hosts.allow</i> file.
<p>
Let's take a look at the man page. You'll find the info you need by typing
<b>man 5 hosts_access</b> (don't forget the 5 and the underscore).
<p>
<pre>
daemon_list : client_list
daemon_list is a list of one or more daemon process names
or wildcards
client_list is a list of one or more host names, host
addresses, patterns or wildcards that will be matched
against the remote host name or address.
List elements should be separated by blanks and/or commas.
</pre>
<p>
Now, if you go take a look at the man page, you'll notice that I didn't show
you everything that was in there. The reason for that is because the extra
option (the shell_command) can be used to do some neat stuff, but *most
Linux distributions have not enabled the use of this option in their tcpd
binaries*. We'll save how to do this for an article on <i>tcpd</i> itself.
<p>
If you absolutely have to have this option, get the source from
<a href="ftp://ftp.funet.fi/pub/Linux/PEOPLE/Linus/net-source/base/tcp_wrappers_7.4.tar.gz">
here</a> and recompile.
<p>
Back to business. What the above section from the <i>hosts_access</i> man
page was trying to say is that the format of
<i>hosts.</i>[<i>allow</i>|<i>deny</i>] is made up of a list of services and
a list of host name patterns, separated by a ``:''
<p>
You'll find the name of the services you can use by looking in your
<i>/etc/inetd.conf</i>...they'll be the ones with <i>/usr/sbin/tcpd</i>
set as the server path.
<p>
The rules for determining host patterns are pretty simple, too:
<p>
<ul>
<li> if you want to match all hosts in a domain, put a ``.'' at the front.</li>
<ul>
<li>Ex: <i>.bar.com</i> will match "foo.bar.com", "sailors.bar.com",
"blue.oyster.bar.com", etc.</li>
</ul>
<p>
<li> if you want to match all IPs in a domain, put a "." at the end.</li>
<ul>
<li>Ex: <i>192.168.1.</i> will match "192.168.1.1", "192.168.1.2",
"192.168.1.3", etc.</li>
</ul>
</ul>
<p>
And finally, there are some wildcards you can use:
<ul>
<li><i>ALL</i> matches everything. If in daemon_list, matches all daemons;
if in client_list, it matches all host names.</li>
<ul>
<li> Ex: <i>ALL : ALL</i> would match any machine trying to get to any
service.</li>
</ul>
<p>
<li><i>LOCAL</i> matches host names that don't have a dot in them.</li>
<ul>
<li> Ex: <i>ALL : LOCAL</i> would match any machine that is inside the
domain or search aliases given in your <i>/etc/resolv.conf</i></li>
</ul>
<p>
<li><i>except</i> isn't really a wildcard, but it comes in useful. It excludes
a pattern from the list.</li>
<ul>
<li> Ex: <i> ALL : ALL except .leetin-haxor.org</i> would match all services
to anyone who is not from ``*.leetin-haxor.org'' </li>
</ul>
</ul>
<p>
Ok. Enough technical stuff. Let's get to some examples.
<p>
Let's pretend we have a home LAN, and a computer for each member of the family.
<p>
Our home network looks like this:
<p>
<pre>
linux.home.net 192.168.1.1
dad.home.net 192.168.1.2
mom.home.net 192.168.1.3
sis.home.net 192.168.1.4
bro.home.net 192.168.1.5
</pre>
<p>
Now, since no one in the family is likely to try and ``hack root,'' we can
assume they're all friendly. But....we're not so sure about the rest of
the people on the Internet. Here's how we go about setting things up so
people on home.net have full access to our machine, but no one else does.
<p>
In <i>/etc/hosts.allow</i>:
<p>
<pre>
# /etc/hosts.allow for linux.home.net
ALL: .home.net
</pre>
<p>
And in <i>/etc/hosts.deny</i>
<p>
<pre>
# /etc/hosts.deny for linux.home.net
ALL : ALL
</pre>
<p>
Since <i>tcpd</i> looks at <i>hosts.allow</i> first, we can safely deny
access to all services for everybody. If <i>tcpd</i> can't match the machine
sending the request to ``*.home.net'', the connection gets refused.
<p>
Now, let's pretend that Mom has been reading up on how Unix stuff works,
and she's started doing some unfriendly stuff on our machine. In order
to deny her access to our machine, we simply change the line in <i>
hosts.allow</i> to:
<p>
<pre>
ALL: .home.net except mom.home.net
</pre>
<p>
Now, let's pretend a friend from....uh....friend.com wants to get something
off our ftp server. No problem, just edit <i>hosts.allow</i> again:
<p>
<pre>
# /etc/hosts.allow for linux.home.net
ALL: .home.net except mom.home.net
wu.ftpd: .friend.com
</pre>
<p>
Things are looking good. The only problem is that the name server for
home.net is sometimes down, and the only way we can identify someone as
being on home.net is through their IP address. Not a problem:
<p>
<pre>
# /etc/hosts.allow for linux.home.net
ALL: .home.net except mom.home.net
ALL: 192.168.1. except 192.168.1.3
ALL: .friend.com
</pre>
<p>
And so on....
<p>
I have found that's it's easier to deny everybody access, and list your
friends in <i>hosts.allow</i> than it is to allow everybody access, and
deny only the people who you know are RBG's. If you are running a private
machine, this won't really be a problem, and you can rest easy.
<p>
However, if you're trying to run a public service (like an ftp archive of
Tetris games for different OS's) and you can't afford to be this paranoid,
then you need shouldn't put anything in <i>hosts.allow</i>, and just put
all of the people you don't want touching your machine in <i>hosts.deny</i>
<p>
You might also want to take a look at the next section.
<p>
<hr>
<h2><center><a name="other">Other things to keep in mind</a></center></h2>
<hr>
<p>
<h4>Security holes in software</h4>
<p>
Like I said earlier, a lot of the software that comes standard in CD-ROMs have
security holes in them which could let local or even remote users execute
commands as root on your system. Keep an eye on
<a href="http://bach.cis.temple.edu/linux/linux-security"> Linux ALERTS</a>
to find out about problems we know about and how to fix them.
<p>
<h4>What services you offer</h4>
<p>
Check to make sure that the services you have running on your machine are
what you really want to offer. For example, most of us don't have a need
to run <i>in.nntpd</i>, yet it's got an entry in <i>/etc/inetd.conf</i>.
Do you really want everyone on the Internet to have access to
<i>in.fingerd</i>? Do you really need to let everyone on the Internet have
access to your ftp server?
<p>
Find what you don't need (or don't want to offer to any passing stranger who
might happen across your machine) and either shut it down or deny outside
access to it.
<p>
<h4>Passwords</h4>
<p>
Yeah, yeah, yeah. Everyone's heard the speech about passwords, but they
are pretty important. Especially if you're not restricting access to your
machine. Remember, if they can get to your machine, they can get on your
machine. And if they can get on your machine, they can get root access.
<p>
In case you haven't heard the speech, here's the condensed version:
<ol>
<li>Make the passwords at least 6 characters long.</li>
<li>Mix the case of the passwords.</li>
<li>Use at least one numeral.</li>
<li>Use at least one non-alphanumeric character.</li>
<li><b>Change the passwords on a regular basis</b>. About once every<br>
two months should do for the casual user.</li>
</ol>
I have found that using "k-rad" or "leet-speak" helps when you need to
make up a password. For example, instead of using the password
"foobar", try using "f00b4R!".
<p>
Also, get and install shadow passwords. You might have to recompile a
few services, but it's worth the extra protection.
<p>
Finally, it is important to note that only the first 8 characters of the
password get used under Linux's login. In other words, if you have a password
that looks like <i>abcdefghijklmnopqrstuvwxyz</i>, you will only need to enter
<i>abcdefhg</i> in order to gain access to the account. This holds true
whether you are using shadowed passwords or not.
<p>
<pre>[ Thanks to Olav Wölfelschneider for pointing that out. ]</pre>
<p>
<h4>File Permissions</h4>
<p>
Many of the security holes that exist are because the files are "setuid".
That means that a non-root user can execute the files as root. Remove
this permission from any files that don't need it. Like <i>mount</i>.
It really isn't that much of a hassle to keep one of your virtual
consoles logged in as root, and flip over to it when you need to get
something done.
<p>
Also, if you have stuff sitting somewhere that you don't want anyone else
to see, don't give them world rwx permission on the dir.
<p>
<h4>Keep an eye on the syslog</h4>
<p>
At least once a day, you need to go check the syslog and see what's been
happening. You can find it <i>/var/adm/syslog</i>, and I'd also recommend
taking a peek at <i>/var/adm/messages</i>. You'll want to look for
multiple connections coming from places you don't know in a short period
of time. If they look suspicious, then don't hesitate to slap an entry
for the domain into <i>/etc/hosts.deny</i>
<p>
<h4>Who you trust</h4>
<p>
This is just common sense. It's not a wise idea to give out your root password
to someone you just met on IRC 5 minutes ago who claims they can get Apache
up and running on your system if you just tell them the root password.
<p>
Set up a guest account with limited read, write, execute abilities and let them
use that.
<p>
It's also not wise to let people just log in and fiddle around on your machine.
Despite common belief, it is possible to create Unix ``viruses,'' and all you
really need is the knowledge, the will, and an opportunity. For more
information, see the paper on
<a href="http://www.cyber.com/papers/plausibility.html">The Plausibility of
Unix Virus Attacks</a>
<p>
<hr>
<p>
<h3>Final Word</h3>
<p>
To be completely honest with you, the only way to be 100% sure your machine
can't be compromised is to physically deny access to it. That means get
rid of the modem and ethernet card, fill up any hole in the computer's case
with cement, and buy a big, mean pit bull to guard it while you are asleep.
<p>
Well, maybe that's going a bit far. But the point is, if they can't get to
your machine, they can't do anything to it. If you think your machine has
been compromised, disconnect it from the network, look through the
<i>syslog</i>, try to find out how it was compromised, fix the problem,
set all new passwords for your accounts, and then reconnect it.
<p>
We might not be able to make the machine 100% secure, but we can make
it hard for the Bad Guys to do their thing.
<hr>
Email:<a href="mailto:mars@loeffel.txdirect.net">
<i>mars@loeffel.txdirect.net</i></a>
<!--===================================================================-->
<P> <hr> <P>
<center><H5>Copyright © 1997, Marsala <BR>
Published in Issue 14 of the Linux Gazette</H5></center>
<!--===================================================================-->
<P> <hr> <P>
<A HREF="./lg_toc14.html"><IMG ALIGN=BOTTOM SRC="../gx/indexnew.gif"
ALT="[ TABLE OF CONTENTS ]"></A>
<A HREF="../lg_frontpage.html"><IMG ALIGN=BOTTOM SRC="../gx/homenew.gif"
ALT="[ FRONT PAGE ]"></A>
<A HREF="./linus.html"><IMG SRC="../gx/back2.gif"
ALT=" Back "></A>
<A HREF="./mutt.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
<P> <hr> <P>
</BODY>
</HTML>
|
