Linux System Security.

[Alk3 0]

I know how to keep my Linux system secure, for the most part. I just want to find out from all of you what other methods are available for countering malicious activity. You know, hardening, logging, NIDS, file integrity checking, anti-virus, firewalls. Also what tools make these methods less time consuming and easier? I'm just curious, since I am planning on going live with a home test server pretty soon- and I want to make sure it is reasonably secure.

Since some of us know how to get in, I'm sure some of us know how to stop others from getting in.

Alk3

[Dirk Chestnut 3]

I'm surprised no one posted on this yet... on security-related forums too! Tisk. I'll be the first to risk the, "No jackass, that won't stop anything!" flames and offer some tips on what I do.

I'm just assuming, from your short description, you've basically got a box accessible from the net, and that it's not too complex-

SSH: If it's public (IE- accessible to the Interweb), disable root logins, and look into running DenyHosts or something similar to parse the /var/log/secure (auth on Debian? I forget) for failed SSH logins and add offending hosts to /etc/hosts.deny. There's an iptables rule to do the same thing, although I forget what it is, and I think it counts on connections within a timeframe, not actual password/username failures. You undoubtably will see Brute Force attempts if it's public, though generally as a large list of common accounts (test, apache, root, bin, etc), each hitting for only one or two passwords.

Telnet: Don't do it, it's horribly insecure, and SSH does the same thing and install just as easy on modern distros.

FTP: For the love of Pete, chroot it, especially if you've set it up for anon access. You really shouldn't use regular user accounts to upload/download files from it. If you do want to use actual user accounts, just go ahead and use SFTP which is built into SSH.

Firewall: Meh, why not, even if you only have a few ports open. Just some simple rules in IP tables to block all ports in but the ones you need public, and allow everything out, usually does the trick. Alternatively, you could use the /etc/hosts.allow and /etc/hosts.deny files for incoming, as I think most daemons respect their settings.

Updating: Like anything, you need to patch things (Kernel, service, or otherwise) when there's a major security flaw found. I've run distros such as Debian and Fedora Core at full patch level all the time, and I don't have any problems with an updated binary breaking something... upgrading from version A to version B is a much different story, however...

HTTP: I trust Apache, again, if you keep up on its critical updates. What I would worry about are canned web applications (Drupal, phpBB, etc) you serve out. Don't forget, these sorts of things can be exploited too. I don't do web service monitoring enough to know what (if anything) is out there to monitor apache logs from a security standpoint.

SMB: Shouldn't be public, period. Same goes with NFS.

SMTP: No matter what you use (Postfix or Sendmail typically) set it to only relay for domains/networks you specify. Under no circumstances should it be allowed to accept connections from anyone that wants to connect to it. If you don't plan on using the box to send/recieve mail for your own little domain, firewall it off. I don't think most domains will recieve mail from a host they can't verify the DNS entries recursively for, so keep that in mind if you do want to send/recieve mail.

Username/Passwords: I won't repeat the lecture, you know it by now- root/root is a terrible combination.

For a single (and simple) box that's not firewalled from incomming traffic on the net, that should do. NIDS shouldn't really be necessary, but you could give it a shot- learning to config it and watch its logs could prove educational. You might also want to look into Bastille linux, which to my knoweldge is a set of scripts to harden Linux installs, but this again may not be absolutely necessary.

[Alk3 0]

Yeah, I have the FTP, HTTP, MySQL servers setup. I am only planning on allowing LAN access to the FTP server. It is chrooted and it only allows connections from specific IP addresses.

I use Firestarter firewall to manage my connections, since essentially it is a GUI front-end to iptables. I use Firestarter because it lets me share internet connections, and allows for point and click firewall rules. What I really want to learn is how to use iptables by itself, eliminating that extra space taken up by the GUI. Does anyone have any really good tutorials for iptables? All the tutorials I have found are /very/ technical and hard to understand, for me at least.

I do use Bastille. It is an essential tool for securing the finer points of a live box. I disabled root login and FTP (and all other plain text protocols). Is there another tool out there that is better than Bastille?

