Making Your Linux Box Secure

pryan writes "rootprompt.org has some interesting articles on locking down a Linux box on a hostile network (read: Internet) and cloaking a Debian box so script kiddies don't find it. Check out fortress building, part 1, and part 2. For you Debian freaks (I'm wearing a Debian swirl t-shirt as I type this), check out cloaking Debian. Of course, the cloaking article is easily adaptable to other distributions. Let's lock down those boxes! "

Comments

Another great resource (NT, Linux, Solaris)

[Saron]

Is Lance Spitzner's Security Whitepapers.

Its a handy little site, covers firewalls in NT and Linux, how to properly armor a NT, Solaris, or Linux install (from the perspective of Redhat, but thats easily adaptable), and for those of you that are a bit more curious, he has a "How to build a honeypot" section.

Enjoy!

In Other News:

[Denor]

Change of Pace for Slashdot Disturbing, Posters Find.

ASSOCIATED PRESS - Dozens were shocked today as popular website Slashdot posted a story that had nothing to do with a corporate or governmental conspiracy.
"I'm absolutely floored" one frequent poster commented. "I mean, I was all ready to get out one of my 'damn the man' rants for karma, but it turns out it's completely offtopic for this story. I mean, I'd actually have /lost/ karma! That was close. I have no clue why Slashdot would do this."
Many others were confused as well. Local trolls were dismayed, one going so far as to assert "I'm betting this is a slashdot conspiracy to try to lull us into a false sense of security."
Many contributors fell into the pattern of trying to form a Slashdot editorial conspiracy, but ultimately failed as the comments did not have nearly the manifesto-inspiring potential that the earlier front page stories had included.
"I was all ready to boycott this 'debian' thing they mentioned in the blurb," commented one disillusioned poster, "But then I went and read the article, and there was nothing about corporate conspiracy at all!"
While there was still theorizing by those who had not read the article, for the most part conversation was stilted and akward, with many participants struggling to figure out exactly what, if not governmental or corporate conspiracy, the article was actually about.

Our comany firewall

[doomy]

Here is the scripts I used to secure our file wall
and enable a nice well secured debian based internal network.

SERVER_IP= #set this to server ip

#
# Local area network
ifconfig eth1 192.168.0.1 netmask 255.255.255.0 up
route add -net 192.168.0.0 netmask 255.255.255.0 window 16384 eth1

# S E C U R I T Y ################################################## ###

#
# Enable syncookies and ip forward

echo 1 > /proc/sys/net/ipv4/tcp_syncookies
echo 1 > /proc/sys/net/ipv4/ip_forward

#
# Let local calls through

/sbin/ipchains -A input -j ACCEPT -s 0/0 -d 0/0 -i lo

#
# External calls to 127 blocking.

/sbin/ipchains -A input -j DENY -p all -l -s 127.0.0.0/8 -i eth0 -d 0.0.0.0/0 -l

#
# IP MASQ Forwarding for 192.168.0.2 subnet
/sbin/ipchains -P forward DENY
/sbin/ipchains -A forward -s 192.168.0.2/24 -j MASQ

#
# Modprobing
modprobe ip_masq_user
modprobe ip_masq_ftp
modprobe ip_masq_irc ports=6667,6668,6669,6670
modprobe ip_masq_raudio
modprobe ip_masq_quake ports=26000,27000,27910,27960

#
# Now block some ports we dont want people to use from outside
# block from ICMP troubled ports

/sbin/ipchains -A input -p icmp -j DENY -s 0/0 -d 0/0 21 -l
/sbin/ipchains -A input -p icmp -j DENY -s 0/0 -d 0/0 23 -l
/sbin/ipchains -A input -p icmp -j DENY -s 0/0 -d 0/0 25 -l
/sbin/ipchains -A input -p icmp -j DENY -s 0/0 -d 0/0 79 -l
/sbin/ipchains -A input -p icmp -j DENY -s 0/0 -d 0/0 139 -l
/sbin/ipchains -A input -p icmp -j DENY -s 0/0 -d 0/0 143 -l
/sbin/ipchains -A input -p icmp -j DENY -s 0/0 -d 0/0 1080 -l
/sbin/ipchains -A input -p icmp -j DENY -s 0/0 -d 0/0 6000 -l
/sbin/ipchains -A input -p icmp -j DENY -s 0/0 -d 0/0 12345 -l
/sbin/ipchains -A input -p icmp -j DENY -s 0/0 -d 0/0 31337 -l

