Hardening Linux

davidmwilliams writes "Out of the box, many Linux systems are insecure with open ports and unpatched vulnerabilities. Read about the essential steps to secure your server as well as how to solve them manually and via automated tools like Bastille."

FP

yes but does it run my favorite rootkit?

I'm not sure what this is doing on /.

It's a pretty reasonable 'how to' of a basic sort but I would expect most of the /. crowd to be well bwond this level of competance.

How To in summary...

For those not wanting to read the article, that "basic how to" is:

1) Disable unwanted services (done via the CLI in this day of GUIs)
2) Keep the OS patched
3) Install and run Bastille to do everything else for you.

Re:How To in summary...

I've alway found GUI tools to be slow and weird.
gentoo has great service management /etc/init.d/ start /etc/init.d/ restart /etc/init.d/ stop

GUI tools are seriously annoying, since this article is about security and disabling unneeded services having config tools that require the unneeded service X11 is pretty silly.

Re:How To in summary...

And yet if someone writes an article like this on how to secure Windows (where lets face it the advice, aside from #3 is exactly the same) it's proof that Windows is insecure.

That's because the article fell through a hole in time, and actually belongs in 1997. They are already yelling to give their article back. No self-respecting consumer distro has shipped with open ports in ages.

Re:How To in summary...

The summary is ... strange.

"... many Linux systems are insecure with open ports" ... "...how to secure your server ..."

Remember all those internet ads about "YOUR COMPUTER HAS OPEN PORTS !!!"

Its a computer connected to "Teh Intarweb" - its supposed to have open ports.

Next we'll read another story about how some "1337 hacker hacked into another person's machine" at IP address 127.0.0.1, erased all their files, and somehow, the "other person" was able to hack their machine and do the same thing ...

Followed by a nostalgiac look at "Punch-the-monkey" ads.

Dude, that article sucked.

Did you see where it mentioned nmap? No? Because it didn't. Wouldn't you expect it to tell you to run nmap from a different machine to you can what your outside profile looks like?

It reads more like someone who's just discovered Bastille and now considers himself "informed" on "security issues".

Step #1. Limit the avenues of attack. This is where you'd use nmap.

Step #2. Remove anything you don't absolutely need. Come on, most people out there will be running some distribution now. At least he could have covered dpkg, rpm, etc.

What's this with the "Enter kill -9 xxx where xxx is the PID."? How about just /etc/init.d/service_name stop? Just use the package manager to remove it.

And editing xinetd.conf / inetd.conf? Again, just use the package manager to remove it.

And he doesn't even go into how each distribution handles package updates? What the fuck? Nothing about "apt-get update"? No "apt-get upgrade"?

No, this article is about someone's discovery of Bastille and how it helps an old, stock installation of Red Hat.

That's a good point. Thanks.

It is often useful to run it locally, anyway, so that you can compare the output of `nmap localhost` and `nmap 0.0.0.0`, as often a machine will have services running that are only accessible locally.

Yep. That's why I prefer hitting it from a different machine. Multiple machines if possible. One on the same LAN segment and one from somewhere on the Internet.

That way you'll see what a would-be-attacker will see.

Sure, I might be running SMTP on port 25, but bound to 127.0.0.1 instead of eth0. An attacker would have to FIRST gain access to my machine through some other means to be able to attack my SMTP service.

Sure, that first hurdle might be set very, Very, VERY, VERY high, but if someone can get over it ... that's why patching is still important. But that's also why patching cannot be your only "defense". You will not know what vulnerabilities the bad guys have found that are not patched yet. Defense in depth.

And that's what "security" is all about to me. It's the PROCESS of evaluating threats and reducing their effectiveness.

This is the last time I'm explaining it to you.

Running nmap on those two IP addresses yields different results.

Maybe it does. Maybe it does not. But that is immaterial. This is about what an attacker would see. Not what your machine can see from itself.

It is possible to set up a system that allows access to those services from eth0 & localhost, but not from any other addresses.

You are not concerned about what you can see from your machine. You are concerned about what an attacker can see. They are NOT the same.

The latter will show exactly what an attacker would see.

NO it will NOT.

Your statement is only accurate for the condition in which NO ports are open. That is a single scenario and does NOT account for the various possibilities. Therefore the ONLY way to know what an attacker would see is to scan the way the attacker would.

When a service is bound to an IP on a machine, it has a choice of which IP to bind to. Services accessible by the connection on her eth0 network device (or any other device, for that matter) can be viewed by nmapping the network IP associated with that device.

No. Again, the system can be set up so that the ports are visible from localhost and eth0. The only way to know EXACTLY what the attacker can see (other than in the specific scenario of all ports being closed) is to scan the way the attacker would.

If her cable modem filtered traffic or ports, the list given by nmap would still be accurate, as any filtered ports would come back either as filtered or closed.

No, the list given by nmap would not be accurate. Because the list given by nmap would show ports open (and therefore vulnerable) when there would be no way for an attacker to see those ports.

Again, the only time your statement would be accurate is the single case of all ports being closed.

If you run it on the IP of the interface an attacker will access, you will see what the attacker sees.

I've given multiple, specific examples where such would not be the case. I've shown where your statement is correct ONLY FOR A SINGLE SCENARIO where all the ports are closed.

As such, going to a different machine is still superfluous. You're giving misinformation by trying to say it's not.

Again, I've provided specific examples that illustrate where the information gained by scanning from an attacker's position would be different than scanning from the machine itself.

You can claim that such is impossible all you want.

But the facts contradict you.

You are taking a single case and claiming that it is the same for ALL the possible configurations. It is not. The only way to know what an attacker will see is to perform the scan as an attacker would.

AppArmour

I know people seem to find it all trendy to bash Novell these days, but AppArmour is a a pretty damn good tool for containing the behaviour of applications. Use a handy little utility to monitor your application (apache, bind, postfix, anything else..) being used in a controlled environment, then apply that ruleset at kernel level and if access isn't defined in the AppArmour profile, it ain't happening.

Hmmmm

Only skimmed the article but it seems to be pushing Bastille more then anything else. Don't know of any installer that automagically starts services unless you specify them yourself. I'm pretty sure there are far better security tutorials and introductions. Better yet, your distro probably has one specifically for it. This seems more like advertising then anything useful. I could be wrong though.

Ipchains?

Apply a firewall to prevent access to potentially vulnerable services, using ipchains.

Is that a misprint, or is Bastille still using ipchains? (Is that even possible in modern kernels?)

Huh?

I haven't read the article. Can someone please tell me what ports are left open on the default installations of some of the major Linux distributions? I'm running Ubuntu, and I was under the impression that the default installation doesn't leave any ports open.

Re:Huh?

As root, run the following command:

netstat -plutn

That will list all the listening services on a Linux box, complete with the program/PID that is associated with it. It's faster than just running something like NMAP, plus it will identify whether a program is binding to a specific external IP, a loopback IP and so on, not all of which an external port scanner is going to be able to report on.

A default Ubuntu box has them all closed.

I'm running Ubuntu, and I was under the impression that the default installation doesn't leave any ports open.

That is correct. By default, they are all closed.

But you may have changed that. If you've installed any P2P or such apps, you may have open ports from that.

As the other poster suggested, use nmap to determine what your outward profile looks like. Even better, have a friend scan your address from their location. That will tell you what your machine looks like from the Internet.

xxxxxx@xxxxxxx:~$ sudo nmap -p0-65535 10.31.198.130

Starting Nmap 4.20 ( http://insecure.org/ [insecure.org] ) at 2007-08-12 07:54 PDT
All 65536 scanned ports on 10.31.198.130 are closed
MAC Address: 00:11:D8:E1:9F:A9 (Asustek Computer)

Nmap finished: 1 IP address (1 host up) scanned in 16.486 seconds

That's without a firewall.

In Soviet Russia

Linux hardens You

Bastille hompage

http://www.bastille-linux.org/ [bastille-linux.org]

Open Ports?

I know that Mandriva tells you if you have any services installed that have open ports (SSH,Samba) when you do the install. There are some necessary open ports for most users, like samba. Having open ports doesn't have to be a bad thing, although I will agree that having them open without any reason is not a good idea. However, as long as you keep on top of the updates (very easy with Mandriva and most other distros), you shouldn't have too much to worry about.

Per-distro comparisons?

In this regard I'm very impressed with the work the Ubuntu developers have done: a netstat -tupa post-install reveals a very small attack-surface where ports are concerned. That said, it would certainly be interesting to see a per-distro comparison at some point.

Anyone know of such a project - even if just comparing a few top-tier distributions?

Re:Per-distro comparisons?

I think a dist security roundup would be an awesome thing. Do a default install of Mandrive, RedHat, Ubuntu etc. and then run nmap, examine their password policy, see what "dangerous" apps are installed by default and so on. Dists should be named and shamed if they have a single port open.

Hardened Linux From Scratch

This is mainly for those who roll their own using LFS, but Hardened Linux From Scratch [linuxfromscratch.org] should give some tips, and practical advice, which critical areas need patching, plus proper practices.

Open ports and unpatched vulnerabilities?

If your Linux distro is out-of-the-box "insecure with open ports and unpatched vulnerabilities", then change distro. If this is not an option, it's time to approach your vendor menacingly, clue bat in hand.

Article not very informative

The article isn't very informative and makes several assumptions about the distribution being used. For example, when it tells the reader to "ps aux|grep http" and then "kill -9 [the pid]" it doesn't take into account that Debian systems are running Apache2 as 'apache2', not 'httpd'. Why you would SIGKILL the running process instead of just using apachectl or the appropriate init script is also just as short-sighted.

Run 'netstat -apvtu' if you're worried about what you have open. A good ingress/egress firewall policy is ideal and any competent Linux user should be forced to learn iptables instead of relying on a GUI or automated configuration tool to make assumptions about the purposes of your network.

The article isn't very useful or accurate.

Box?

Out of the box, many Linux systems are insecure with open ports and unpatched vulnerabilities.

That box must have a lot of dust on it, and an early 13-floppy Slackware distro inside.

Before making a claim like that, the writer should come up with at least three examples, from current versions of major distros.

Reminds me of a local woman who said "We must have a town-wide neighborhood watch, because there's a child sexual predator on every block." In the several years since she raised that hysteria, there's been exactly one serious case in town: one of her best friends had his extensive child porn collection found by the police. He hired the state's most expensive lawyers and got off with probation. She's still his best friend.

Back to the topic. The article mentions telnet. Is there a single current distro that comes with telnetd enabled? Let's help the sloppy author. Has anyone here installed any current distro and found "open ports and unpatched vulnerabilities"?

Hardened? Hardly.

This article makes no mention of grsecurity [grsecurity.net]. Surely closing off unused services and patching vulnerabilities can certainly prevent a penetration, but what happens if a penetration is successful? grsecurity is the answer.

So what - we are all NAT'ed anyway?

I bet that 99% of Linux users are behind a NAT router (because as IT geeks they have tons of networked gear and a private network). The remaining 1% with a public IP directly on their Linux box probably know what they are doing. And don't give me the "what if there is port forwarding rules on the router" argument. If the user has port forwarding rules then he/she also knowledgeable enough to secure the target Linux box. I know a lot of IT geeks (being one myself) and I seriously don't know ANY IT geek who is not using a NAT router for their local machines. The few that do have a machine on a public IP (hobby mail servers, game servers, etc) already know what they are doing and don't need an article about open ports on a default-installed Linux box. - Jesper

Since the submitter is also the author...

Can you tell us the story about how you came to write this article?

Here's how I'm picturing it:

(editor) Mr. Williams, we need a techie article on Linux.
(mr. williams) Okay... I haven't touched linux since I played around with my RedHat 7.2 box 3 years ago.
(editor) Do you still have it?
(mr. williams) Yes, what would you like me to write about it?
(editor) Write something up on securing its "holes and vulnerabilities", and we'll sensationalize it a bit by making it look like Linux is insecure out of the box.
(mr. williams) I don't know how to do that.
(editor) Find something on google. Try it on your RedHat machine.
(mr. williams) I'm going to look really stupid.
(editor) You're a journalist.

The defaults are no longer what they were in 199x

Seems to me the article is just pimping bastille Linux. Years and years ago, most distros did indeed ship with some pretty crack-worthy options enabled by default. It took a small amount of prodding by the community, but most distros, these days, lean towards a default disable policy:

- [KU]buntu
    All services off by default. netfilter rules are default allow however, but there is
    nothing to connect to.

- Fedora/RHEL/CentOS
    Choose during install what services you want enabled/open/firewalled.
    SELinux enabled by default.

- Knoppix 5.1.1
    Only Port 68 for dhcp client listener. /etc/hosts.deny ALL:PARANOID

- Mandriva 2007 Bootable CD
    Port 6000 is all that's open (X server. Ok this is dumb, why?)

Other distros follow similar suit. You can find out what's running on your linux box with:
  - netstat -tuna (all tcp/udp sockets, dont resolve names, all listening/non-listening sockets)
  - locate iptables; sudo iptables -nvL (show iptables chains for netfilter)

Chances are, if you've not mucked around with the default services things are pretty tight.
TFA is a bit inaccurate for linux systems these days.

newbie article

The obvious problem with this article is they mention using "Bastille" and forget to mention grsec [grsecurity.net]. I don't really care about Bastille, but I do care about using grsec. Just because you turn off some services doesnt mean someone is not going to pop an xterm off your apache web server from some random cgi vulnerability... At least when someone compromises your web server in this way (which is probably how most linux web servers get compromised these days anyway), the attacker wont be able to do anything besides navigate the directory tree maybe. The attacker wont be able to view processes that are outside their own uid. The attacker wont be able to execute binaries outside of the standard bin directories (so custom scripts/binaries wont execute), and stack overflows do not allow execution of arbitrary code.. Its not a very fun environment to work in, most attackers will just look around and exit when confined to this type of environment...

Redhat 7.0, ipchains?

Uh oh..

Why doesn't linux come "closed" out of the box

i.e. with all ports closed and all services off, then take the installing user through
some wizards with a few different, and mostly conservative, minimalist options
for opening things up, explaining the cost-benefit of the options.

I suppose it's just inertia combined with Unix/Linux's pre-internet-malevolence
origins. The whole idea originally was for a number of socially responsible researchers
to have their computers maximally cooperating with each other (go figure). It wasn't designed
with human viruses (malicious crackers) in mind at the get-go.

But we've had net morons long enough now that you'd think a closed and incrementally
open up policy would be a no-brainer for the default installations of net-facing OSes like
Linux.

Secure wget!

Almost all script kiddies work off the same theory: find an application that has not been updated, and which has a security vulnerability (un-updated versions of Wordpress or AWStats are always favourites), use this to run wget to pull a script, rootkit, etc. onto the server, then "break" the machine and use it as a spambot.

The simplest way, then, to prevent script kiddies from compromising your system is not only allow access to wget through sudo! Simply chmod it.

Now, this is no excuse not to ensure everything else is up to date, etc. But a simple chmod can make an enormous difference to the security of your system.

Hardening Linux

1. Insert OpenBSD CD
2. Reboot
3. Follow the instructions on screen

Bind services to localhost.

Services run from inetd/xinetd have their port and interface bindings managed externally, and since UNIX systems have run multihomed almost from the start, there are few if any deamons that can't be run bound to localhost, so if you have to run a local webserver for some purpose it can be unconditionally protected from remote exploits simply by running it on localhost... so as far as an attacker is concerned it doesn't exist.

Installing Debian server

I would install a Debian server using the minimum install cds and then apt-getting just the services I need from the mirrors (which should have current patches). I mean, if it is going to be a server it should have a somewhat fast internet connection, right?

Use nmap?

Why do "security experts" like these folks always suggest using nmap to determine what services you are running? Have these folks never heard of netstat?

i'm secure, too

i just keep the cup-holder closed, and keep the screws on the back of the case tightened ... seems secure enough to me ...

Hardening? Wha?

Is there anyone, anyone at all, who doesn't think that hardening linux and hardening windows are the same exercise in futility?

Now from those people, should they exist, is there anyone actually skilled in security?

From this now impossible subset, why aren't we just moving to openbsd?

I'm a windows based engineer, and every time I look at linux I see the same great gaping security holes as the core system I use and less usability. So I stay with windows, where its easy. And strangely enough all my bastion hosts are Theo's work.

rofl

Don't worry, hackers respect people with unix systems

Source is an interesting one

I thought this was pretty light content wise, until I noticed it was from the publication that includes Stan "ISO" Beer among its staff writers .... (can't find any references to the "What's an ISO image ?" article, but those of you who remember the article will no doubt remember this guy fondly).

Re:Lots of linux stories on the front page

You DO realize what website you're on, right?

Seriously.

Re:Lots of linux stories on the front page

Are you new?

Re:Lots of linux stories on the front page

Um, I see you have a 20-digit UID or something, but how can you be surprised that /. is generally pro-FOSS, pro-Linux???

Re:Lots of linux stories on the front page

Well, if you're looking for something that's "not linux", you can always enter this contest [trolltalk.com] - there are already a few entries that cover "open ports" that have nothing to do with linux - and one (# 12) that really nails "hardening" pretty good.

"The purpose of this post is to see the reasoning behind so many linux fluff stories making front page "

Its Sunday, this is slashdot, not PC Magazine, CmdrTaco is stuck reviewing submissions over dialup, and the big news of the MONTH was SCO getting kicked in the nuts. [youtube.com] - but at least they got more than the $20 that guy got. Hopefully one or two will also get prison, but I'm not holding my breath.

Maybe they can turn the whole SCO fiasco into a tv show, like this kicked in the nuts [youtube.com] video, but in reverse - have Darl wear the orange clown wig and PAY people $699 each to kick him.

Re:Lots of linux stories on the front page

If there's a bigger - and by bigger I mean more populated - Linux fanboy forum than slashdot, I'm not aware of it. All in all, I think it's probably a good thing though.

Re:Lots of linux stories on the front page

Yah, I reckon Slashdot ought to broaden its appeal a bit, let's follow Digg and start an expansion into Adam-Sandler-did-a-funnie-on-Colbert Celebrity Bullshit Non-News.

Re:Lots of linux stories on the front page

I hope you don't use Windows, with that comment about forcing others to use.