Is it safe?

Mr Green · 2006-05-15 17:24:28

I listened to Security Monkey on the tllts the other night ...

It freaked me out ... fake kernel modules, hacked ssh, crpyting swap, zeroing empty drive space, rootkits etc...

I was just wondered what out listeners (users!) do to secure there systems from the dark place we know as the net?

Are there any plans for a apt-armour for pacman ?

Or is Arch (linux) secure as its made out to be ?

thoughts

dtw · 2006-05-15 17:49:32

I think the key things to remember are as follows:

1) Aside from a love for you box and a desire to keep it un-violated and "muddy footprint" free - what have you got to lose if you are hacked?
2) Of all the millions of machines connected to the internet why the hell would they hack you?
3) If you have even reasonable security it's not going to be _easy_ to hack you so why not put your efforts into hacking someone you know has something you want?

s/hack/crack/g (sorry)

I guess being cracked isn't your only concern, what about secure comms over the net? But what can you do about that? Not transmit sensitive info.

lumiwa · 2006-05-15 19:11:03

dtw wrote:

I think the key things to remember are as follows:
1) Aside from a love for you box and a desire to keep it un-violated and "muddy footprint" free - what have you got to lose if you are hacked?
my privacy!
2) Of all the millions of machines connected to the internet why the hell would they hack you?
It same as war: some died some no...
But if you protected you have less chance...
3) If you have even reasonable security it's not going to be _easy_ to hack you so why not put your efforts into hacking someone you know has something you want?
s/hack/crack/g (sorry)
I guess being cracked isn't your only concern, what about secure comms over the net? But what can you do about that? Not transmit sensitive info.

syamajala · 2006-05-15 19:16:28

i disable root (change shell to /bin/false) and install sudo. Make sure u set a root password before doing this and then configure sudo to use that password instead of the user's normal password. that way all things get logged. I also use tcp_wrappers instead of disabling. Ideally iptables should be used too. Finally, i'm gonna play with selinux in arch soon. after reading this, http://www-128.ibm.com/developerworks/l … w07SELinux

kill · 2006-05-15 19:44:15

Fake kernel modules, rootkits can easily be avoided. Don't install anything from a source you don't trust. If your worried about getting something bad from an official Arch package then you should probably stop using Arch and stitch to something else. As long as you stick to the official repos and check anything you build from Aur your safe. Remember only root can install that stuff.

Crpyting swap really only protects from physical access attacks. Crypting swap will only keep uncleared information that is on your swap partition from being easily read. If the computer is running then an app that wants to read it can just use the system to decrypt it for it. If you can't trust where you keep your computer then you can't trust what you run on it.

Zeroing empty drive space is also a physical access stopper. Yes there could be personal info in that space but unless someone is going to analyze the drive you really don't have much to worry about.

As far as other precautions. Iptables firewall is always a good idea. SELinux is also an option but there is also Grsecurity which provides acl's plus some further security enhancements via Pax. Are those really needed. Probably not. Would it hurt to use them, yeah it will. They are a pain to setup and keep up.

Your best best to stay secure is to be careful. Don't go and run kernel modules you found on some shady website. As far as overall Linux security when you go on the net. If there isn't anything you have running that can be exploited you have very little chance of being compromised.

Gullible Jones · 2006-05-15 19:51:19

I do the same as syamajala with sudo; in addition I've set things up to block all remote logins, since I do not use SSH. I tried messing with BSD secure levels but those are worthless, since setuid is run every login and Level 2 (the default) blocks that. I do not use a swap partition (384 MB of RAM being more than enough). I have chkrootkit installed and scan with it regularly (I know, I know, paranoia).

Syamajala: I don't know what you're talking about re tcp_wrapper, could you explain that to me?

Oh yeah... I was thinking of trying out RSBAC or AppArmor too. I took a look at Gentoo's SELinux instructions page, but it looks like an absolute PITA to use, and GrSecurity lags a bit with support for 2.6 kernels.

