• RSS
  • Twitter
  • FaceBook

Security Forums

Log in

FAQ | Usergroups | Profile | Register | RSS | Posting Guidelines | Recent Posts

[Tutorial] Securing a linux machine - Detailed How To

Users browsing this topic:0 Security Fans, 0 Stealth Security Fans
Registered Security Fans: None
Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> UNIX // GNU/Linux

View previous topic :: View next topic  
Author Message
paranoid
Just Arrived
Just Arrived


Joined: 13 Aug 2002
Posts: 0


Offline

PostPosted: Tue Aug 13, 2002 11:05 pm    Post subject: [Tutorial] Securing a linux machine - Detailed How To Reply with quote

Can someone suggest what I should be looking for to secure my mandrake machine to a reasonable standard:

I have the:
-latest distribution
-latest version of each server, i.e apache / mysql

Im more concerned with where I should be looking for possibly security breaches and general administration.

Id rather not use intrusion detection systems as would prefer to learn about what I am actually doing.

I periodically check through /var/log/messages
which others should I be paying special attention to ?

Also where do I put IP restrictions on incoming SSH. I know this can be done through a firewall but im sure it can be done via configuration files or similar to /etc/hosts.allow
Back to top
View user's profile Send private message
Journeyman
Just Arrived
Just Arrived


Joined: 06 Aug 2002
Posts: 0
Location: Earth

Offline

PostPosted: Wed Aug 14, 2002 12:30 am    Post subject: Reply with quote

well there is SAINT but it costs money now
Id suggest SARA and there is also SATAN but its a bit outdated

http://www-arc.com/sara/
Back to top
View user's profile Send private message AIM Address
ShaolinTiger
Forum Fanatic
Forum Fanatic


Joined: 18 Apr 2002
Posts: 16777215
Location: Kuala Lumpur, Malaysia

Offline

PostPosted: Wed Aug 14, 2002 12:59 am    Post subject: Reply with quote

Latest Distro/Servers don't make nuts difference really.

IDS don't take away the fact that you can learn what you are doing they just look at each packet and see if there is anything suspect about it.

Please read below:

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

(1) What makes a good password?

A good password will consist of numbers, letters (upper and lower case), and shift characters. Additionally, it will be of a good length, at LEAST eight characters. Further, a good password will not contain any easily-guessable information, like names (human or pet), anniversaries, birthdays, or the like. While a password should be difficult to guess, it should not require that the user write it down. To increase ease in recall of passwords, may use mnemonics ("3g8Ah!wRT?" becomes "Three goats ate all hay! Where are they?") or practice their "leet-speak" ("barnyard forever" becomes "64Rn|\|y4RD |=0r3ver").

2) Lockdown 101 or HOW-TO be secure

This is, of course, not an all-inclusive list, but rather a simple guide to creating a fairly secure system.

A) ifconfig $INTERFACE down

Turn off the your connection to the outside. You just installed your distribution, and there are criminals out there (who, by the way, are most likely *not* hackers) that would just love to root your juicy little box.

B) Kill ALL services to the outside world. This is one of the most crucial steps. By default, many distributions enable the oft-exploited fingerd, RPC, and wu_ftp. Turn them all off. Turning some services off (like sshd) will be as easy as killall -9 sshd (or, for the Sys V minded, /etc/rc.d/init.d/sshd stop). However, the services implemented by inetd (or xinetd) will require an editing of configuration files and the 'killall -HUP xinetd' call.

C) When there are NO services running, you can ifconfig $interface up. However, it is still the best practice to retrieve the necessary files from another computer and install them from a medium (such as cdrom) rather than download them off the internet.

Short story: if you don't have to bring your network device up, don't.

D) Compile. Install. Tweak. Repeat. Install the latest versions of any services you will use (sshd and apache come to mind).

E) Edit init files. Using rename (From S* to K*), deleting symlinks, commenting out of BSD startup scripts, or chkconfig, disable the services that you don't want/need from starting. Note that you must disable the 'portmap' to keep RPC from loading.

F) Obtain and install nmap. Run it and repeat E until you have no unnecessary ports open.

G) Install an IDS. Snort is a very good program that is powerful, robust, and easy to tweak for personal needs. It comes highly recommended.

H) Reboot.

