Linux hardening--Great for us Semi-Newbs...

**nokiaxv2** · September 16th, 2004, 7:51 AM

When you're bored and wanna know more...

Quote:

Linux hardening
[at] Articles -> Security Jan 08 2003, 10:51 (UTC+0)
bugghy writes: This is a basic/advanced guide to hardening linux. This isn't meant to be a perfect choice for everyone. Linux isn't secure out of the box (well most of it is) but it's your job to secure it and make it suit your needs. It has some security advice and different tools presentation. NOTE: This is not a good written tutorial (cos I am lazy) and it's won't be updated. These are just tips

some more advanced than others.

CONTENTS
=====================================

1. Introduction
2. Basic advice
3. Advance advice
4. Basic commands
5. Basic help
6. Link of the day
7. Last words

=====================================

Written by: Bugghy
E-mail: bugghy[at]home.ro
URL: www.bugghy.home.ro

Comments/errors/bugs/jokes > bugghy[at]home.ro

2. Basic advice
===============

A. GPG (www.gnupg.org)
Download & install. Create a key (&read the docs)
Go to your linux distros' homepage, download their public key, import it to your public key ring
and sign it. (read the docs)
Check the rpm binaries you download from mirrors against their key:
rpm -Kv lolthisiskewl.rpm
Check result:
MD5 sum OK: fcabce3438eb9c
gpg: Good signature from "Red Hat, Inc "
If you get "public key not found" then the source was modified. (or your key isn't valid for
this RPM)

B. Check the your linux distro's errata pages: (www.redhat.com/apps/support/updates.html)
1) Bug fixes fix errors that come with previous versions of programms
2) Security advisories fixes security vulnerabilities in system
3) Package enhancements provides additional features

C. Disable not needed services (echo, daytime, others?)
Edit /etc/inetd.conf or (/etc/xinetd.conf and /etc/xinetd.d directory)
In /etc/inetd.conf, comment out any unneded services (like echo). Any attacker could replace
echo by a backdoor program that looks&feels exactly the same.
In /etc/xinetd.d remove the unneded services, or disable them (edit them and set "default: off")
or add a "#" before the "service echo" part (comment it).
Restart (x)inetd (/etc/rc.d/init.d/xinetd restart).
Disable any R-services you have. (rlogin and rsh). They contain security vulnerabilities, and
are usually subject to IP/DNS/ROUTING spoofing. Telnet and ftp are unsafe too.

Disable stand-alone services:
"ps -auxe |less" to look at all the services
"ls -la /proc/servicepid" and look at the "exe -> /usr/sbin/service" to get its path
Check the startup scripts to see where the process gets executed. (grep -r sshd /etc)
Disable the service from the /etc/ scripts and kill it.

Use "netstat -apn|less" to check for other daemons. Disable the unneded ones and configure the
remaining.

Well-known port are those bellow 1024. These can only be root owned processes. If you get a new
port openned there, and you didn't open it, you're in deep [at][at][at][at] ;p
Registered port are those between 1024 and 65535. Any normal priviledged user can run a daemon
on any of these ports.

D. Disable setid and setgid files.
If you (or programs in your system) don't need the +s bit, remove it. Man find for more info.
Or get a suid scanner from packetstorm.

E. /etc/securetty
/etc/securetty is the file which defines where the root can log from
Comment all lines except the ones containing: console, tty1-6 (physical ttys).

