Copy Link
Add to Bookmark
Report
The Discordant Opposition Journal Issue 01 File 03
::::::::::::::::::::::::::::::::::::::::::::::::::::::::Dec/98
::: The Discordant Opposition Journal ::: Issue 1 - File 3 :::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
:Securing Linux:
The basics
What exactly are 'the basics'? The basics are things that everyone running
Linux should do to provide themselves with a basic level of security. Even if
you take no more interest in security than to implement a few minimal
precautions it's much better than nothing at all. This section will focus on
various ways of securing Linux including shutting off non-essential services and
using the default system TCP wrappers.
/etc/inetd.conf
What is 'inetd'? Inetd listens and waits for connections to sockets that are
listed in /etc/inetd.conf, then the TCP wrappers check the files hosts.allow and
hosts.deny to see if the incoming connection is allowed or not and whether they
are allowed to use the service that they are trying to reach. Most services are
started by inetd so that they can be launched when needed.
What exactly is a service then? A service is anything in your /etc/inetd.conf
file that hasn't been commented out ['commenting out' is done by placing a '#'
at the start of the service's line therefore causing the line to be ignored].
Services include ftp and telnet. Some of the services are only intended for test
purposes and should be commented out as soon as you get a chance to, among these
services are chargen, echo, and discard. Finger, netstat and systat are all used
to gain information about your system from the outside, this is unnecessary and
therefore these services should also be commented out. 'Time' is to give the
time of day, if you don't think you'll need it just comment it out. Sun-rpc can
also probably be commented out without much worry.
When you feel that you've edited /etc/inetd.conf to your satisfaction do a ps
-aux and then after noting the pid [process id] of inetd then issue the command
kill -HUP [inetd pid] to restart inetd and have the changes you made come into
effect.
Shadow passwords
Most people know that passwords in Unix aren't secure. Any user on a system
can make a copy of the passwd file and then use any one of a number of password
crackers out there that'll brute force passwords using dictionaries or lists of
known non-dictionary password choices. Why is this possible?
Various programs on a Unix system have to be able to access the passwd file to
determine a user's groupid [gid] or userid [uid] or whatever. To make the passwd
file root read only would mean that a hell of a lot of programs would have to be
run as root, this is not a secure way to run a system. As people who know
anything about security will tell you, keeping the number of programs run as
root to a bare minimum is essential. The more programs run as root the more
chances that one or more of them will be exploitable exist, therefore an
alternative to this had to be found.
Password crackers
The passwords on a Unix system are encrypted using DES, this is extremely
difficult to decrypt, probably impossible. Each system uses a 'keyphrase' or
'word' on which it bases the encryption, this is just random letters and
numbers. Hackers who claim to have 'decrypted' the passwd file have done no such
thing, they're bullshitting or don't know what they're talking about. The
passwords are not designed to be decrypted, what the system does is encrypt
[using the 'crypt' function] the password you provide at login. This is then
compared to the password field in the passwd file, if they match then you are
granted access if not then you aren't. Simple as that.
What a cracker basically does is crypt all the words in a given file [like a
dictionary or a special wordlist containing common non-dictionary choices of
passwords] and compares each attempt to the password in question. When the
cracker gets a match between the crypted password and one of the encrypted words
it has compared it to then it has cracked the password. This is known as 'brute
force' because it simply relies on the sheer number of attempts it makes to get
the password instead of any sophisticated method.
This is where shadowed passwords come in, it adds far more security to your
system and stops a simple 'cat /etc/passwd' allowing your full password file out
for all the world to see.
An unshadowed passwd file will have entries that look roughly like this:
rueful:S721vK02fl94:0:0:Rue-the-Day:/root:/bin/bash
I was gonna give you an actual example from 'mechanus' [my box], but I figured
it's best not to have such things floating around online so the above example is
just that - an example [don't take my word for it though, spend a few hours
trying to crack it and then believe me, hehe].
So what does all that actually mean? Let's have a look at the format:
username:password[crypted]:userid:groupid:comment:homedirectory:shell
That's all pretty self-explanatory right? 'Username' is the user's login name,
the 'password' field is where the password goes in crypted format and the
'userid' [uid] and 'groupid' [gid] are for determining the user's level of
access [incidentally a uid and gid of '0' indicates root level access]. The
'comment' can be anything from the user's real name to their phone number or
home address depending on what the person who added the account wanted to put
there, the 'homedirectory' is the user's home directory, for instance
/home/ruetheday. The 'shell' field states what shell the user uses by default,
in my example it was bash.
So what would a shadowed passwd file look like? Let's see an actual real life
entry as an example, exciting stuff eh?
[source: http://www.paulbrady.com/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd]
river:x:587:100:riverdance.com:/export/home/riverdance.com/:/sbin/sh
niamh:x:30048:1::/export/home/riverdance.com:/sbin/sh
Never has 'Riverdance' been so interesting. I hope you noticed the important
part of the example, in place of the crypted password is an 'x' [By the way, for
phf fun try scanning ac.jp, for some reason the Japanese seem a little overly
fond of phf]. That's right, the good folks at paulbrady.com have shadowed
passwords, this example demonstrates quite nicely how much better it is to have
your passwd file protected in this way.
Incidentally I haven't bothered to check but it looks like there may be a
vague possibility that some of the users at paulbrady.com may have joe passwords
but I haven't checked for various reasons [almost getting busted three times in
two weeks'll do that for you folks]..
What the shadowed password package does is move the passwords to another file
that is read only by root and leaves the original file behind as a reference for
programs that need it. The package comes with it's own versions of the programs
that need to see the crypted password like adduser and login. The new shadow
file will reside in /etc/shadow, it has a few extra features separate from the
standard /etc/passwd file as we can see from the format below:
username:password[crypted]:changedate:minchange:maxchange:warn:inactive:expire
So aside from the standard fields like 'username' and 'password' what do all
the other new ones mean? Here are brief definitions of what each of the new
fields contain:
changedate: the date of the most recent password change.
minchange: the minimum length of time before a password change is required.
maxchange: the maximum length of time before a password change is required.
warn: warns the user a set number of days in advance that their password will
expire.
inactive: specifies the length of time a user has to change their password after
the 'expire' date before their account is invalidated [cancelled].
expire: the date that the password will expire.
Well that explains most of the basics of why you want to shadow your passwd
file and what it actually does and why, any questions, corrections, comments,
haiku or whatever should be emailed to me at root@Rue-the-Day.net.
More information on the shadow password package can be gotten from
sunsite.unc.edu. You can download the latest version of the package from
iguana.hut.fi. [filesize: 464kb]
Firewall basics
A more in-depth document on firewalls for Linux can be obtained from
sunsite.unc.edu, I'll be covering the basics though. There are also a number of
lists that deal solely with the subject including: Firewalls, Euro firewalls,
Academic firewalls and TIS's Firewall Toolkit users list.
What exactly is a firewall?
A firewall is a system that creates a barrier between a 'trusted' [internal]
network and an 'untrusted' [external] one. So basically a firewall is a computer
that acts as a barrier between your network and the internet, which runs special
software to keep others from accessing your systems without authorisation. In
fact the firewall software doesn't even have to be on a separate, dedicated
computer, it can be on one used for other purposes as well but this is less
efficient. Many firewalls determine access based on the domain name of the
incoming connection.
Let's say that I decided to set up a firewall but I still wanted 'Bedlam' to be
able to access my system. His ident is usually something along the lines of
'dubadl.tinet.ie' but to be on the safe side I might make 'tinet.ie' the allowed
domain because his ident isn't always the same [my ISP is also 'tinet' which
makes it all the more convenient really]. Great, so 'Bedlam' can continue to
access my system through the firewall and nobody else can.
Well actually that's not quite true. What about all the other people on tinet?
A lot of the hackers I've met in Ireland have used tinet as their ISP so that's
immediately a worry but the person wouldn't even have to be on tinet to have
their ident read 'tinet.ie'.
This is where the problem of 'wingating' comes in. To be honest wingating
deserves it's own page or file but I'll try to sum it up here briefly. Wingating
allows two computers to share a connection, when it is first installed it has
certain defaults running. Like all defaults they aren't necessarily ones that
you'd want to leave active, careless sysadmins leave them running though. You
can use a wingate to bounce your connection to another computer through and
therefore appear to be coming from wherever the wingate is set up.
Let's say somebody did a dns lookup on 'Bedlam', let's say his ip was resolved
to 159.134.230.132, and then fed the ip string [in this case 159.134.230.132]
into a domain scanner and scanned for port 23, they would then have a good
chance of discovering wingatable ips. They could then telnet to port 23 of one
of the ips that was discovered and from there telnet to my system with
'tinet.ie' as their ident. The firewall would recognise the domain and grant
access. If I wanted to grant access to some other of my friends like 'Cronus' then
I would have to allow even more domains making security even more lax. What I'm
trying to say is that relying on such things gives a false sense of security.
There are of course other ways to get around firewalls, most work only if the
firewall in question is a cheap one. One way of getting around them is to ping
them repeatedly until they become too lagged to properly check incoming
connections.
Let's have a look at some other details of firewalls.
Other utilities
Examining SSH
http://www.cs.hut.fi/ssh
SSH is a drop in, encrypted replacement for the r* tools. It has its own daemon,
which can be run 'stand alone' or from inetd.
SSH can be compiled with support for syslogging, TCP_Wrappers, replacing the r*
tools completely, support for X, port redirection, login completion -- did
someone ask for a Swiss Army Knife?
Websites
Linux security 101 - A great site, very informative.
http://www.gl.umbc.edu/~jjasen1/unix/linux.html
Linux security web page
http://www.aoy.com/Linux/Security/
Sneakers homepage - The Sneakers list homepage.
http://www.cs.yale.edu/HTML/YALE/CS/HyPlans/long-morrow/sneakers.html
Newsgroups
There are a few newsgroups that have a topic that would be useful to people
interested in computer security in general and in Unix security in specific.
comp.unix.admin
comp.security.unix
comp.security.announce
alt.hackers.malicious
comp.society.cu-digest
alt.ph.uk
Mailing lists
Here is an incomplete list of mailing lists that deal with various aspects on
Unix and general computer security, some are very general and others concentrate
solely on one topic such as firewalls. You don't always have to subscribe to a
list in order to benefit from information on it, some have archives online like
Bugtraq and some are linked to a newsgroup where important information is
reposted like comp.society.cu-digest.
Bugtraq
Bugtraq is one of the most well known of all the security mailing lists, you
can check out it's archives or subscribe by mailing listserv@netspace.org with
the text 'SUBSCRIBE bugtraq' and your first and last names in the body of the
email [not the subject line].
Bugtraq is a list for detailed discussions on Unix security flaws and ways to
fix them. Among other things it is about defining, recognizing, and preventing
use of security holes and risks. It provides information on Unix related
security holes/backdoors [past and present], announcements, advisories or
warnings and ideas and future plans or current works dealing with Unix security.
Linux security
linux-security-request@redhat.com
Linux alert
To subscribe email linux-alert-request@redhat.com with the text 'Subscribe' in
the email's body [not the subject line].
Firewalls
To subscribe send email to majordomo@greatcircle.com or send email to
Firewalls-request@greatcircle.com with the text 'SUBSCRIBE firewalls' in the
body of the message [not the subject line].
This list provides information on the implementataion of internet firewall
security systems and issues related to them. It is an outgrowth of the Firewalls
BOF session at the Third UNIX Security Symposium in Baltimore on September 15,
1992.
Academic firewalls
To subscribe send email to majordomo@net.tamu.edu.
Euro firewalls
To subscribe to this list email majordomo@gbnet.net with the text 'SUBSCRIBE
firewalls-uk [your email address]' in the body of the message [not the subject
line]. This list is about firewalls from a European perspective [is there
actually a difference?].
8 Legged grooving machine
This list is for *detailed* discussion of security holes: what they are, how
to exploit, and what to do to fix them. The mailing list is only used for
mailing advisories, there is no 'junk mail'.
To subscribe to the list email majordomo@8lgm.org or
8lgm-list-request@8lgm.org with 'subscribe 8lgm-list' in the message's body, not
in the subject line.
Computer underground Digest
Send email to listserv@vmd.cso.uiuc.edu to subscribe to this list. CuD is
available as a usenet newsgroup, comp.society.cu-digest.
Intrusion detection systems
This list discusses techniques used to detect intruders in computer systems
and computer networks, methods used by intruders [known intrusion scenarios] and
scripts and tools used by hackers among other things. To subscribe to it email
majordomo@uow.edu.au with 'subscribe ids' in the messages body.
Sneakers
Mail subscription requests to majordomo@cs.yale.edu with 'SUBSCRIBE sneakers'
in the messages body [not the email's subject line okay? Do I really have to
write this each time?].The Sneakers mailing list is for discussion of legal
evaluations and experiments in testing various internet firewalls and other
TCP/IP network security products. "Above board" organized and/or loosely
organized wide area tiger teams [WATTs] can share information, report on their
progress or eventual success here.
I think what they're trying to say is 'play nice now kiddies'. They have a
webpage with instructions on un/subscribing as well as posting, and where
notices and pointers to resources may be put up from time to time. It's at:
http://www.cs.yale.edu/HTML/YALE/CS/HyPlans/long-morrow/sneakers.html
One hell of a url eh?
Happy hacker
To subscribe mail cmeinel@techbroker.com with the text 'SUBSCRIBE' in the body
of the email [not the subject line]. This list is one primarily for hacking,
security and internet related material aimed at 'newbies'. Speaking personally
[no offense to anyone intended] I would consider the factual content of some
of the articles I've seen from the list, and the group behind it, suspect at
best and blatantly incorrect at worst, still - to each their own. Carolyn
Meinel, the woman who runs the list, has stuck with it despite being victim
to credit card fraud and email bombing campaigns, etc, etc. I gotta respect
her for not giving in after such malicious attacks.
Thats it for now, but I will follow up this with another article on log files
and maintaining your system and keeping it secure.
Rue-the-Day
root@Rue-the-Day.net