#
# Block ICMP flooding/pinging

/sbin/ipchains -A input -p icmp -j DENY -s 0/0 8 -d 0/0 -l

#That's some basic stuff to be blocked. These rules will block: ftp, telnet,
#smtp, finger, netbios, imap, socks, X11, netbus and Back Orfice. It will
#also create a syslog entry as logging (-l) has been enabled. You can add or
#remove ports as you want.
# got this bit from a security listing

# Block everthing on eth0 for the following ports
/sbin/ipchains -A input -j DENY -p tcp -l -s 0.0.0.0/0 -i eth0 -d ${SERVER_IP}/32 2401
/sbin/ipchains -A input -j DENY -p tcp -l -s 0.0.0.0/0 -i eth0 -d ${SERVER_IP}/32 6000
/sbin/ipchains -A input -j DENY -p tcp -l -s 0.0.0.0/0 -i eth0 -d ${SERVER_IP}/32 515
/sbin/ipchains -A input -j DENY -p tcp -l -s 0.0.0.0/0 -i eth0 -d ${SERVER_IP}/32 752
/sbin/ipchains -A input -j DENY -p tcp -l -s 0.0.0.0/0 -i eth0 -d ${SERVER_IP}/32 1024
/sbin/ipchains -A input -j DENY -p tcp -l -s 0.0.0.0/0 -i eth0 -d ${SERVER_IP}/32 111
/sbin/ipchains -A input -j DENY -p tcp -l -s 0.0.0.0/0 -i eth0 -d ${SERVER_IP}/32 5432

Basically it blocks almost every kind of ICMP and any unwanted attempts by intruders and also blocks access to resources used only within our network. Eg: Our postgresql server and so on.. Also it logs any illegal activities.

Enjoy.
--

Re:Our comany firewall

[arivanov]

/sbin/ipchains -A input -p icmp -j DENY -s 0/0 -d 0/0 79 -l

You mean tcp (or for some of these UDP) right?

Re:Our comany firewall

[PhiRatE]

Just a few notes:

Always enabled ip_forwarding _after_ you have initialised your firewall, in this case, move the echo to ip_forward at the top down to the bottom of the script. The reasoning behind this is that without such a move, there is a short window during which your system will forward but your firewall is not in place, thus if the attacker somehow manages to reboot your firewall they can get through into your internal network in the clear. Certainly in this case this is a very small risk, but its a trivial change and good for completeness.