Tools such as Bastille Linux can tweak config files and scripts for the security-minded. A great tool to audit your netowork is Nessus. Nessus is a daemon that waits on a machine until the Nessus Client tells it to scan a machine. For security's sake, nessusd should only allow connections from localhost, and be restricted to scanning the local network. Nessus can perform a very nice security audit, checking for information-leaking banners, vulnerable services, and even vulnerable cgi scripts.

Finally, make sure to watch your logs. Using the command tail -f $LOGFILE from a desktop console that has had the border removed and made transparent, logs can be made to scroll across your desktop, not taking up much room at all. Using tail -f, one can easily and unobtrusively moniter Snort's alert log, /var/log/messages, /var/log/secure, and the httpd access and error logs.

Make sure to keep your daemons and other programs (especially those that suid!) updated to avoid being rooted.

(3) Lockdown 201 or HOW-TO be very secure

A) Security through obscurity. Install portsentry. Have it open a few ports that don't belong on your OS. This will foil port-based OS guesses (such as that used by nmap). Recompile daemons to report an incorrect version. Two famous OS fingerprinting culprits are sshd and apache. Either compile the sources, replacing the offending text (sed and grep are your friends) or open up your favorite hex editor and hack away at the binary (make sure to back it up first!). There are a few methods to porting false banners: the obvious way and the sly way. The obvious way involves replacing banner text with obviously false text (such as having a Unix/Apache server report Goat/Hayburner). The second way is a bit craftier, and a bit harder to pinpoint. This involves a complete mask of the operating system, for example configuring an Apache/Unix daemon to report IIS/Microsoft. This method, when coupled with opening Windows ports with portsentry, is quite effective in outwitting would-be vandals.

While security through obscurity is often the subject of ridicule, keep in mind that it, like any security system, is only part of the greater blanket of security.

It should be noted that the wonderful tool from Ofir Arkin, xprobe, will still be able to OS fingerprint, since it relies on differences in ICMP and UDP responses.

A wily sysadmin would disable ICMP messages and unsolicited UDP responses with their stateful firewall.

Security through obscurity is not, mind you, confined to the network.

Programs such as ps (especially when used with the switches 'aux') can reveal valuable information about running processes, and may include IP addresses that can give hints on network topology. Unless a user needs access to such programs, they should be disabled. Other information-giving programs include dmesg (which prints kernel messages), lsof (lists open files), netstat (lists network connections) and ifconfig (lists network interface information). Further, world-readable config files can provide information to a potential attacker. Some files, which should be owned by root and not world-readable, contain plaintext password files, as any reader would necessarily need root privelages anyway. Sometimes, however, mistakes happen and such a juicy file will be readable by everyone, Random J. User included.

B) Proper network setup

A good network setup will not allow access to or from the LAN, save through highly customized systems. A poor network setup would look like this:

{internet}---[hub]
|--- LAN box 1
|--- LAN box 2
|--- ...

With this setup, ALL boxes are open and potentially vulnerable to the outside internet. A different, though not recommended, setup is the following:

{internet}---[router]
|--- Server 1
|--- LAN box 1
|--- LAN box2
|--- ...

In this setup, the network is isolated on the subnet, but is still vulnerable.

Since the server is on the same subnet, an attacker would have access to the entire network if they rooted it [the server]. A better setup would be to isolate the servers on their own subnet.

{internet}---[router]
------|-----
| |
| |
{Servers} {LAN}

This is a good setup, with only one major drawback: it allows possibly malicious traffic to talk to the router. With a single exploit (remote kernel, say) an attacker could have access to the LAN. However, an attack against the servers would leave the LAN relatively uneffected, since the two are separated. The best configuration will include a stateful firewall, be it a purchased solution or a simple *nix box running iptables:

{internet}---[firewall]-+-[router]
|D |
|M |
|Z |
{Servers} {LAN}

As you can see, this network uses a DMZ to completely isolate servers from the LAN. This way, even if a server is exploited, the LAN would remain secure. Further, the firewall itself could be rooted, and the LAN would still have a fair degree of security. Note that it is also smart to turn the router above into a firewall by simply installing and running iptables.

A final step to building a secure network is the installation of an IDS(Intrusion Detection System). One of the most common IDS, Snort, is actually a Network IDS (NIDS).

