💾 Archived View for clemat.is › saccophore › library › ezines › textfiles › ezines › DOJ › doj1-03.t… captured on 2022-01-08 at 15:31:12.
⬅️ Previous capture (2021-12-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