File: security.html

package info (click to toggle)
lg-issue16 4-4
  • links: PTS
  • area: main
  • in suites: woody
  • size: 1,256 kB
  • ctags: 77
  • sloc: tcl: 89; makefile: 37; sh: 4
file content (223 lines) | stat: -rw-r--r-- 12,188 bytes parent folder | download | duplicates (3)
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
<!--startcut ==========================================================-->
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<title>More Linux Security Issue 16</title>
</HEAD>
<BODY BGCOLOR="#EEE1CC" TEXT="#000000" LINK="#0000FF" VLINK="#0020F0"
ALINK="#FF0000" >
<!--endcut ============================================================-->

<H4>
&quot;Linux Gazette...<I>making Linux just a little more fun!</I>&quot;
</H4>

<P> <HR> <P> 
<!--===================================================================-->

<center>
<H2>More Linux Security</H2> 
<H4>By Andrew Berkheimer, <A HREF="mailto:andy@tho.org">andy@tho.org</A> 
</H4> 
</center>
<P>
	Here you go, yet another article on Linux security. Some new tidbits
for all to enjoy, reinforcement of some key points, and clarification of some
things which I though were a bit misrepresented in previous articles. Note
that this is geared towards a slightly novice audience, more experience users will
probably find themselves bored out of their minds at times.
	
	So you've got your system up and running, connected to the net,
maybe running an ftp server or some other service.  But you've heard all these
nasty stories of people having their computers cracked for no apparent reason,
and you're just a tad bit nervous.  You want to start securing your system
from outside intruders, but where to begin?  Contrary to popular belief,
securing your system can actually be fun, and if nothing else, informative.
So it's time to begin!
<P>
	First and foremost, stay informed! Jay mentioned reading CERT, but
I would argue that this is not enough. CERT does not release information 
until they have verified that it is a problem and most of the big-name
vendors have provided patches to fix the problem. This can often cause
lag times of months between a hole being found and the CERT announcement. There
are a number of good mailing lists which I would recommend subscribing to,
including bugtraq, linux-security, and linux-alert (subscription information
is at the end of the article), where security holes are often discussed and
found long before CERT starts talking about them - the crackers know about
these places, so should you.
<P>
	Now onto some real meat. The first concern is to try and protect 
yourself from attacks from unknown outsiders who may stumble upon your system
and see it as an invitation to test out their cracking skills. One of the first 
things you want to check is for unused daemons running on you system. There's 
really no reason to be running nfsd if you're not NFS serving to anywhere, 
now is there? There are two places that you will need to check out: the 
configuration file for the inet super server (typically /etc/inetd.conf), 
and the system bootup scripts (located in /etc/rc.d, /etc/rc2.d, or some 
similar directory). 
<P>
	In inetd.conf, comment out with a # the lines for any service you
don't really need to provide...the r* services (rlogind, rshd, rexecd, etc)
are good candidates, as well as other typically unused ones like echo, 
daytime, and chargen. For most people, leaving in telnetd, ftpd, and maybe 
pop3d should be sufficient for the moment. Maybe fingerd too, though be
careful, finger can give out a lot of information about your computer which can
be to a potential crackers advantage. Once you finish editing your
inetd.conf, restart inetd by running "killall -HUP inetd" to get it to reread
the configuration.
<P>
	In your bootup scripts you may see references to things like portmap,
ypserv, rpc.mountd, and rpc.nfsd. Unless you are a NFS or NIS server, you have
no need for these and should not run them...in many cases the "out of the box"
versions of these programs have some pretty nasty security vulnerabilities. 
Also look for sendmail (if you're not receiving mail directly you don't need
to run it), and httpd (only want this if you're running a web server).
<P>
	So, you've worked hard to get the list of unnecessary servers down...
time to start adding/upgrading software again. First and foremost, make sure
you are running the most recent version of NetKit, which contains most of the
typically network servers for Linux like telnetd, fingerd, etc. The current
version as of this writing is 0.09, it is available in
ftp://ftp.uk.linux.org/pub/linux/Networking/base. The most recent version fixes
a few known security flaws in earlier versions.
<P>
	In general, you want to try and keep everything else up to date too:
check http://www.sendmail.org for updates to sendmail (any time a new version
comes out nowadays, it is almost always to fix a security problem), as well
as http://www.apache.org for updates to the apache httpd server, etc.
<P>
	However, there is still the problem of password sniffers grabbing
your password if you telnet to your system from some other outside network.
Telnet, FTP, POP, and just about any other standard protocol out there will
transmit your password in plaintext. There are a couple of ways around this
available in external software packages. I'll look at OPIE and ssh here.
<P>
	First of all there's OPIE, also known as One-time Passwords In
Everything, a package created by the US Naval Research Labs and currently
maintained by The Inner Net. The idea behind one time passwords is that when
you login to a system from remote, it will give you a prompt like this:
<PRE> 
	stroke login: andy
	otp-md5 271 st6747
	Response:
</PRE> 
Instead of just typing in your password right away over the connection, you
would instead run a key generating program on your local machine, with the
parameters given in the "challenge" of the login prompt (the challenge here
being otp-md5 271 st6747). You type your password into the local program
(where it can't be grabbed by packet sniffers), and the key generator 
produces a unique password which you login with. This unique, one-time password
will only work once, so even if someone grabs it in a packet sniffer, it
won't do them any good. The OPIE package is available at 
ftp://ftp.nrl.navy.mil/pub/security/opie/ with more information.
<P>
	There's also another pretty popular package, ssh. The ssh package
replaces those evil rlogind, rexecd, rshd, etc. programs with sshd, which
has the same functionality, but it encrypts all communications, making it
very hard in deed for a packet sniffer to get anything useful. More information
about the package can be found at http://www.cs.hut.fi/ssh/.
<P>
	In addition to these two, there are a number of more involved,
complicated methods designed for sitewide networks, labs, and the like, which
are a tad overkill for one single host (this includes things like 
Kerberos V and the like).
<P>
	That about wraps up the protecting yourself from outside crackers,
but you still have to worry about other users on your own system (or even
outside crackers if they manage to get access to a shell on your system). 
Typically you will hear a lot about "buffer overflow" security holes. These
are essentially times when a binary doesn't check to see if the data it is
storing into a character buffer can fit into the memory it is being put into.
A carefully written program can take advantage of this and overwrite other
parts of memory, causing other programs to be executed. Normally this isn't
a problem until you get into setuid root binaries. Since setuid root binaries
will initially run with root privileges, then any binary executed by the
program will also be run as root. So if there is a buffer overflow which is
used to run /bin/sh as root, then blammo, any random joe suddenly has a root
shell to do what they please with.
<P>
	There are also programs which have what are called race conditions,
or times when they are doing something which may be used to a crackers
advantage if the program happens to be running as root. Through some bit
of trickery, it might very well be possible for them to get a root shell.
The bottom line: setuid root binaries are not the greatest things in the world,
keep the number of setuid root binaries on your system to a bare minimum.
<P>
	To protect yourself from buffer overflows, there isn't too much you can
do but keep up to date with information being made available about possible
security holes and fixing them ASAP.  If you have some programming experience,
you also probably want to actually look through the source code and check for
buffer overflows yourself: you just may find one that no one else knows about
yet. 
<P>
	Also, an important point: you should very rarely trust binaries that
you just get off the net from an untrusted unknown source, especially if you
are going to be running those binaries as root. This is how the Bliss "virus"
spread, combined with a buffer overflow in some commonly found setuid root 
games. Under any Unix, root is a very powerful user, so while normal viruses
can't exist under Unix because users typically cannot modify system binaries,
a program like Bliss is designed to try and exploit known buffer overflows to
get root access to be able to modify root owned binaries.
<P>
	And just as a last reminder, here are some points I can't help but 
reinforce.If you think you've been compromised, then disconnect from the net
immediately, analyze your logs, and replace any binaries which you think may
have been compromised, maybe even reinstalling your system (after backing up
important data). And always remember to keep your passwords hard to guess and
change them regularly.
	 
	Besides all this, I can't begin to emphasize the importance of 
GETTING INFORMED and then STAYING INFORMED. There are many good books on the
topic of computer security, I'd especially recommend _Computer Security 
Basics_ from O'Reilly and Associates for those with a beginning interest in
security. And keeping current with some of the more popular security mailing
lists will do you a world of good.  There is also a Linux Security FAQ
available online at http://www.aoy.net/Linux/Security/, which is a good 
source of information. Some final advice: never get the feeling that your
system is "perfectly secure" - you're just inviting a break-in that way.
<P>
	Oh, about those mailing lists I mentioned earlier. Information about
linux-alert and linux-security can be found at the Linux Security WWW I just
mentioned (http://www.aoy.net/Linux/Security/). Information about bugtraq
may be found at http://www.geek-girl.com/bugtraq/index.html. There are also
a lot of other things which can be said about security, delving into firewalls
and other packet filtering, IP spoofing protection, more fine grained access
control to net services, and many other areas, but those are topics for
another place and time.
<P>
					-Andrew Berkheimer
					andy@tho.org, aberkhei@tjhsst.edu
<P> 
<B>Summary of Resources Mentioned</B>
<PRE> 
                  netkit: ftp://ftp.uk.linux.org/pub/linux/Networking/base/
                sendmail: http://www.sendmail.org/
                  apache: http://www.apache.org/
                    opie: ftp://ftp.nrl.navy.mil/pub/security/opie/
                     ssh: http://www.cs.hut.fi/ssh/
      linux security www: http://www.aoy.net/Linux/Security/
   linux-alert list info: http://www.aoy.net/Linux/Security/LinuxAlertList.html
linux-security list info: 
		http://www.aoy.net/Linux/Security/LinuxSecurityList.html
       bugtraq list info: http://www.geek-girl.com/bugtraq/ 
</PRE> 
    
<!--===================================================================-->
<P> <hr> <P> 
<center><H5>Copyright &copy; 1997, Andrew Berkheimer <BR> 
Published in Issue 16 of the Linux Gazette, April 1997</H5></center>

<!--===================================================================-->
<P> <hr> <P> 
<A HREF="./lg_toc16.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="./lgei.html"><IMG SRC="../gx/back2.gif"
ALT=" Back "></A>
<A HREF="./gv.html"><IMG SRC="../gx/fwd.gif" ALT=" Next "></A>
<P> <hr> <P> 
<!--startcut ==========================================================-->
</BODY>
</HTML>
<!--endcut ============================================================-->