The best security policies are built from the "deny first, accept later" method. You should set the default policy on your network to DENY, and then accept what you need, not the other way around as you have done here. Yes this requires a lot more work, since you have to really figure out what you need to access, but it remains far more secure against unanticipated future attacks and insecure internal machine configurations (ie, leaving on a service that you didn't mean to).

You should always drop martians on a firewall as well, a martian is a packet that has an address that should not be possible, this includes broadcast addresses you don't want, 192.168.* from the internet, 10.* from the internet, any addresses you have inside the firewall, etc. For complete lists check out places like securityfocus, they have some good resources, the iptables and ipchains sites have good information as well.

Again, only accept in packets addressed to legal accessible hosts, only send out packets addressed from legal sending hosts.

If at all possible, create a real internal network setup (ie, a 192.168.* address space), and use NAT (available in iptables and ipfilter and to some extent in ipchains) to translate these to external, this causes even more difficulty for IP based assaults as internet and internal packets must be explictly converted before they are effective in either network, giving another layer of security. This also follows on to greater security possibilities such as a public and private DNS (one outside, and one inside, that give out only the relevant information, revealing little about your network structure), binding many services at the firewall and using port based NAT to forward different ports to different hosts (confusing the attacker, making more efficient use of network resources including clustering, and causing many multi-service exploits to fail).

If possible, a reasonable variation in the operating systems used can be helpful as well, don't use an O/S you're not familiar with, you're more likely to make a critical mistake in securing the box, but if you're familiar with OpenBSD and Solaris, use both rather than aiming for a single-os network, it improves the odds of partial network survival in the event of operating system-specific exploits. This includes architectures too, most buffer overflow exploits come out for x86 systems, so having a PowerPC or MIPS system instantly improves your odds against those attacks.

All in all its a balancing game, but you can certainly make life extremely hard for those attempting to penetrate your network at many levels.

Re:Windows cloaking device

[slickwillie]

Just run Blue Screen of Security 1.0.

Try Bastille Linux

[slickwillie]

Here. It is supposed to harden your Linux system. I haven't tried it though. I downloaded it, but before I got around to running it, I installed FreeBSD.

Lock down? Why?

[Fervent]

The whole principle of hacking is to share and divulge information and ideas. You claim information wants to be free, then proceed to "lock down" your Linux box (this is the modern day hacker's paradox).

According to Steven Levy, the "original hackers" (those working at MIT) had a small drawer where all the paper tapes could be read, borrowed, changed and altered. Anyone could have access to the box.

When the university developed their first time-sharing machine (replete with user names and passwords) they hated it. Not for the fact that they were losing computer power (although some would argue this was important) but because information was hidden from other users.

They accepted the time-sharing box under one condition: users could have passwords, but all user information could be read by any other user. This included admins. So the standard user could change and view the admin's files, and vice versa.

The tape drawer was reborn.

One would argue that the modern-day hacker has really lost touch with what hacking is supposed to mean. It's about sharing, and by "locking down" boxes and trying to break into web servers to expose security, we're moving farther and farther away from that ideal. We should go back to the tape drawer, people.

P.S. Read the book "Hackers" by Steven Levy. You'll be glad you did.

Amateurs . . .

[alhaz]

OK, I'm sorry. I shouldn't talk down to people, but that "cloaking debian" article, while definately helpful, smacked of an amateurish failure to fully comprehend how these things work. For starters he has you turn on ip forwarding w/o even mentioning what it's for and letting you decide if you really want it. (tip, unless your linux box is a router, you don't)

There is a MUCH better free resource on the issue - http://www.linux-fire wall-tools.com/linux/firewall/index.html

Run it. Read it. Study it. Compare it with the documentation. OK, just use it, but using it and working with it can help you get a far better grip on what's going on. The script it will generate for you is FAR better at keeping a lid on your network connection.

ls output from publicfile's ftpd

[woods]

publicfile is a fabulous package that should really get much more recognition and use. It can do 90% of what most people want from httpd/ftpd servers in a faster and far more secure manner.

However, one stumbling block for a lot of people is Dan Bernstein's exclusive use of his EPLF format for LIST and NLST requests. This format is a great idea but still isn't very widely implemented by ftp clients including most web browsers; this is why you'll usually just see the raw eplf output on most clients when you do a dir or ls (example eplf output).

I wrote a patch to publicfile that will cause it to use the more widely accepted /bin/ls format. This will allow it to display properly in most ftp clients and web browsers (example of patched publicfile ftpd, over 65k modem BTW).

The patch is at ftp://ftp.essc.psu.ed u/pub/emsei/woods/publicfile_no_eplf.patch. I don't believe it compromises the security of the package in any way. Please let me know if you find it useful, or have any suggestsions.

-- Scott

How apropriate...

[nevets]

Yesterday, a friend of mine found out (I told him) that he was hacked.

He first called me to ask me why he can no longer read his vfat filesystem after he mounts it. It seems that the functions (ls, cd, ...) core dump after he access his vfat system. Then he ask (as a side note!) is it normal to have the Transfer and Receive lights of his cable modem flashing while he is not doing anything. This is where I became curious.

I asked him to do a netstat -a and he told me that he sees a connection to .ksu.edu on port 1025. Looks like he was currently being hacked. I did a nmap on his machine and it was a straight out-of-the-box version of RedHat 6.1, with everything from linuxconfd to webservers to finger open. He just told me he didn't care.

I helped him reinstall his whole system with only his mp3s stored and we whiped clean his harddrive and reinstalled. I showed him how to use ipchains and to turn off all daemons that he did not use. We also set up a system to perform check sums of his file system to compare it to a check sum on a cdrom.

With more and more users connecting to the Internet via cable modems and DSL and leaving their machines up 24 hours a day, things like this will happen unless you lock down your system.

I have to mail him this.
Steven Rostedt

Re:http://cr.yp.to/

[Bruce Perens]

Quoting DJB: If you want to distribute modified versions of qmail (including ports, no matter how minor the changes are) you'll have to get my approval.

IMO that's a genuine lack of freedom. Next time you have a question like this, would you please leave out the gratuitous insult?

In his place, I would publicize the checksum of the "official version" and let people do what they want with unofficial versions. I would use a trademark to distinguish official and unofficial versions. Since I started using that strategy for the official Debian CD ISO image, it's worked pretty well.

Bruce

Hmm...

[Aqualung]

I can just see it now....

root@host#telnet box.host.org 25
Trying 123.244.244.244...
Connected to box.host.org.
Escape character is '^]'.
220 box.host.org ESMTP Sendmail 8.11.0/8.11.0/NOT DEBIAN I SWEAR!!!!! 8.11.0-1; Wed, 13 Sep 2000 13:47:29 -0500
Script Kiddie:Curses, foiled again!

:-)

