Common *nix Security Practice's

Greetz AO'er's. This tutorial is going to be an overview and some information on common and even uncommon Linux/Unix security practice's. Throughout this guide, you'll learn how to "harden" your box by performing a few common security practice's. Let's not waste time and jump into some common Unix security practice's.

Unix Security Practice's: What You Should Do

-- If you have root access to your system, it's best if you rarely (if ever) use that account. The more you do, the more and longer you leave yourself susceptible to an attack which would compromise the account. Instead, create an account similiar to root with root-level privledges and rename it.

-- If you wanna feel safer, block login's to root. As stated, rename it something different to confuse hacker's and so they won't know which to go for if they wanna "root" your box.

-- Limit or Eliminate su access to root.

-- Password security is a must, make sure your password's are very difficult to crack and should be mixed character's. Don't forget to make it something you can remember, like perhaps your nephew's birthday or something (for example, Jack61690 would be a good password) would be great. Even scrambling mixed character's make's it a great password, just tough to remember (i.e jg859jo59fk). It might even be noted that you should change your password often.

-- Honeypot's/Firewall's are a must for any system in today's world. Constant port probe's and random vulnerability scanning can lead to your system being a target. Be sure to install a honeypot or a firewall shortly after install. Moniter the logs and test your setting's. Configuration is key when installing a firewall, so read the installation instruction's carefully.

-- As with any system, backup your file's every so often in the event of an intrusion. Always, ALWAYS have backup's.

-- A/V software is key to any Unix system administrator or even a home Linux user. It is vital to download one after installation. Always keep up with the update's and download them as soon as release. Be wary of what you download off the internet. There will always be new worm's and new virii all the time so keeping this updated is critical.

-- As with any other system, ALWAYS be on the lookout for the latest updates and patches for your Unix/Linux machine. One of the worst thing's to have to worry about is to have a hacker hack your OS because of a non-patched bug. Always download the latest patches and keep up with the newest modification's in your OS.

-- IDS system's and other tool's of the like work wonder's. Use them to your advantage and if your capabilities extend that far.

-- Common logic about email attachment's: Use Common Sense. If you don't know the person and they want you to open a file on your computer, chances are it's something malicious and harmful.

-- When it comes to securing your system and Computer Security in general, paranoia is a good thing.

-- Be careful of user access and file permission's on your system. Create user level's with permission's that you feel are needed, don't make any that is not needed.

-- Turn off/shutdown any service's or server's you don't need or use. All it does is open more holes into your system for a hacker to exploit. Close any port's that you don't need open.

-- Perform weekly or daily virus scan's for infected software. Even if you have auto-detect on, it's still a good choice to scan anyways.

-- Use chmod to your liking and how you want file permission's to be set.

-- If on a network (or even home, as it could happen) be sure to not let any user rm -rf as you don't want your files and everything deleted because of something as silly and stupid as that.


Well, those are my tip's and practice's on securing your *nix box. Hopefully you found this tutorial helpful and you'll apply these tip's to your system, as it's designed to secure it. Remember, your box is only as secure as you make it to be :D

Quote:

---

-- Download Spyware Protection. Spyware/Malware/Adware has quickly and quietly become a problem in the security world and has grown more and more annoying as time progresses. Save yourself alot of hassles by simply downloading spyware protection.

---

I didn't know marketers targeted *nixer's....

Is there a *nix spyware scanner?

Ahh good point, I was thinking of security in general at the time. :p

its a good outline of what needs to be done, often little things like renaming "root" can be overlooked :)

I know i have seen heaps of people who use the "root" account as their general account .......

little practices like you have outlined are awesome to get into .. welldone

Thanks :) Yeah, well I created a smaller account for me to do my general stuff on while on the FreeBSD box. One of the main rule's of security (IMO) is to rarely use the superuser account (whichever it may be, whether *nix, Window's, etc) at all and to create another account to use as the general one.

Ok, my recommendations:

1. DO NOT under any circumstances, install any honeypot software anywhere near a production machine. Honeypots are for fun and catching attackers; they need to be installed with great care and in a very sterile carefully prepared environment. And nowhere near a production machine. Remember that not all honeypot software is free from vulnerabilities itself.