Basically, it looks at each and every packet that crosses its NIC and makes a note if the traffic is suspicious. A NIDS is usually run from a box within the DMZ, as opposed to the firewall or router itself, to minimize the chances of it being compromised.

C) Chroot

Chroot is a method of "locking down" a program, isolating it. Basically, it makes the chrooted program believe that a specified directory is /. Of course, it can take some work setting up a chroot jail, as all libraries and conf files will need to be copied. However, if a chrooted daemon is rooted, it will still be locked in it's chroot jail, unable to wreak havoc. This method has transformed countless security disasters into a short cleanup job. An important part of chrooting is to make the filesystem appear to be non-chrooted. This way, the would-be vandal would have no way of knowinng that he was, in fact, absolutely no threat to the rest of the system.

Many admins, however, use too much (or, more accurately, poorly-implemented) security. For example, some systems will permanently block an IP address after three failed loging attempts. By spoofing their IP address, an attacker could arbitrarily lock a user (or subnet, or router)out of a system.

C) Priveledge seperation

Often used in conjuntion with chroot, privelage separation is the act of separating the core of a deamon from its children. While the daemon, hat needs to be root, sits at uid 0, its children (who actually serve the data) can be made to run at a lower (user-equivalent) privelage level. This way, if an attack on the daemon is successful the attacker only gains the separated privelage (user) rather than full root access. This becomes very powerful when coupled with chroot, as it is impossible for a non-root user to break from a chroot jail.

(4) Lockdown 202 or Physical security

An oft-overlooked aspect of *nix security is physical security. Aside from post-it notes containing passwords, many don't know how vulnerable most systems are when accessed through the terminal. Of course, one can never realistically stop a user from pulling the plug.

Although it's fairly obscure, physical security is quite easy to implement on it's base levels. Simply putting a password file on the boot loader and booting into the OS immediately provide a very good level of security.