F. /etc/motd /etc/issue (http://ciac.llnl.gov/ciac/bulletins/j-043.shtml)
Edit /etc/motd and put a disclamer there, stating that any malicious activities will be logged
and sent to the local police department (or smthg bigger) Also modify /etc/issue.

G. Manage log files:
man+exec: lastlog, last, w, who, dmesg
exec: ls -la /var/log
Look through the logs, check /etc/syslog.conf

If we scan host bugghy using the tcp connect() scan:
/var/log/maillog :
Nov 22 15:47:13 bugghy sm-mta[1190]: gAMDlDek001190: localhost [127.0.0.1] did not issue
MAIL/EXPN/VRFY/ETRN during connection to MSA
/var/log/messages :
Nov 22 15:47:13 bugghy telnetd[1135]: ttloop: read: Connection reset by peer
/var/log/secure :
Nov 22 15:47:13 bugghy in.telnetd[1145]: warning: can't get client address:
Connection reset by peer
Now we telnet to port 23, fail 1 password and login as root:
/var/log/lastlog
root pts/1 Nov 22 15:47:13 +0002 2002
/var/log/secure :
Nov 22 15:47:13 bugghy in.telnetd[1384]: connect from 127.0.0.1
And there's /var/log/faillog too.

A good admin must know how to look through the logs (and a good hacker). This is usually done
through practice. Some admins "tail /var/log/* > logs;pico logs" skimming through the output.

H. Scan yourself from the outside (and from the inside):
1) from outside: nmap -sX -P0 -f -oG server1.new -p 1-65535 -g 53 -n -r server1
(man nmap to decrypt what I've typed. You'll probably be scanned by hackers this way.)
(this will take tooooo long so I'll really suggest:
nmap -sT server1 -p 1-65535 -P0 -oG -n server1.new
A good admin could make a bash script that like:
nmap -sS server1.net > /tmp/1.tmp
diff /tmp/1.tmp /root/.goodscan 1> /var/log/hacked 2>&1
cat /var/log/hacked
And put it in /etc/rc.d/rc.local like
echo "sh /usr/local/sbin/antihack.sh" >> /etc/rc.d/rc.local
Now : echo "tail --follow /var/log/hacked" >> /root/.bashrc

2) from inside: (you could use the same nmap)
mount /mnt/floppy
/mnt/floppy/md5sum /bin/netstat > /var/log/md5.netstat.log
diff /var/log/md5.netstat.log /mnt/floppy/.md5.netstat.log
(diff's netstat's md5sum with the valid md5sum)

Vaious other options:
H. disable CTRL-ALT-DELETE
I. password single-user
J. allow root only shutdown/reboot/halt
K. use tcp wrappers
L. disable not needed programms. You should put these programms "chmod 500".
M. run restricted environments (bash -r)
N. set quota for users
O. password LILO prompt
P. get a LKM that protects vs LKMs