2. Don't rename root. It is pointless and may break stuff. For starters, renaming root instantly breaks most of "inetd" services. DO disallow non-local root logins via sshd, FTP etc.

I think that limiting your usage of the root account is mainly for safety rather than security. If someone compromises your user account, they only need to trojan "su" (which can be done with shell script), and they have root too.

IDS are nontrivial to maintain, and use up a lot of system resource (as well as the administrator's time). If you don't have time to spare to take care of your IDS properly, don't install one as it will be counter productive. If after two weeks you have 10Gb of logs, you aren't going to bother sifting through them to find the 10 lines caused by attackers in the 100million caused by worms.

Obviously if you start having IDS on a production system, it can also use up CPU time and fill your disc with logs.

IMHO, the jury is out of Unix AV software - if your preferred vendor has a sufficiently mature package - by all means go for it.

Unix AV software is still in its infancy, and while most vendors provide an on-demand version of their AV for Unix, few do on-access (due to the difficult of interfacing with the range of Unix kernels). Also bear in mind the performance hit caused by on-access virus scanning, this is pretty severe on some Windows versions.

Not all servers need AV software either. If they aren't handling windows files on a regular basis, there is no real possibility of getting viruses, therefore it's unnecessary. For example, with a database server you could find that the overhead of an on-access virus scanner decreases performance a lot - and even if the database contains win32-based files - would the AV even find them buried inside the DB?

Slarty

Good work, but I have a few beefs with some of these:

Quote:

---

-- If you have root access to your system, it's best if you rarely (if ever) use that account. The more you do, the more and longer you leave yourself susceptible to an attack which would compromise the account. Instead, create an account similiar to root with root-level privledges and rename it.

---

Rename it? No, that would defeat the entire point of the saftey of root anyways. Why? Because not only would you have one account with full system access, but two. And as stated already, renaming root kills a lot of services because of how deeply the root account is embedded into the UNIX tradition. Only one super user, period. For users that you want to allow root access via su root, place them in the wheel group. Adding a second super user only means a second chance to be broken into.

Quote:

---

-- If you wanna feel safer, block login's to root. As stated, rename it something different to confuse hacker's and so they won't know which to go for if they wanna "root" your box.

---

Remote login to root is fine to block. Block local, and you may end up having a ton of problems because su root, in some cases, simply won't cut it. Especially if that user's home directory is corrupted. And as I stated above, renaming the root account will have SEVERE system consequences.

Quote:

---

-- Limit or Eliminate su access to root.

---

While a good idea, that's something that could effectivly ruin your system. Let's say you want to check logs? Modify services? Lock down the firewall.sh? Modify the rc.local file? root needs to do that, and that means your normal user has to use su root, meaning they need su to modify the system so they won't login as root. See why it's bad to give another user root in my statement above.

Quote:

---

-- Password security is a must, make sure your password's are very difficult to crack and should be mixed character's. Don't forget to make it something you can remember, like perhaps your nephew's birthday or something (for example, Jack61690 would be a good password) would be great. Even scrambling mixed character's make's it a great password, just tough to remember (i.e jg859jo59fk). It might even be noted that you should change your password often.p

---

NIX password handling goes beyond that, including special chars and encouraging to include lower and upper case. Here is a very good password example: 0MfG_4Ev@_

1. It's longer than 8 letters, beating a lot of commonly used brute force password crackers.
2. By including special chars (@ and _) that opens up an entire new range of characters that require brute force, and a ton of extra time.
3. The combination of upper and lower doubles the possibility checks.
4. Even if they got the entire part up to the _, if the password cracker stopped there they would still not be able to get in because they would not have expected a special char after the commonly used internet phrase "4eva"

Quote:

---

-- Honeypot's/Firewall's are a must for any system in today's world. Constant port probe's and random vulnerability scanning can lead to your system being a target. Be sure to install a honeypot or a firewall shortly after install. Moniter the logs and test your setting's. Configuration is key when installing a firewall, so read the installation instruction's carefully.

---

This was discussed above, but running one is haphazord as it is basically inviting people to give your server a shot. This is not meant for security issues, but usually placed on the outside of the network to entice crackers to get that instead of the real network, thus trapping the cracker. And... the key to UNIX security is to not run things that are not absolutley requires. Having a honeypot service running opens you up to the DoS of that honeypot as well.

Quote:

---

-- A/V software is key to any Unix system administrator or even a home Linux user. It is vital to download one after installation. Always keep up with the update's and download them as soon as release. Be wary of what you download off the internet. There will always be new worm's and new virii all the time so keeping this updated is critical.

---

AV software? Just don't run things in root, and only su root when the event requires it and you fully understand the event.

Quote:

---

-- IDS system's and other tool's of the like work wonder's. Use them to your advantage and if your capabilities extend that far.

---

An IDS can be quite a load on hardware and software alike. For a simpler solution, monitoring of each and every packet is not needed. Why? Just monitor the logs that the services you are running create. If you see suspicous logs in apache, ssh, and smtp, then you know something is going on. However, trying to sift through 20 gigs of log files when you really are only going to have 5k of suspicous files and 19 gigs of work and ACK requests.... ouch

Quote:

---

-- Common logic about email attachment's: Use Common Sense. If you don't know the person and they want you to open a file on your computer, chances are it's something malicious and harmful.

---

This is really only windows specific, since NIX doesn't use exe's, and the user (shouldn't) be running in root to allow any possible virus to spread beyond /home.

Quote:

---

-- Perform weekly or daily virus scan's for infected software. Even if you have auto-detect on, it's still a good choice to scan anyways.

---

Once agian, moreso windows specific, but I get what you mean.

Quote:

---

-- If on a network (or even home, as it could happen) be sure to not let any user rm -rf as you don't want your files and everything deleted because of something as silly and stupid as that.

---

No, never ever do this. If a user wants to rm -rf gaim-0.7 in their home directory they need to be able to do that. Removing the rm -rf function is something that doesn't need to be worried about. If chmod settings and permissions are done correctly, they can't rm it anyways. But.. wow.. to deny that simple function that not only helps a user clean out his home directory.. but is REQUIRED to delete folders... please don't do this to your users. Just ensure proper permissions are set

Honestly, this "tutorial", should be removed from the site. I'm not trying to be mean or nasty but it is about 90% rubbish. There are plenty of sharp people here who wont be misled by the information, however, there are many more that could easily bust up a production web server (or any number of other services) by doing the things suggested by the poster. Security does not equal inoperability, which is exactly what will happen to *any* unix system you do these things to.

--TH13

I'm going to have to agree with horse on this. We aren't trying to be mean or hurtful, but the information provided here is inaccurate for nix systems, to a dangerous degree. This does need to be removed or at least allow the author time to make major modifications so that we can still honor his attempt.

In fact, this makes a MUCH better Windows security tutorial, as almost every point is much better focused towards a windows point of view.

The danger we see (so parent poster knows we aren't just trying to be jerks) is that, if someone who is unlearned in the art of *nix does take this as insight into server security then they risk opening their system up in ways that severly make their entire network insecure. Tutorial writing comes, I feel, with a responcibility that the information you provide may be used somewhere in reality and applied to every letter you wrote down. This means the fame as well as the tears.

Keep that in mind :)

Moved from Security Tutorials to *Nix Security Discussions. Spyder32, perhaps look at the comments and give another try again. :)

Quote:

---

quote:
-- Limit or Eliminate su access to root.

While a good idea, that's something that could effectivly ruin your system. Let's say you want to check logs? Modify services? Lock down the firewall.sh? Modify the rc.local file? root needs to do that, and that means your normal user has to use su root, meaning they need su to modify the system so they won't login as root. See why it's bad to give another user root in my statement above.

---

Actually you can eliminate access to su. On any descent *nix system you can always open a new virtual terminal (usually ALT-F2 or CTRL-ALT-F2 if you're running X) and login (locally) as root.

Eliminating su does mean you cannot change anything remotely (because you should deny root logon using ssh, rsh, telnet etc.).

Yep, thus my 90% rubbish statement rather than 100%.

;)

Quote:

---

Originally posted here by slarty
[B]Ok, my recommendations:

2. Don't rename root. It is pointless and may break stuff. For starters, renaming root instantly breaks most of "inetd" services. DO disallow non-local root logins via sshd, FTP etc.

---

Yep, pointless
PAGE 52. O'reillys Practical UNIX 1991(copy). $7.00

Code:

---

cat /etc/passwd

---

Root always has a (UID) number of

Code:

---

:0:

---

http://www.cert.org/tech_tips/unix_c...uidelines.html

:( Sorry again guy's. I guess certain people just aren't meant to write tutorial's. I'll never write one again, don't worry. Thanks thehorse13 for being so frank :D I love constructive critisism but geez ;). Oh well, I guess writing tutorial's just isn't for me..

Spyder32, I wouldn't give up on writing tutorials. But what I would suggest is find someone to review it before posting it. In essence, get a 2nd opinion until you get the hang of things and to have a 2nd set of eyes to review for grammer, spelling and technical issues. For some it's simple but for others it requires some work. I've had to write tutorials for a while before going online and when you learn what works and what doesn't you understand better what needs to go in.

Don't give up, just approach it differently. :D

Heh, thanks MsM :) Now all I gotta do is find that person ;)