Further, disabling floppy and cd booting and adding a BIOS password can make a quite secure box. Of course, if the box is easily accessible, the harddrive can still be stolen. This is where harddrive encryption comes in. Using the PPDD driver (http://linux01.gwdg.de/~alatham/ppdd.html), one can transparently encrypt an entire partition or harddisk. This allows seamless reading of data, but prevents a thief from gaining access to sensitive data. One could go a step further and install various locks and light-detecting sensors inside the case itself, but such measures are often quite costly. Finally, one should remember not to leave terminals unattended. Programs such as xlock (for X) and vlock (for terminals) can keep unauthorized users from accessing the computer directly. Note that a quick ctrl+alt+backspace will kill the X server, dropping the user into a terminal. However, this can be disabled.

A quick review:

o Disable cd/floppy boot (wouldn't want the partition mounted from a rescue cd)
o Add BIOS password (administrative only) (wouldn't want floppy boot enabled)
o Password the bootloader (wouldn't want init=/bin/bash rw passed to LILO)
o Immediately boot a single kernel (see above)
o Encrypt the harddisk (wouldn't want a thief to get access)
o Disable open terminals/X sessions

It should be noted that security is not a one-step process. A great firewall, up-to-date binaries and the best available physical security are but parts of the security process. Just blocking connections won't be great security; neither will chrooting everything or running a single IDS/NIDS. Security is not an either/or situation; it is thoroughly and-based.


Some Added Info:

Firewalls

Firewalls come in two basic flavors: hardware and software. A hardware firewall is a dedicated machine (be it a small, commercially available box or a *nix box running iptables or ipchains) placed between a LAN and the outside network. A software firewall, however, is not a true firewall at all. It is simply a piece of software that monitors port usage and blocks or denies access. As such, it is no more a true firewall than MS Outlook.

Hardware firewalls can be broken down into three main categories:

Packet filter

(stateless), packet inspection (stateful), and proxies.

Packet filtering (IPCHAINS)

Packet filtering firewalls are simple and rule-based. The administrator simply tells the firewall which packets to relay and which to drop. A breeze to set up, packet filtering firewalls are the most common (and cheapest) firewalls available. Unfortunately, rulesets are based on addresses and ports only, and data payload is not inspected.

The oft-misnamed Windows port-monitoring applications usually use packet filtering, but are not firewalls due to the fact that they reside on the connecting machine.

An analogy for stateless firewalls would be a post office worker examining envelopes on a conveyor, tossing out those that have certain source or destination addresses.

Packet inspection (IPTABLES)

Packet inspection firewalls take packet filtering to the next level. They look at each and every packet, determining the state of the connection. For example, ACK floods have little effect on stateful firewalls because they immediately drop ACKs that have no SYN. Further, stateful firewalls examine the data of each packet, making the logs of stateful firewalls much more informative.

An analogy would be the factory worker watching as items whiz by on a conveyor, kicking out those that are unfit.

Proxy

The proxy is hardly a firewall at all. It is simply a machine that intercepts all data between two computers and decides whether or not to allow the connection. Where stateful and stateless firewalls act on a packet-by-packet basis, proxies act on a connection-by-connection basis, simply refusing to relay connections as appropriate.

Since proxies are basically a server piping into a client, they clog fairly easily (although are easy to set up and maintain). Further, UDP is often not supported well (or at all) by proxies.

To better understand proxies, one can imagine a conveyor belt bringing widgets to a man who inspects them and places them on a separate conveyor to be carried away.

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

Courtesy of drumstik alt.hacking Usenet.

And my own 2 p's worth.

Install Tripwire:

http://www.tripwire.org/

Nmap yourself a LOT

http://www.insecure.org/nmap/

Grab Nessus/SATAN anything else you can.

http://www.nessus.org

Have a look at the more 'secure' kernel projects:

http://www.openwall.com/linux/

http://www.lids.org/

A tutorial here on how to harden your kernel yourself:

http://online.securityfocus.com/infocus/1539

Have a scan with anything else you can aswell.

Check for all the exploits on your services, if they are exploitable publically then go forward/back one version to make sure whatever you HAVE to run is as safe as it can be.

There is also a 2-part guide on securing linux at Linuxworld:

Part 1 - HERE

Part 2 - HERE

A good resource for finding more info here:

http://www.wittsend.com/mhw/1999/securing_linux/

And of course if you have any more questions please ask Smile
Back to top
View user's profile Send private message Visit poster's website
ciel
Just Arrived
Just Arrived


Joined: 30 Apr 2002
Posts: 6
Location: LYON ( FRANCE )

Offline

PostPosted: Mon Aug 19, 2002 11:27 pm    Post subject: Reply with quote

Hello,

I just want to add this little link :

http://www.linuxsecurity.com/docs/LDP/Security-Quickstart-HOWTO/

ciel


Last edited by ciel on Fri Sep 16, 2005 1:01 am; edited 1 time in total
Back to top
View user's profile Send private message Send e-mail
AxeZ
Just Arrived
Just Arrived


Joined: 06 Mar 2003
Posts: 0
Location: Novi Sad, Vojvodina

Offline

PostPosted: Thu Mar 06, 2003 11:43 am    Post subject: Reply with quote

Here is very very nice Slackware hardening article by dentonj
(Jeffrey Denton)

http://www.c2i2.com/~dentonj/system-hardening
Back to top
View user's profile Send private message
Achillean
Forum Fanatic
Forum Fanatic


Joined: 14 Sep 2003
Posts: 16777215


Offline

PostPosted: Sun Sep 14, 2003 1:21 am    Post subject: Reply with quote

Just like to mention the very first thing you should do to secure linux is shutdown the services you don't know, in mdk I believe you can use mcc to disable what you don't want. Personally I use slackware. You might want to read up on iptables and build a decent firewall as well.
Back to top
View user's profile Send private message Send e-mail
CoyoteX
Just Arrived
Just Arrived


Joined: 26 Sep 2003
Posts: 0


Offline

PostPosted: Fri Sep 26, 2003 11:03 am    Post subject: Reply with quote

Quote:
I periodically check through /var/log/messages
which others should I be paying special attention to ?


wont work. ever heard of logcleaners? check packetstorm for them. if your system is compromised, you wont even notice if the cracker is good.
lets look at vanish (a log cleaner) pretty fast:
"Vanish is a log wiper that cleans WTMP, UTMP, lastlog, messages, secure, xferlog, maillog, warn, mail, httpd.access_log, and httpd.error_log."

pretty much every logfile there is. here an advice:
- get a router
- use a *BSD, openbsd i guess is pretty secure
- check freshmeat for new security software, can help you alot

thats it.
Back to top
View user's profile Send private message Visit poster's website
Giro
New Member
New Member


Joined: 25 Mar 2004
Posts: 22
Location: England

Offline

PostPosted: Tue Dec 09, 2003 5:37 pm    Post subject: Reply with quote

CoyoteX wrote:
Quote:
I periodically check through /var/log/messages
which others should I be paying special attention to ?


wont work. ever heard of logcleaners? check packetstorm for them. if your system is compromised, you wont even notice if the cracker is good.
lets look at vanish (a log cleaner) pretty fast:
"Vanish is a log wiper that cleans WTMP, UTMP, lastlog, messages, secure, xferlog, maillog, warn, mail, httpd.access_log, and httpd.error_log."

pretty much every logfile there is. here an advice:
- get a router
- use a *BSD, openbsd i guess is pretty secure
- check freshmeat for new security software, can help you alot

thats it.


Would you not notice ur log files missing a day?
Back to top
View user's profile Send private message
slozovsk
Just Arrived
Just Arrived


Joined: 27 Mar 2004
Posts: 0


Offline

PostPosted: Sat Mar 27, 2004 3:18 am    Post subject: Re: [Tutorial] Securing a linux machine - Detailed How To Reply with quote

A good security tool is VXE - http://vxe.quercitron.com

Sometimes it is much more convinient than chroot.
Back to top
View user's profile Send private message
Whitetoque
Just Arrived
Just Arrived


Joined: 23 Apr 2004
Posts: 0
Location: Canada's National Capital Region

Offline

PostPosted: Sun May 02, 2004 12:26 am    Post subject: Re: [Tutorial] Securing a linux machine - Detailed How To Reply with quote

paranoid wrote:
Can someone suggest what I should be looking for to secure my mandrake machine to a reasonable standard:
<snip!>
Im more concerned with where I should be looking for possibly security breaches and general administration.
<snip!>
Also where do I put IP restrictions on incoming SSH. I know this can be done through a firewall but im sure it can be done via configuration files or similar to /etc/hosts.allow


Securing a Linux box can be fairly complicated; in lieu of a course or tutorial in this regard I would highly recommend the book "HackNotes Linux and Unix Security Portable Reference". This book touches on a lot of security concerns and how to address them.

Now IRT your query about how to place IP restrictions on incoming SSH - off the top of my head (and I'm sure someone will correct me if I'm wrong), I believe you should be able to do this by removing the "sshd: ALL" entry from the /etc/hosts.allow file if it is there and adding the appropriate information, e.g. "sshd: x.x.x.x", where x.x.x.x is the IP address of the host you wish to allow.

Cheers,

Ted

Ted Mac Daibhidh, CD
Network Intrusion Detection Specialist

E-mail: ubergeek(at)whitetoque(dot)ca
URI: www.whitetoque.ca/ubergeek
Public PGP key is available at www.whitetoque.ca/ubergeek/pgp.htm

Back to top
View user's profile Send private message
ViMan
Just Arrived
Just Arrived


Joined: 30 May 2004
Posts: 0


Offline

PostPosted: Mon Jun 07, 2004 2:51 pm    Post subject: Reply with quote

The following is an excellent and short tutorial on using iptables. Read it. http://www.justlinux.com/nhf/Security/IPtables_Basics.html I found it very useful.
Back to top
View user's profile Send private message
ViMan
Just Arrived
Just Arrived


Joined: 30 May 2004
Posts: 0


Offline

PostPosted: Mon Jun 14, 2004 9:31 pm    Post subject: Reply with quote

If you're really security-conscious, then you might want to have a look at LIDS, the Linux Intrusion Detection System. I came across it today. Here's some basic information about it:
Code:

"The Linux Intrusion Detection System (LIDS) is a patch which enhances the kernel's security by implementing a reference monitor and Mandatory Access Control (MAC). When it is in effect, chosen file access, all system/network administration operations, any capability use, raw device, memory, and I/O access can be made impossible even for root. You can define which programs can access specific files. It uses and extends the system capabilities bounding set to control the whole system and adds some network and filesystem security features to the kernel to enhance the security. You can finely tune the security protections online, hide sensitive processes, receive security alerts through the network, and more."

You can download it and get more information from their website at http://www.lids.org
Back to top
View user's profile Send private message
minixad
Just Arrived
Just Arrived


Joined: 08 Jul 2004
Posts: 0


Offline

PostPosted: Thu Jul 08, 2004 8:08 am    Post subject: Re: [Tutorial] Securing a linux machine - Detailed How To Reply with quote

paranoid wrote:

I believe you should be able to do this by removing the "sshd: ALL" entry from the /etc/hosts.allow file if it is there and adding the appropriate information, e.g. "sshd: x.x.x.x", where x.x.x.x is the IP address of the host you wish to allow.





I usually check my servers a couple of times per day, and my carrier changes (I am using the SSH client from http://mobish.com on my mobile) the IP adress from time to time. I mean not just a /24 mask but like a 16-mask... Can I put that C-mask in hosts.allow? What happens if I go abroad? Will I get an entirely new IP?? Or do I get routed (NAT/ed) so I get the same IP-range?

I suppose this question is valid for a firewall approach as well.
Back to top
View user's profile Send private message
0x54
Just Arrived
Just Arrived


Joined: 01 Aug 2004
Posts: 0


Offline

PostPosted: Sun Sep 26, 2004 12:45 pm    Post subject: Reply with quote

hmmmmm,

no ones mentioned systrace Smile

id have to say its one of my favourate things about openbsd

manpage:

HERE

website:

http://www.systrace.org/

the shell..... o:

http://www.monkey.org/~jose/software/stsh/



i like it.

alot.
Back to top
View user's profile Send private message
AK_Dude
Just Arrived
Just Arrived


Joined: 25 Jan 2005
Posts: 0
Location: Somewhere in the cold, frozen north (Anchorage, AK)

Offline

PostPosted: Tue Jan 25, 2005 3:59 pm    Post subject: Reply with quote

Giro wrote:
Would you not notice ur log files missing a day?


I'm not familiar with vanish or other log cleaners, but consider this: suppose the cracker didn't erase an entire day's worth of logs, but only the entries relevant to his intrusion. You might not miss a few deleted lines from your logs. One potential way around this is to have your syslogger write to a log file and *also* e-mail directly to a logging server (on another subnet with only console access). It's bandwidth intensive, but if you are really paranoid...

Still, by all means *DO* check your log files daily. Unless your system is really insecure or the cracker is either exceptionally good or exceptionally lucky,there will probably be a period of hack attempt, failure, repeat... before he/she gets in. These failed attempts should show in your log files (you are running iptables, right?) That gives you a chance to detect what's happening and take action to counter the attacks.

Case in point: I recently detected a number of brute-force ssh attempts against one of my Slack boxes. Because I found the evidence in the logs, I was able to set iptables to deny all incoming ssh from other than a handful of IP addresses that I know I use regularly. Without scanning the logs, I never would have found the attempts...until I was hosting an 0wn3d server Smile

You should check almost all (if not all) of your log files regularly, but especially these: messages, syslog, apache's error_log, apache's access_log, sulog. Depending upon what services you are running and how your logging is configured, there might be other files that are just as important, too.

One other note: make sure you are using some kind of integrity checking software! At work we use Tripwire, and it is a really good, full featured program--I highly recommend it. You can download the open source linux version at http://www.tripwire.org/downloads/index.php
Back to top
View user's profile Send private message Visit poster's website
Display posts from previous:   

Post new topic   Reply to topic   Printer-friendly version    Networking/Security Forums Index -> UNIX // GNU/Linux All times are GMT + 2 Hours
Page 1 of 1


 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

Looking for more Windows Networking info?

Sign up to the WindowsNetworking.com Monthly Newsletter, written by Enterprise Security MVP Deb Shinder, containing news, the hottest tips, Networking links of the month and much more. Subscribe today and don't miss a thing!
View a sample newsletter.

Become a WindowsNetworking.com member!

Discuss your Windows Networking issues with thousands of other Windows Newtorking experts. Click here to join!

Community Area

Log in | Register

Readers' Choice

Which is your preferred data recovery solution?

Follow TechGenix on Twitter