syamajala · 2006-05-15 20:07:23

Gullible Jones: its just the hosts.deny and hosts.allow stuff. Some people just get rid of the ALL: ALL: DENY in hosts.deny some people just keep it and add things to hosts.allow (thats what i do).

kill · 2006-05-15 20:10:55

Gullible Jones wrote:

tcp_wrapper, could you explain that to me?

It is an access control mechanizm for inetd. It isn't needed unless you use inetd. Also any network service that doesn't use inetd will bypass the access restrictions set by tcp_wrappers.

Edit:
Die.net has a really good description of tcp_wrappers. Section 5.3 of their firewall howto.

Die.net wrote:

Tcpwrappers controls access at the application level, rather than the socket level like iptables and ipchains. ... Tcpwrappers is commonly used to protect services that are started via inetd (or xinetd). But also any program that has been compiled with libwrap support, can take advantage of it. Just don't assume that all programs have built in libwrap support -- they do not. In fact, most probably don't.

Gullible Jones · 2006-05-15 21:26:35

kill wrote:

Gullible Jones wrote:
tcp_wrapper, could you explain that to me?
It is an access control mechanizm for inetd. It isn't needed unless you use inetd. Also any network service that doesn't use inetd will bypass the access restrictions set by tcp_wrappers.

Err, shouldn't xinetd be used these days? :?

syamajala · 2006-05-15 22:27:30

i almost have selinux working in arch, i just have a problem with my policy.conf... might have to borrow one from somewhere else. just follow the instructions in this article http://www-128.ibm.com/developerworks/l … w07SELinux if anyone is interested in trying it. some notes:
don't use cvs just get the source from the selinux site.
before you build policycoreutils, install libsemanage. everything else just follow what the article says, until you get to the checkpolicy -o policy.bin policy.conf thats where i am stuck right now. it seems that the policy.conf it creates has a bug in it.

kill · 2006-05-15 22:34:15

Gullible Jones wrote:

Err, shouldn't xinetd be used these days?

kill quoting Die.net wrote:

...via inetd (or xinetd).

Personally I wouldn't use either.

syamajala wrote:

i just have a problem with my policy.conf... might have to borrow one from somewhere else.

Fedora has the most complete SELinux policy I have ever seen. I would recommend you look into their Targeted policy. It's not as secure as their strict policy but it causes less apps to break.

user · 2006-05-15 23:49:26

delete(comment) all securetty, sudo pacman -R openssh, sudo pacman -S chkrootkit, rkhunter( http://www.rootkit.nl/ ) ..

neotuli · 2006-05-16 01:34:04

Oh this is a great thread to mention one of my latest additions to [extra], mod_hosts_access.

Apache, by default, does not use tcp_wrappers for access control, it uses its own allow and deny lines in configuration files. Though this is obviously acceptable, some find it easier to unify all of their white/black lists in hosts.allow and hosts.deny. This apache module allows you to make Apache check with tcp_wrappers, in addition to its usual builtin access control business, and thus allowing you to unify all of it in those couple files.

syamajala · 2006-05-16 02:59:44

thats cool. i'll have to try that sometime.

Mr Green · 2006-05-16 07:48:03

ok so I knock out root use sudo ..... I'm sitting in front of your machine & I drop knoppix in cd/dvd drive & switch on pc ???

do I not have full access to your system?

Gullible Jones · 2006-05-16 10:58:49

We're talking remote security... Local security is another matter entirely, trying to make it tough to mess with a machine that you have physical access to is probably futile.

Mr Green · 2006-05-16 11:24:08

ahhh ok .... ;-)

guess the sshd (change port) thing

firewall, well I am behind a router so was told I did not need a firewall :oops:

how to deal with scripts running from say /tmp mailbots etc...

syamajala · 2006-05-16 11:46:44