Rootkit detection? How does this work? I usually only run desktop installs of Linux and the whole security issue isn't as prominent for my purposes. I understand what it is but what is the benefit? Are viruses an issue with Linux?

What Dirk Chestnut said about web service monitoring is really what I am trying to learn and apply ASAP. I have a laptop that is available for use as a logging server, necessary? I would like to find an application that allows for server log management and monitoring, any ideas?

The host OS I am running is Debian GNU/Linux 4.0. I am sufficient in administering and keeping it patched. (even thought it hasnt been live yet) With MySQL, I know there are database administrative interfaces available. Which is best?

Anyway, input for this topic will be /very/ helpful.

Alk3

[Dirk Chestnut 3]

For iptables http://electron.mit.edu/~gsteele/firewall/ . This is one least confusing iptables tutorials I've come across. You should be able to alter that script to your needs. Also http://www.aboutdebian.com/firewall.htm has a horribly long iptables script, which you might want to read through to help in your understanding of it. There is no shortcut to learning IPtables the manual way.

For MySQL administration I know webmin has a plugin for it, and there's phpmyadmin, I don't use either enough to tell you what works best, but that should be a nudge in the right direction.

In general, http://www.aboutdebian.com has some other walkthroughs that may be of interest to you. Debian is well documented, especially from the command-line, for most anything.

Edited January 11, 2007 by Dirk Chestnut

[l0gicb0mb 0]

Another thing you should do is write some scripts(doesnt matter in what) to parse your logs from everything to incorrect logins to failed ssh attemps and so on. You can then set them up as cron jobs so you dont have to go through massive ammounts of data to see what is happening on your machine. O'Reilly has some good bocks on this topic(as they have good books on almost anything you can think of) There some good online guides for this too, yet I cant remember them at this time... If they come to me I'll post them up for you.

While on the subject of parsing logs I should also suggest using a intrusion detection system such as Snort. I have even seem some people(not sure how well it worked for them) set up TCPSpy and configure it just to log 'suppicious' activity.

Hope that helps a tad.

[mstanley 0]

I'm surprised no one posted on this yet...

I didn't want to go first because whoever did would have to write a really long post.

The thing to remember about preventing unauthorized access to your server is that you can't. You can limit your exposure by reducing the number of services and closing uneeded ports. But beyond that you just need to know when your system has been accessed and hopefully as soon as possible.

There will always be some time between a successful compromise and a fully rooted system. That is the time that I have the system start sending me continuous emails which contain bash_history and the system logs. You are root so bash_history shouldn't be changing unless you are logged in.

[Alk3 0]

Another thing you should do is write some scripts(doesnt matter in what) to parse your logs from everything to incorrect logins to failed ssh attemps and so on. You can then set them up as cron jobs so you dont have to go through massive ammounts of data to see what is happening on your machine. O'Reilly has some good bocks on this topic(as they have good books on almost anything you can think of) There some good online guides for this too, yet I cant remember them at this time... If they come to me I'll post them up for you.

While on the subject of parsing logs I should also suggest using a intrusion detection system such as Snort. I have even seem some people(not sure how well it worked for them) set up TCPSpy and configure it just to log 'suppicious' activity.

Hope that helps a tad.

Yeah, those O'Reilly books are king. They have texts on just about anything you can think of.

There will always be some time between a successful compromise and a fully rooted system. That is the time that I have the system start sending me continuous emails which contain bash_history and the system logs. You are root so bash_history shouldn't be changing unless you are logged in.

How would I go about setting this up? I have the mail server set up. Would I just have the recipient be username@hostname.com?

Also, what are other things to be aware of to know if your system is rooted? Finding out if your system has been compromised can be hard to know to a less aware admin. I know some, but what tells you your system is compromised?

Anyone else have any ideas?

Alk3

[Alk3 0]

bump!!!

[perlfu 0]