vs /dev/kmem patching (or even vs buffer overflows) and fakes OS
Q. disable CTRL-ALT-DELETE
R. disable any possibility do d/l files from the net. (rpm lynx ftp wget ...) Any1 hacking you will not
have anything to do on your maching (rm -rf /*; echo "?")

3. Advanced advice
==================

A. Unknown root login:
"passwd operator" and use this account as the root one.
"rm -f /root/.bash_history; ln -s /dev/null /root/.bash_history"
Now everytime you login, do a "lastlog -u root" and check to see if somebody hacked you.
(this is just a quirk, success NOT guaranteed)

Another ideea would be to put another user as gid uid 0 and put root as uid gid 1000.
Root is not all mighty now.(and you'll have problems with some scripts/proggies)

B. /etc/login.defs (man login.defs for all the options)
If you suspect you'll be the subject to bruteforce, increase FAIL_DELAY.
Set FAILLOG_ENAB to yes. (logs to /var/log/faillog login failures)
Set CONSOLE to /etc/securetty
Set NOLOGINS_FILE to /etc/nologin (or other). Put a statement in that file indicating non-root
logins are disabled. (Can be handy when you run administrative programms that slow down the system)
Set NOLOGIN_STR to NOLOGIN. Now edit /etc/passwd and put a NOLOGIN in each "shell" field of
users/services needn't login.
Set PASS_MAX_DAYS, PASS_MIN_LEN, PASS_WARN_AGE to the appropriate values. 100, 6, 10 seems a
good choice for some systems. Shell providers will disagree.
Set LOGIN_RETRIES to 3 and LOGIN_TIMEOUT to 20 for enhanced security.
Set UMASK to 0066 so you create 600 files.

C. Put daemons in chroot environment. Use Jail (version 1.9 for linux) on
http://www.gsyc.inf.uc3m.es/~assman/jail/ It's a program that makes a jail environment, the easy way.

D. Openssh (www.openssh.org) - a must for any remote administration task
Read the docs, download the latest version. Patch it to the last version as there are numerous
exploits for it.
"su - bugghy" "ssh-keygen -d" Your choice for the passphrase. "cat ~bugghy/.ssh/id_dsa*" Your
public and private keys. Your .pub key can be distributed.
"cp ~bugghy/.ssh/.id_dsa ~bugghy/bugghy.pub" And mail it to the ssh server's admin.
He will move it to "~bugghy/.ssh/authorised_keys2". Another file will appended on the second
line of the file. (Each key is one line long.)
Now "ssh server.net" and login.
Edit /etc/ssh/ssh(d)_config (man ssh(d) for the options) Add sshd to inetd.

E. Sudo (www.courtesan.com/sudo) (man sudoers)
It executes commands as root (or another user).
"visudo" and uncomment "%wheel ..." with pass. No users in group wheel can sudo.
sudo -l = displays allowed commands
sudo -v = validate the sudo exec for another 5 minutes.
sudo -k = loggs off
sudo -u = runs command as user

If "%wheel ALL=(ALL) ALL" is enabled and user emind is in group wheel:
$ id
emind
$ ls -la /home/bugghy/
$ /bin/ls: /home/bugghy/: Permission denied
$ sudo -u bugghy ls /home/bugghy
Password: emind's password
drwx------ 3 bugghy users 4096 Nov 18 19:48 .[at][at][at][at][at]X/
$ sudo -k
Session is killed. Next session would require a password again.
Play more with it and read the docs.

Sample /etc/sudoers:
root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL
andrew lol.dial-in.com = /bin/ping, /bin/netstat -apn, /usr/bin/lsof -ai, /usr/bin/nmap 127.0.0.1
# the "network" user
woman gate.isp.com = (chatter) /bin/[at][at][at][at][at]x
# woman from gate.isp.com runs /bin/[at][at][at][at][at]x as chatter

Log everything:
pico /etc/syslog.conf
Add "local2.debug /var/log/sudo" to it.
touch /var/log/sudo
kill -HUP `pidof syslogd`

G. Scandetd (ftp://ftp.rdsor.ro/pub/Linux/Security/scandetd)
author: Michal Suszycki (mike[at]wizard.ae.krakow.pl)
Scandetd is daemon which tries to recognize port scans. (note the "tries" word, it didn't succed
in all my tests). The code was based on IpLogger Package by Mike Edulla (medulla[at]infosoc.com). For
installation just read the README.
Other options would be Scanlogd (www.openwall.com/scanlogd) and p.0.f.

I. p.0.f. (http://www.stearns.org/p0f/) - passive OS fingerprinting tool
Read the readme.
Another variant (but with less features is "siphon")
Logs will look like this:
193.231.236.40: UNKNOWN [5840:61:1460:1:-1:0:0:44].
+ 193.231.236.40:33504 -> 62.251.85.18:113
148.235.147.168 [21 hops]: Linux 2.2.9 - 2.2.18
+ 202.163.234.5:3293 -> 62.251.85.18:21 (timestamp: 140358963 [at]1037800385)
193.231.28.159 [9 hops]: Linux 2.4.2 - 2.4.14 (1)

K. Tcpdump (www.tcpdump.org)
I get 100 packets in 40 seconds when I'm not chatting/browsing (time tcpdump -a -c 100)
Man tcpdump. Sample commands follow:
"tcpdump -a -e -i eth0 -p" sniffs eth0 in non promiscous mode.
"tcpdump -w packets.log -vv" lots of output -> to file packets.log
"tcpdump -r packets.log" reads from file
"tcpdump arp" shows the arp traffic
"tcpdump icmp -n -i eth0 -p" who is pinging us

"tcpdump host lol.it" and ping lol.it from another console, -vv for more info.
"tcpdump -i eth0 host lol.it and host mycom.com" sniffing my brains out

A packet:
14:05:43.656101 62.241.83.12.1146 > 217.57.107.195.23: S 3712763562:3712763562(0) win 5840 (DF) [tos 0x10]
- 14:05:43.656101 = timestamp.milliseconds
- 62.241.83.12.1146 = ip.port
- > 217.57.107.195.23 = connection to ip.port
- S = syn flag
- 3712763562:3712763562(0) = ISN:ISN+data (0 = no data)
- win 5840 = windows size > /etc/cron.weekly/antivir.cron
To enable all options: www.antivir.de/order/privreg/order_e.htm (you'll receive hbedv.key which
you must put in /usr/lib/AntiVir
Update the virus defs from the site. (.vdf files)

P. OPIE (www.inner.net/opie) - OTP implementation
Opie uses one time password for login. If the passwords are sniffed, they can't be used again.
e.g. user "dunno" has pass "434 312 233" for login nr "1". After login, he can't log in with
passwords for login nr "1" but for passes for login nr "2" (that can be changed accordingly)
I would suggest d/l the rpm because, it's just simpler/faster.
"opiepasswd -c root" Put your pass. It'll show your PASS SEQ and SEED nr.
"opiekey -n 10 `opieinfo` > /root/opiepasses.txt". It'll ask you for your first pass.
Now you have a file with the following passes, for opiesu/opielogin/opieftpd
"su - bugghy" and "opiesu" It'll show smthg like: "otp-md5 498 bu6248 ext"
Now "cat /root/opiepasses|grep 498" and input all those words. You're root.
"^D" and try again. "opiesu" Shows: "otp-md5 497 bu6248 ext" This asks for pass nr 497.
Ass long as the attacker doesn't have the pass list, he will be unable to predict your pass.
If everythig works, replace su/login with a link to opiesu, opielogin... (test them carefully)
To show your passes: "opiekey 498 bu6248" for pass nr 498.
Don't use opiekey from insecure connections.
You can use the opiegen, to log in remotely.
"opiegen" And input: "Challenge: otp-md5 497 bu6248 ext" "Secret pass phrase: yourpass" and
it'll give you the secret pass.

opieftpd: edit the (x)inetd conf file and add this service. kill -HUP the server. Now you can
ftp using the one time passes.

NOTE: This doesn't encrypt transmissions (so it's plain text), but it provides a layer of
security by preventing password theft.
If you get a "Sorry, but you don't seem to be on a secure terminal." then type: "TERM=lol"
This was an example. To implement OPIE for more users, read the man pages.

Q. Honeypots:
The simplest: http://sourceforge.net/projects/single-honeypot
The simple: www.vmware.com
More info: http://www.seifried.org/security/ids...re-basics.html
The usefull: user-mode-linux.sourceforge.net
The honeypot: http://www.citi.umich.edu/u/provos/honeyd/
Other: http://www.tracking-hackers.com/papers/

R. Rootkits and other stuff: http://www.8200.org/

6. Link of the day
==================

!!!The lazy admin way: Bastille does almost all of this work for you: --> www.bastille-linux.org
(by work I mean smthg you could have done manually more/less)
ftp://ftp.pangeia.com.br/pub/seg/pac/chkrootkit.tar.gz

**miakeru** · September 16th, 2004, 1:02 PM

That is definitely a good starting point for any budding server admin. It does have some very important issues, however.

First, I noticed that it is a very general document. It tells you that you should do things, like: "Disable not needed services (echo, daytime, others?)" and gives only "Any attacker could replace echo by a backdoor program that looks&feels exactly the same." for a reason. What I think it should have focused more on was specifics. Be specific in which services it says to disable. I can tell you that if you were to follow it's directions and disable echo and daytime, you hardly be more secure than you were with them running. In fact, I bet most servers aren't running either of those by default.

Second, with all of what it provides, it lacks giving good descriptions of what it's asking to do. It merely tells the reader to perform many actions, especially near the end, but gives no description of what this action will be doing to the users system -- scary.

Now, this wasn't to bash the document or anything. I think it is a great launch pad for new system administrators. I just want to keep people from using this as 'the system admin bible' or anything like that.

Always research a command or program before you install and run it. You should know exactly what it will and won't do to your system before you make use of it.

**nokiaxv2** · September 16th, 2004, 1:10 PM

I appreciate your kind words.

However the author did make clear his purpose of this article. He also admitted his "lack of enthusiasm" before hand as well. As I said, this is "great for us semi-newbs, " in which case; I'm not really in that category. I think this article puts the user in a situation to ask the question, "why am I doing this?" and "What exactly does this do?" It's more or less a crutch, to prepare users for the "next level" of server administration.

I think the author realized it in good faith hoping that the readers, with limited knowledge of the process of Linux security and system administration, would actually pursue more information beyond his "unhealthy" article.

In any case, I'm pretty sure readers, especially those who are already terrified of their systems, would ask the important questions before jumping right into things.

Your comments are appreciated. Thank you.

**Kayla** · September 16th, 2004, 1:35 PM

All of the advice is good! It is good to see the server board getting more activity, thanks to you both.

**miakeru** · September 16th, 2004, 1:51 PM

Quote:

Originally Posted by Kayla - Admin

All of the advice is good! It is good to see the server board getting more activity, thanks to you both.

I hope it continues to do so! I love discussing server-related topics.

November 20th, 2004, 4:15 PM

Or the easy way to do is to have someone else Harden your Linux box.

The Bastille Hardening System attempts to "harden" or "tighten" Unix operating systems. It currently supports the Red Hat, Debian, Mandrake, SuSE and TurboLinux Linux distributions along with HP-UX and Mac OS X.
Bastille works on Red Hat Enterprise 3 and Fedora Core 1 and 2!

We attempt to provide the most secure, yet usable, system possible. The project is run by Jon Lasser, Lead Coordinator and Jay Beale, Lead Developer, and involves a number of developers, beta-testers and concept-creators. Bastille Linux was developed with several major goals:

COMPREHENSIVENESS
Bastille Linux draws from every available major reputable source on Linux Security. The initial development integrated Jay Beale's existing O/S hardening experience for Solaris and Linux with most major points from the SANS' Securing Linux Step by Step, Kurt Seifried's Linux Administrator's Security Guide, and countless other sources.

INSTRUCTIVENESS
Bastille Linux has been designed to educate the installing administrator about the security issues involved in each of the script's tasks, thereby securing both the box and the administrator. Each step is optional and contains a description of the security issues involved.

COMMUNITY
Once the initial development was near complete, we brought the effort to the developers of the Bastille Discussion mailing list. Further, we began soliciting outside suggestions and testing. The script was GPL'd promptly and the Specification shared.

**Aric** · December 20th, 2004, 1:36 AM

Be very careful with Bastille or any other third-party security tool you don't completely understand. Bastille can do a good job of hardening your typical Linux box, but remember that it isn't designed with CPANEL in mind and some of the suggestions it makes assumes you aren't trying to run web hosting on your server. You can very quickly lock yourself and everyone else out of your server or otherwise break things if you don't know what you are doing.

Catch-22, I know...

September 16th, 2004, 1:10 PM	#3 (permalink)
nokiaxv2 Surpass Fan Seasoned Poster Joined in Jun 2004 Lives in Natchitoches, LA Hosted on pass7 78 posts Gave thanks: 0 Thanked 0 times	I appreciate your kind words. However the author did make clear his purpose of this article. He also admitted his "lack of enthusiasm" before hand as well. As I said, this is "great for us semi-newbs, " in which case; I'm not really in that category. I think this article puts the user in a situation to ask the question, "why am I doing this?" and "What exactly does this do?" It's more or less a crutch, to prepare users for the "next level" of server administration. I think the author realized it in good faith hoping that the readers, with limited knowledge of the process of Linux security and system administration, would actually pursue more information beyond his "unhealthy" article. In any case, I'm pretty sure readers, especially those who are already terrified of their systems, would ask the important questions before jumping right into things. Your comments are appreciated. Thank you. __________________ -( NokiaX )- http://www.eclipse-business.com Saprus Dedicated This made me "LoL" "Unleashedgamers (5:39:21 AM): where you a script kiddie?"

Thread Tools	Search this Thread
Show Printable Version Email this Page	Search this Thread: Advanced Search

September 16th, 2004, 1:02 PM	#2 (permalink)
miakeru Web Hosting Super Ninj4 Super #1 Joined in Sep 2003 Lives in Fullerton, CA 1,581 posts Gave thanks: 0 Thanked 2 times	That is definitely a good starting point for any budding server admin. It does have some very important issues, however. First, I noticed that it is a very general document. It tells you that you should do things, like: "Disable not needed services (echo, daytime, others?)" and gives only "Any attacker could replace echo by a backdoor program that looks&feels exactly the same." for a reason. What I think it should have focused more on was specifics. Be specific in which services it says to disable. I can tell you that if you were to follow it's directions and disable echo and daytime, you hardly be more secure than you were with them running. In fact, I bet most servers aren't running either of those by default. Second, with all of what it provides, it lacks giving good descriptions of what it's asking to do. It merely tells the reader to perform many actions, especially near the end, but gives no description of what this action will be doing to the users system -- scary. Now, this wasn't to bash the document or anything. I think it is a great launch pad for new system administrators. I just want to keep people from using this as 'the system admin bible' or anything like that. Always research a command or program before you install and run it. You should know exactly what it will and won't do to your system before you make use of it.

September 16th, 2004, 1:35 PM	#4 (permalink)
Kayla Marketing Maven Surpass Staff Joined in May 2003 Lives in Orlando 24,749 posts Gave thanks: 946 Thanked 806 times	All of the advice is good! It is good to see the server board getting more activity, thanks to you both.

November 20th, 2004, 4:15 PM	#6 (permalink)
Dark Matter Guest n/a posts	Or the easy way to do is to have someone else Harden your Linux box. The Bastille Hardening System attempts to "harden" or "tighten" Unix operating systems. It currently supports the Red Hat, Debian, Mandrake, SuSE and TurboLinux Linux distributions along with HP-UX and Mac OS X. Bastille works on Red Hat Enterprise 3 and Fedora Core 1 and 2! We attempt to provide the most secure, yet usable, system possible. The project is run by Jon Lasser, Lead Coordinator and Jay Beale, Lead Developer, and involves a number of developers, beta-testers and concept-creators. Bastille Linux was developed with several major goals: COMPREHENSIVENESS Bastille Linux draws from every available major reputable source on Linux Security. The initial development integrated Jay Beale's existing O/S hardening experience for Solaris and Linux with most major points from the SANS' Securing Linux Step by Step, Kurt Seifried's Linux Administrator's Security Guide, and countless other sources. INSTRUCTIVENESS Bastille Linux has been designed to educate the installing administrator about the security issues involved in each of the script's tasks, thereby securing both the box and the administrator. Each step is optional and contains a description of the security issues involved. COMMUNITY Once the initial development was near complete, we brought the effort to the developers of the Bastille Discussion mailing list. Further, we began soliciting outside suggestions and testing. The script was GPL'd promptly and the Specification shared.

December 20th, 2004, 1:36 AM	#7 (permalink)
Aric Just Some Guy.. Comfy Contributor Joined in Oct 2003 127 posts Gave thanks: 0 Thanked 5 times	Be very careful with Bastille or any other third-party security tool you don't completely understand. Bastille can do a good job of hardening your typical Linux box, but remember that it isn't designed with CPANEL in mind and some of the suggestions it makes assumes you aren't trying to run web hosting on your server. You can very quickly lock yourself and everyone else out of your server or otherwise break things if you don't know what you are doing. Catch-22, I know...

Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)