kill: i checked out the fedora policy. i think they use this but i'm not completely sure http://serefpolicy.sourceforge.net/ it seems that policies are very distro specific so i couldn't use theirs... plus i got more errors when i ran checkpolicy on the policy that got created when i used the serefpolicy stuff. maybe i should just give up now...

user · 2006-05-16 13:23:28

Hardening Linux: a 10 step approach to a secure server
# Choose a widely used Linux distribution that releases security updates in a timely manner.
It's not a matter if there will be new vulnerabilities in your Operating System: it's just a matter of when they will be found. And when that happens you want to be among the first ones to obtain and apply the fix (or the compensatory control, should a fix not be initially available).
And the more people using your distribution, the sooner the vulnerabilities will be found and corrected. The worst thing that could happen to you is a vulnerability only known by a few, with a so called "zero day exploit" being used in the wild.
And avoid exotic or custom configurations as much as possible: standarization is a big advantage. It's much easier and faster to apply a security fix by just installing a default package through an standard tool (rpm, yast, apt-get, emerge, etc.) than to reconfigure and recompile from source a whole set of applications and libraries.
# Plan the filesystem layout beforehand.
Avoid using a single partition approach. Create, at least different partitions for /, /tmp, /home, /usr and /var. Mount /tmp, /home and /var with, at least, the following options: noexec, nodev and nosuid (why would anybody need to create a device, an executable or, even worse, a setuid executable in these three directories anyway?).
# Don't install unnecesary packages.
If you don't have a need for package xyz, just don't install it. You can always install it later if you find out that you really need it. The more software that you have installed, the more likely you will be impacted by a vulnerability, and the more software you will need to keep up to date.
Avoid compilers and developer tools. Avoid network tools. Avoid packages that have binaries setuid root (some of them are really needed, but don't get carried away).
# Change default passwords and create regular users
Never forget to review /etc/passwd and /etc/shadow looking for default users. Lock out non interactive accounts (a simple '!!' in the password field in /etc/shadow will do it – for extra protection replace the shell in those accounts by '/bin/false' in /etc/passwd).
Create regular users for normal system administration. Abusing the root account for system administration is not only dangerous but also silly: root mistakes can be very expensive (root can wipe out the whole filesystem with a simple command).
Install and configure sudo. If you need to run anything as root, just precede the command by 'sudo'. It has the double advantage of making you conscious of running that command as root, and also keeping track (audit trail) of which commands are run as root and by whom.
# Disable unnecesary daemons and network services
Run a 'ps -ax' and review each line. Think if you really need that daemon. If you don't, remove it from the startup scripts and kill it.
Run a 'netstat -anp' and see which applications are listening to network ports. Disable all network services that you won't use.
# Disable remote root logins over ssh
Edit the sshd configuration file (usually /etc/ssh/sshd_config). Make sure that the line 'PermitRootLogin no' is present and not commented out. Anyway, you will always login as yourself and use sudo to run commands as root, won't you?.
# Set up and enable iptables
Configure and enable iptables with a deny by default policy for incoming and outgoing traffic. These are the basic rules that you should have for a web server running on port 80 (use it as a guideline, don't copy it literally):
iptables -P INPUT DROP
iptables -P OUTPUT DROP
iptables -A OUTPUT -i lo -j ACCEPT #accept internal connections
iptables -A OUTPUT -d your_dns_server -p udp—dport 53 -j ACCEPT #DNS/UDP
iptables -A OUTPUT -d your_dns_server -p tcp—dport 53 -j ACCEPT #DNS/TCP
iptables -A OUTPUT —state ESTABLISHED, RELATED -j ACCEPT #established and related connections
iptables -A INPUT -i lo -j ACCEPT #accept internal connections
iptables -A INPUT -p tcp—dport 80 -j ACCEPT #HTTP on port 80
iptables -A INPUT -s your_administration_box -p tcp—dport 22 -j ACCEPT #ssh from your administration workstation
iptables -A INPUT -m state—state ESTABLISHED, RELATED -j ACCEPT #established and related connections
You may need extra rules if you are sending your logs somewhere else (a very good idea as nobody will be able to alter the logs, even if the server gets compromised).
An outgoing deny by default policy is almost as important as an incoming deny by default policy. The least thing that you want is to let a hacker use your compromised server as a jumpbox to attack something else. And he will be already inside your network.
# Configure security related kernel parameters
Enable syncookies, disable responses for pings to the broadcast, enable ip spoof protection, disable ICMP redirects and disable source routing. You can do so by adding the following lines to /etc/sysctl.conf
net.ipv4.tcp_syncookies = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
# Install a host based Intrusion Detection System (HIDS)
If you can afford the effort of walking the extra mile, install an HIDS system. A well known one is Samhain.
Or at least use an integrity verification system like AIDE or Tripwire™ .
But if you feel really corageous, you could improve general Operating System security with Role Based Access Control and multilevel security (as in SELinux or in grsecurity ), but both of these will require kernel patches and substantial modifications to the system.
# Apply the latest updates
Unless you are installing the latest version of a distribution that just came out yesterday (and I would recommend at least waiting a few weeks before installing a new version of any distribution), there are most likely updates available to some of the packages that you've just installed. So review the fixes and the caveats, and apply them. And familiarize yourself with this process because you'll be doing this for the entire life of this server.

Gullible Jones · 2006-05-16 19:23:59

Thanks, I am really going to have to try that stuff.

Mr Green · 2006-05-16 20:33:27

emmm very nice

sweiss · 2006-05-20 08:51:53

I've probably the least secure system around. It's running SSH, FTP and HTTP. It doesn't have any firewall since it is connected to the internet through a firewalled W2K machine. The only protection it has is a perl script which blacklists users who try to SSH with bad login details.

Gullible Jones · 2006-05-20 09:21:52

Connected through a firewalled Win2K machine? I wouldn't trust that as far as I could throw it... :shock:

Pick2 · 2006-05-20 16:36:28

I have come up with the Perfect Protection Method (tm) for my computer !
I have since turned off all my firewalls and opened all my router ports to the intra web !
Cyber Crime has decreased globally by 5% in the last week of it's operation !
the way it works is this:
the first thing they get when they try to intrude is a Naked picture of My Wife ! :shock:
That will Blind them for Days , and they wont get near a computer for weeks afterwards without uncontrollably shaking and blackout spells !

Arch Linux

#1 2006-05-15 17:24:28

Is it safe?

#2 2006-05-15 17:49:32

Re: Is it safe?

#3 2006-05-15 19:11:03

Re: Is it safe?

#4 2006-05-15 19:16:28

Re: Is it safe?

#5 2006-05-15 19:44:15

Re: Is it safe?

#6 2006-05-15 19:51:19

Re: Is it safe?

#7 2006-05-15 20:07:23

Re: Is it safe?

#8 2006-05-15 20:10:55

Re: Is it safe?

#9 2006-05-15 21:26:35

Re: Is it safe?

#10 2006-05-15 22:27:30

Re: Is it safe?

#11 2006-05-15 22:34:15

Re: Is it safe?

#12 2006-05-15 23:49:26

Re: Is it safe?

#13 2006-05-16 01:34:04

Re: Is it safe?

#14 2006-05-16 02:59:44

Re: Is it safe?

#15 2006-05-16 07:48:03

Re: Is it safe?

#16 2006-05-16 10:58:49

Re: Is it safe?

#17 2006-05-16 11:24:08

Re: Is it safe?

#18 2006-05-16 11:46:44

Re: Is it safe?

#19 2006-05-16 13:23:28

Re: Is it safe?

#20 2006-05-16 19:23:59

Re: Is it safe?

#21 2006-05-16 20:33:27

Re: Is it safe?

#22 2006-05-20 08:51:53

Re: Is it safe?

#23 2006-05-20 09:21:52

Re: Is it safe?

#24 2006-05-20 16:36:28

Re: Is it safe?

Board footer