For file integrity, I just use mtree. If used correctly it can be just as reliable as tripwire, without all the licensing hassle. Takes a bit more know how to get up and running as a file integrity checker, but it's not too bad. Spamassassing/clamav is my personal preference for mail. Packet Filter/ALTQ for the firewall, and everything else I tend to use is pretty much covered.

Oh, and Squid. In my experience Squid is definitely worthwhile, it can be rather time consuming to get up and running properly, but the benefits in speed/security far outweigh the time required to set it up. Squid is probably my best tool for protecting my users from their own stupidity, and protecting my anonymity. All while being probably the most effective ad blocker I've ever had.

[feverdream 1]

And configure any DB system like MySql to only allow network access from localhost.

[Alk3 0]

Thanks for the replies guys. Does anyone else have any other ideas? Anything really important that might not be as commonly found on the net through a search engine?

ALk3

[zeroxeal 0]

Make sure you **ALWAYS** reuse your passwords, especially passwords for forums/email/websites and your boxes, always set your root password to password .... it makes life so much easier for people who want to own ya.

[mecca_ 1]

I think you guys have covered most of it very well. I have one thing I'd like to add that may be a bit helpful.

If you go to http://www.cisecurity.org/ you can download a "scoring utility" for various OSes. This scoring utility will present you with a list of recomended changes to make to your system to enhance security.

Basically when you run the application you are given a log of what the scoring utility found, alongside a number. This number corresponds to a section of the included .pdf file. In each section of the .pdf you will find small shell scripts that will actually fix the problem. Some of the stuff the scanner checks is not really required, like warning banners, but all-in-all it's a nice little utility.

If you don't feel like running the scoring utility, the included .pdf is a very good information resource. I haven't looked at the newer releases yet, but the .pdf used to include actual information about why the scoring utility is asking you to change certain things. It's actually a good read

[Alk3 0]

I think you guys have covered most of it very well. I have one thing I'd like to add that may be a bit helpful.

If you go to http://www.cisecurity.org/ you can download a "scoring utility" for various OSes. This scoring utility will present you with a list of recomended changes to make to your system to enhance security.

Basically when you run the application you are given a log of what the scoring utility found, alongside a number. This number corresponds to a section of the included .pdf file. In each section of the .pdf you will find small shell scripts that will actually fix the problem. Some of the stuff the scanner checks is not really required, like warning banners, but all-in-all it's a nice little utility.

If you don't feel like running the scoring utility, the included .pdf is a very good information resource. I haven't looked at the newer releases yet, but the .pdf used to include actual information about why the scoring utility is asking you to change certain things. It's actually a good read

Great info! Is there anything like this available in source code? I'd like to compile my own package for later use. Or is there something like this for .deb base Linux distribuitions?

[mecca_ 1]

Great info! Is there anything like this available in source code? I'd like to compile my own package for later use. Or is there something like this for .deb base Linux distribuitions?

To be quite honest I haven't used this utility much since they switched over to their "Next Generation" version of the utility, but the previous one was just a fairly simple shell script. You could see everything that the script was checking for and them compare that to the small script suggestions given in the .pdf.

Alot of the things that this script checks for are version inspecific. The reason they offer different distributions is because of the differences in SUID\GUID files and such. At least, thats how it was before the new version. I think there may be some OS version checks in the shell script, but I have successfully run this on non-supported OSes simply by commenting out the section that makes the shell script die if it can't determine the version. The only thing you miss are the SUID checks and the other minor version specific things. It would be very simple to make, add to, and modify the shell script and deploy it across the Linux distro of your choice.

[riscphree 0]

Since running a dedicated server on the net, I've found some tools that come in handy.

APF, which is a policy based firewall using iptables. You can find it here: http://rfxnetworks.com/apf.php

BFD, which is brute force detection. You can set it to email you when people are trying to brute force your user accounts. http://rfxnetworks.com/bfd.php

R-Fx Networks has some really cool stuff, http://rfxnetworks.com/proj.php

Also, I would install http://www.chkrootkit.org/ for checking for rootkits.

If those two tools you don't like, check out CSF here http://configserver.com/cp/csf.html

I hear people say they like that one better, I'll probably be testing it out later this week.