I would be happy to look over a tutorial before you post it.

:)

Quote:

---

Originally posted here by Spyder32
:( Sorry again guy's. I guess certain people just aren't meant to write tutorial's. I'll never write one again, don't worry. Thanks thehorse13 for being so frank :D I love constructive critisism but geez ;). Oh well, I guess writing tutorial's just isn't for me..

---

*Bitch slaps you*

What the hell man? You got two people spanking your balls and you give up? Come on man, I did a tutorial on OSs once, and even after checking the information, had mistakes pointed out to me.

It got closed and a big mess was made, all because I chose to listen to a book I had about the subject, which I now know is jammed with misinformation, and won't be used again to check information when I'm writing something.

Now, YOU, get up, whipe yourself off, and try again, and don't ever let me see that I give up **** again or you'll be answering to me.

When I write something for this place, I have about 5 people I have look over it, including, but not limited to:

HT Regz, Horsey13, Juridian once in a while, Prodikal, and a couple other people. I started working on a new text not long ago on OSs, and I made a sneak peak in Addicts, but then I had work, finals at school, and then sick for a week, so I havn't worked on it at all....And I'm low on Vicodin so my concentration is ****.

Thanks thehorse13, I'll PM ya when I write a tut or whatever and you can help me out with looking over it.

Quote:

---

Originally posted here by gore
*Bitch slaps you*

What the hell man? You got two people spanking your balls and you give up? Come on man, I did a tutorial on OSs once, and even after checking the information, had mistakes pointed out to me.

It got closed and a big mess was made, all because I chose to listen to a book I had about the subject, which I now know is jammed with misinformation, and won't be used again to check information when I'm writing something.

Now, YOU, get up, whipe yourself off, and try again, and don't ever let me see that I give up **** again or you'll be answering to me.

When I write something for this place, I have about 5 people I have look over it, including, but not limited to:

HT Regz, Horsey13, Juridian once in a while, Prodikal, and a couple other people. I started working on a new text not long ago on OSs, and I made a sneak peak in Addicts, but then I had work, finals at school, and then sick for a week, so I havn't worked on it at all....And I'm low on Vicodin so my concentration is ****.

---

It's not that really, but this is my second f'ed up tutorial and I dunno.. I'ma still write tutorial's, just from now on I'm going to PM thehorse13 and maybe some other people so they can give me their opinion on it.

Quote:

---

Now, YOU, get up, whipe yourself off, and try again, and don't ever let me see that I give up **** again or you'll be answering to me.

---

Thanks man, I needed that :D I'm going to be working on another tutorial (gotta find a subject first) for now. But thanks for the help and encouragement gore :)

Quote:

---

I would be happy to look over a tutorial before you post it.

---

LOL. Nuff said. (TH13 knows what I'm referring to). Sorry, just had to put that one in :D.

Cheers,
cgkanchi

LOL,

Yes, I know exactly what you are referring to. I promise one day.... ;)

NOOO, don't give up ;) Where you able to walk when you where born? No. Did you fall on your face trying to stand up? Probably alot. Did you eventually get the hang of it? I sure hope so. Making mistakes is all part of the learning process. Nobody get's it right the first time (and some people the second, third, fourth etc.). It's all about making progress and learning from the mistakes you make. Just look at my sig and think about it.

tzu

Quote:

---

NIX password handling goes beyond that, including special chars and encouraging to include lower and upper case. Here is a very good password example: 0MfG_4Ev@_

---

ok i agree with you tzu

but when you are jumping around using different keyboard sets and mappings these weird characters can create a lot of problems
i don't know how many times i have to try to figure out were a certain special characters is located on a system where the mapping is wired.
(try VAX machines they can drive you nuts, with that damm gold key to get a special character, hours of fun)

Quote:

---

but when you are jumping around using different keyboard sets and mappings these weird characters can create a lot of problems
i don't know how many times i have to try to figure out were a certain special characters is located on a system where the mapping is wired.

---

shift+1= !
shift+2= @
shift+3= #

I'm not talking about oddly special chars like: ǽ and Ữ Just normal shift+# special chars. And that should be universal on keyboard mappings.

sorry tzu but they are not universal shift + 2 is " on my Swedish key board i utilize a french site(don't know if its just that site though) and there " its shift + 3 and so on it can get interesting some times.

but like its just a small point if one is jumping around swapping systems back and forth like i get tricked into doing

pooh sun tzu
That only works on a qwerty(english) keyboard. better advice is to learn your asci table and use alt with the asci code. For example :
ALT 64 gives @
ALT 33 gives !
ALT 35 gives #
Of course i dont know if this works on a unix machine.

edit :
di0strb lol you got in before me
end edit

Ah :) Thanks for clearing that up guys! I was unaware that something so minor could be so different. I -still- recommend using special chars on security passwords. A bit of keyboard frustration until the movements are memorized versus a broken network.

