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

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

[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.

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

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.

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

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.