[gloomer 1]

Great stuff here. Anyone have any tips on Snort? That's really the only thing I haven't tried yet.

And how is APF any different than Iptables? Once you get the hang of it, iptables is actually easy. Remember, it's easy if you know how.

The BFD is a knew thing. However, the most important thing is choosing complicated long passwords.

Some of my passwords are over 15 chars. Upper case lower case and numbers.

Why risk being compromised because you're lazy? Also, never use the same password more than twice for ANYTHING.

That CSF thing is pretty cool. Like Bastille.

[riscphree 0]

And how is APF any different than Iptables?

Its not, it uses iptables. I found APF easier to work with than writing the iptables stuff because I never knew how to do it.

Easier in the sense that if I want to ban an IP address from connecting, I just do: apf -d IPADDR

I don't know how to do using iptables off hand.

[Alk3 0]

Since running a dedicated server on the net, I've found some tools that come in handy.

APF, which is a policy based firewall using iptables. You can find it here: http://rfxnetworks.com/apf.php

BFD, which is brute force detection. You can set it to email you when people are trying to brute force your user accounts. http://rfxnetworks.com/bfd.php

R-Fx Networks has some really cool stuff, http://rfxnetworks.com/proj.php

Also, I would install http://www.chkrootkit.org/ for checking for rootkits.

If those two tools you don't like, check out CSF here http://configserver.com/cp/csf.html

I hear people say they like that one better, I'll probably be testing it out later this week.

How did it go?

[riscphree 0]

CSF is more intuitive, I still like APF more

[JimmyRidge 0]

just got finished dicking with some neato stuff myself mostly centered around my openwrt router (it is my gateway to the world afterall) heres some of the things i did

WPA wireless

my ssh/http server are hosted on a gentoo server with hardened kernel

iptables TARPIT module i tarpitted a few common windows ports lol netbios etc

snort ids alert mode (really want to setup some sort of temporary ipblocking for those that trip the alarm) *UPDATE* using snort inline! iptables queue's pkts snort inspects and accept/drops based on the rules only been running a short while but unbelievable the amount of attacks so far on my "nothing special servers"

<-- sixxs.net user!! i have a tunnel and a subnet workin on reverse delegation

i started increasing ssh password security and setup ssh keys so i dont have to type 20+ characters everytime i logon

so far i think its all locked down pretty good i can sleep tonight and continue fucking with it all and improving *UPDATE> also fired up fail2ban that checks the auth log for failed atempts and blocks the ip for a significant amount of time

hey its a work in progress and a home lab so... bite me

been thinking of messing with honeyd agian just wet my tongue with tinyhoneypot but that was too weak oh yea labrea tarpit for my ipv6 subnet hide my real machines

damn i still need to fart with dns bind

all in a days work

Edited May 12, 2008 by JimmyRidge

[Alk3 0]

You should recompile SSH with the versions spoofed on your router. It makes it harder for attackers to figure out what exploit to run against your gateway. So like this:

# ssh -v

OpenSSH_4.7p1 Debian-2, OpenSSL 0.9.8g 19 Oct 2007

I would spoof the stable release of Debian. I'm running Debian Lenny, not Etch, so it would in turn say OpenSSH_4.3p2. Its a good idea to do that for any service commonly known to drop to root if exploited. Sure there are thing that can be done to get passed this while attacking, but it should hopefully make your IDS easier to set up.

Edited March 13, 2008 by Alk3

[Alk3 0]

Also...

http://www.nagios.org/

https://www.linuxsecuritycentral.com/

[Coder(365) 0]

When setting up my router for OpenWRT, I used Shorewall as the front-end for iptables. It makes things so much easier to configure.

[mungewell 7]

In terms of firewall config I have recently been playing with Pyroman (http://pyroman.alioth.debian.org/).

It has a config file arrangement with rules in clearer english/text. It can pre-parse the rule for correctness and backups the current state of IPtables before applying new rules - useful if you get something wrong as you can 'undo'.

Cheers,

Mungewell.