I realize that this is almost a month old, apologies in advance for that.....

I can't help but notice that a lot of the 'UNIX Security' stuff assumes one or a couple of boxes with a small handfull (if not just one) user. Keep in mind that in an installation of any significance and depending on what the environment is setup like, much of what is frequently mentioned here on A.O. is not the least bit scalable, if it will work at all.

Medium to large installation reality check:

- There are going to be several users who have the root password. It is not uncommon for something on the order of 30 - 50 people (or more) to know the root password at large installations.

- Much of the time you are going to be building/patching a system and then handing it over to a customer (e.g. engineering dept.). From that point you become a fireman, chasing after and fixing the messes they make.

- Restricting access to 'safe' activity is only going to work until the 50th time they call you at home at 03:00 on a Sunday to fix something or run some command for them.

- Honeypots and the like belong on DMZ's and serve absolutely no purpose on a machine that anyone would ever actually use.

- Viruses aren't a real threat in the UNIX world, but Worms and Trojans are among the worst possible scenarios next to mass internal network comprimise.

- You can't always run the latest and greatest, or even the lastest patch level for that matter. Software vendors often have specific requirements and if you aren't at the OS version and patch level they require you won't get support.

- Real UNIX environments run things like NIS+ and LDAP which aren't exactly a security freaks idea of a secure environment. Of course, only fools run either of these on a machine that is accessible from the outside.

Real world tips:

- Only allow root access via console. Have some kind of serial console (e.g. lantronix) set up on all of your machines, and only allow root to log in there. Disallow direct login everywhere else (e.g. telnet, ssh)

- NEVER put . or :: in root's path! Doing so is begging to run somebody's trojaned command. For that matter, use a minimum PATH for root . Something along the lines of /sbin:/usr/bin:/usr/sbin:/usr/lib/nis:/etc (Solaris) or /sbin:/usr/bin:/usr/sbin:/etc:/usr/etc (AIX and IRIX), etc. Personally, I prefer to unset PATH in roots .profile

- Get in the habbit of using the full path to the command, e.g. /bin/su - instead of just su. The theme is to always know exactly which command you are running.

- root passwords should change every 30 days, should be a generous mix of non-alphanumeric (e.g. # @ _ ? ^) characters, and should follow an agreed upon convention to make them easier to remember

- The root password on servers and workstations should be different.

- Important log files from all hosts should be sent to a loghost if possible and written to some type of 'write once' media.

- Properly secure and audit each machine before putting it into production. This will greatly reduce the work involved in security monitoring once users get a hold of it.

Just my thoughts...

-- spurious