----
Dave
MicrosoftME®? No, Microsoft YOU, buddy! - my boss

Re:Windows

[bartjan]

Securing a windows box is easy: remove all cables connected to it.

http://cr.yp.to/

[Russ Nelson]

If you want secure servers, run Dan Bernstein's software. Three of the top ten programs on SANS's list of security holes include bind, sendmail, and ftp servers. Dan has secure replacements for all of them.
-russ

Re:http://cr.yp.to/

[AliasTheRoot]

The license he distributes his software is his business, just because it doesn't mesh with the prevalent ideology here on /. doesn't make it bad.

Me, I couldn't give a rats ass what license something is distributed under, it's just not important to me in the selection process.

Tools for the job.

Re:http://cr.yp.to/

[Bruce Perens]

Dan is a pretty interesting guy. I just wish he would change his take on licensing. None of his replacements for other programs have OSD-compliant licensing, as far as I'm aware, and IMO his reasons for that aren't good enough. The result is that people write replacements for his replacements! The Postfix mail delivery agent is a good example of this.

Bruce

Re:Security != "security_from_script_kiddies"

[G27 Radio]

The cloaking article says "they can't crack what they can't find"... and sadly I think it's very true. My home small network has a firewall with only ssh2 open. I get portscanned about 3 times a day. I think my setting is pretty secure, but I might always have a security hole somewhere. However, script kiddies will not bother with my computer because so many others are fully open.

I get scanned that many times an hour at times (probably because people know my subnet is all cablemodems.) One day I decided to run nmap on the IP's as they scanned me. On about the third IP address I that nmapped I found an open port 139. So for kicks I connected to it with a null login and password from an Win2k box I was testing. His entire C: drive, CDROM, and CDR were wide open. How convenient of him to leave a guest account for the people he scanned to find out more about him. I got bored fast (sharing over tcpip was way slow) so I didn't bother to read through his homework, but I did download a photo of him and his mother. I should've mailed it back to him from a hotmail account and told him he's an idiot. Disclaimer: Before you even think about trying this yourself, consider that the machine may be a honeypot owned by a hacker. Documents and executables may contain trojans.

Considering how quickly I got scanned by a script kiddie whose own system was wide open, I have to wonder is this the average skill level of a script kiddie?

There is an excellent radio show available online called Info.sec.radio. It's available on SecurityFocus.com under the Audio/Visual Media section. They do a one hour show every two weeks. They've got some cool interviews: the RCMP officer that busted the welsh hacker, and most recently Kevin Mitnick himself. They also have done a feature on Hacking Through the Ages which is a historical perspective on hacking. Every show they do a segment on new vulnerabilities.

I wasn't expecting much but now I'm addicted. They do an excellent job of providing a lot of information quickly. I think what suprised me the most was that the show moves quickly and is not boring at all. If you have any interest in securing/cracking systems you'll be glad you checked it out (IMO).

Requires Realaudio :|

numb

GNU system philosophy

[Ross C. Brackett]

I think things have changed a bit now, but you're right -- GNU software design certainly reflects this paradigm, even in today's modern security-paranoid age. Here's a great few paragraphs I've excerpted from the GNU sh-utils manual from '96 (I kid you not)

----

Why GNU su does not support the `wheel' group
(This section is by Richard Stallman.)

Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)

However, occasionally the rulers do tell someone. Under the usual su mechanism, once someone learns the root password who sympathizes with the ordinary users, he or she can tell the rest. The "wheel group" feature would make this impossible, and thus cement the power of the rulers.

I'm on the side of the masses, not that of the rulers. If you are used to supporting the bosses and sysadmins in whatever they do, you might find this idea strange at first.

----

I didn't know if I should shake my head and weep or pump my fist "right-on" style and start a food collective. It wasn't exactly the answer to the question I was looking for, but it is one of the cooler things I've ever seen in a software manual.

Better to cloak or look like boringly visible?

[dpilot]

Cloaking seems to be a great idea, but it falls on a few counts. First off, you really shouldn't block all ICMP messages. You really do need some of them for efficient operaion. I don't know if the ones that need to be open can be used in a ping-like fashion, but I wouldn't put it past someone to figure out a way.

Second, you really need at least some opening for IDENT, or else you'll get terrible throughput on your email. You can filter based on the source IP, but that can be spoofed. (Of course the responses then go to the mailrelay...) Some web sites seem to generate IDENT requests, but I'm not sure what they do if you DENY them.

This is even before we get to scans with illegal packets. I'm under the impression that there are some scans that will get responses from some firewalls even if a port is "stealthed".

In general, it just might be better to look "boringly visible" and offer no services, just closed ports. Nothing to offer, nothing to hide. At the same time, it would be useful to get the kernel patch that lets you change your TCP fingerprint - make your box look like OS/2, for instance.

The situation will change when Kernel 2.4 gets out with netfilters. Stateful filtering will make it possible to DENY more effectively if you want to fly with "stealth", and the general architecture should make it easier to look boring, including changing the TCP fingerprint. (Netfilter or ipchains will allow you to offer ports to some IPs while hiding from others, netfilters will just let you do a better job of it.)

Re:Better to cloak or look like boringly visible?

[mjg]

There is a patch available here called the Linux IP Personality patch. It adds features to netfilter in the 2.4 kernel series which gives you the ability to change the network fingerprint, so you can, for example, fool nmap.

So yes, you can make your box look like OS/2 pretty easily.

Security != "security_from_script_kiddies"

[JPS]

The cloaking article says "they can't crack what they can't find"... and sadly I think it's very true.

My home small network has a firewall with only ssh2 open. I get portscanned about 3 times a day.
I think my setting is pretty secure, but I might always have a security hole somewhere.
However, script kiddies will not bother with my computer because so many others are fully open.

Securing a network against SK is fairly easy because you just need to be more secure than the norm. Securing a network for real is certainly harder.

Social Engineering

[zpengo]

It always comes down to the human element, though, which is the part that the 1337 h@x0rz and skr1p7 k1dd13z never quite figure out. The great crackers went beyond mundane knowledge of how to open a box to use creativity, psychology, and human nature to get people to give up the goods. I've been made a fool once or twice, but each time I let myself get talked into it. A box is only as secure as its administrator is paranoid.