Paranoid Security

tomfitzyuk · 2006-08-11 21:08:47

Hey,

I've been thinking of what it would take to make a really secure system, here's some ideas I've been thinking about.

Note: I've not used/tested most of these so unless you totally know what you're doing, I don't recommended you try them.

Also, I know a lot of these tips are not very feasible, but I'm talking about really secure.

/home, /var, /tmp mounted as noexec; all other root directories mounted as read-only
This means the only place a user (be that an intruder or not)
can write to, are the directories which you cannot execute files from. /home, /var and /tmp are not mounted as read-only for obvious reasons. Now, I assume this means that it will be impossible to plant executable files on the system and get them to run, unless the intruder is able to remount the partitions with whatever options he wants, which he'd need root access for...

Strong passwords
This is a no brainer but it must be mentioned. The only way to get root access remotely is by using either logging in or sudo so strong passwords are a must.

Encrypt all partitions
If an intruder does manage to get root access and wants to write to, say, /bin, he will have to unmount it first. Now, when he comes to remount it without read-only defined, he won't be able to since the partition is encrypted. It may be impossible to boot from an encrypted partition (i.e. encrypting /boot would be a bad idea).

Store /boot on a CD-R
Now /boot is on read-only media. Remotely, it would be impossible to write to the kernel (and they couldn't write to / to create a new /boot since it's either encrypted and unmounted or mounted as read-only). Locally, the user/intruder could use his/her own CD-R with their own kernel (which would be dangerous if it had keylogging modules which could log the passwords for the encrypted partitions), which leads to...

Perform a checksum on the boot CD-R
This will make sure the CD in the drive is the one you intended (meaning you would load the kernel you intended to load). Of course, if a collision is able to be generated (i.e. a modified kernel of the intruders such that their own CD-R has the same checksum as your CD) then we're in trouble. However this is very unlikely... to be found.

I'm not sure if it's possible to checksum a file (or CD-R, whatever) upon booting... that would be one limitation.

Secure BIOS
Set the first boot media to HDD (or CD if you're the ultra-paranoid type) and disable the rest. Make sure you put a password on the BIOS setup; also, you could even put a password on booting if your BIOS features it.

Now for more general tips:
Create a seperate user for each service
This is recommended since if one service is compromised in a way such that its owner is compromised, all services owned by that user are at risk. It's best to create seperates users for each service as to isolate the damage if a service is compromised. Also, having no login shells for services is usually a good idea.

Finally:

· Always keep packages up-to-date;
· Read security bulletins;
· Use intrusion detection;
· Configure all services to sensible settings for your needs;
· Regularly run tripwire to make sure no files have been compromised.

How to update
Using pacman, download the packages which need updating. Reboot and boot into single-user mode (this could be done by using an alternative kernel, or at least a kernel with different boot options such that you can write to /usr). Add the new packages. Reboot. Sorted

What do you all think?

Thanks,
tomfitzyuk

phrakture · 2006-08-11 21:21:34

tomfitzyuk wrote:

I've been thinking of what it would take to make a really secure system, here's some ideas I've been thinking about.

It'll never happen. Here's the steps to make a secure system.

1) Find ethernet cable
2) Unplug it
3) Lock physical box in a closet
4) Throw the key away

pauldonnelly · 2006-08-11 21:37:51

It sounds pretty solid from here, but I'm no expert.

I'd also add: be very careful about which network services you provide. I.e. if you're running sshd, configure it so that it's only possible to log in one way. SSH version 2 only, no password logins (keys only), and so on. Or whatever fits your setup. I guess this is the same as "configure to sensible settings for your needs," but more explicit.

Also, be sure to tell Pacman which config files shoud *not* be upgraded. All the clever settings in the world are useless if they change behind your back. Would Tripwire catch this? I'm not familiar with it.

bboozzoo · 2006-08-11 22:13:49

set default umask to 077 (this will break a lot of stuff), chmod -x on unneeded shared libs, audit cron stuff, check which log do need to be accessible by others and which do not.. etc.. lots that you can do without going to extremes like the CDR + boot idea

allucid · 2006-08-12 00:45:18

phrakture wrote:

tomfitzyuk wrote:
I've been thinking of what it would take to make a really secure system, here's some ideas I've been thinking about.
It'll never happen. Here's the steps to make a secure system.
1) Find ethernet cable
2) Unplug it
3) Lock physical box in a closet
4) Throw the key away

He said really secure, not unconditionally secure.

headhunter · 2006-08-12 12:41:33

One could also install SELinux or AppGuard from Novell to increase security alot.

palandir · 2006-08-12 18:56:42

bboozzoo wrote:

set default umask to 077 (this will break a lot of stuff)

For example? I've used 077 for a while and didn't notice anything going wrong. On my normal user account of course. Using it as root is a bad idea when you install software that should be usable by other users too.

The Debian Security manual has lots of advice, it's a very good read, and mostly distribution-independent.

bboozzoo · 2006-08-12 21:22:55

palandir wrote:

bboozzoo wrote:
set default umask to 077 (this will break a lot of stuff)
For example? I've used 077 for a while and didn't notice anything going wrong. On my normal user account of course. Using it as root is a bad idea when you install software that should be usable by other users too.

The Debian Security manual has lots of advice, it's a very good read, and mostly distribution-independent.

This would mean that you have badly configured system and most services are run using the same uid. System which I work on usually haeve separate users for each larger software package installed. Umask 077 usually breaks stuff like Oracle and software wchich dynamically links with Oracle libraries, but run from user other than ``oracle''. Anyways 077 is just the beginning most admins end up having a bunch of scripts to secure each machine.

1c3d0g · 2006-08-12 22:44:04

phrakture wrote:

tomfitzyuk wrote:
I've been thinking of what it would take to make a really secure system, here's some ideas I've been thinking about.
It'll never happen. Here's the steps to make a secure system.
1) Find ethernet cable
2) Unplug it
3) Lock physical box in a closet
4) Throw the key away

Best.Security.Ever.

Another way would be to use one PC for Internet access etc. only, and use another "standalone" PC for storing your data.

palandir · 2006-08-12 23:16:20

bboozzoo wrote:

palandir wrote:
bboozzoo wrote:
set default umask to 077 (this will break a lot of stuff)
For example? I've used 077 for a while and didn't notice anything going wrong. On my normal user account of course. Using it as root is a bad idea when you install software that should be usable by other users too.

The Debian Security manual has lots of advice, it's a very good read, and mostly distribution-independent.
This would mean that you have badly configured system and most services are run using the same uid. System which I work on usually haeve separate users for each larger software package installed. Umask 077 usually breaks stuff like Oracle and software wchich dynamically links with Oracle libraries, but run from user other than ``oracle''. Anyways 077 is just the beginning most admins end up having a bunch of scripts to secure each machine.

I just had it for my user account. So anything else wasn't affected, just the files I created. root and other users (for services) had the default of 022.

user · 2006-08-14 12:43:08

make your linux open, remove private or privacy information that hurt you.

if it done, then use firewall for your linux.

jerem · 2006-08-14 22:44:31

As far as *paranoid* security is concerned,
I like to use some kind of Mandatory Access Control, as well as some anti-stack-smashing technology...

But I also think that ultimate security can only be reached with serious code auditing, like the OpenBSD people do.
After all, even a MAC system can have bugs...

Gullible Jones · 2006-08-15 01:01:39

There's also RBAC, which is technically different. BTW, Arch Linux has SSP thanks to GCC 4.1.

Strong passwords
This is a no brainer but it must be mentioned. The only way to get root access remotely is by using either logging in or sudo so strong passwords are a must.

Someone can get root access remotely by exploiting a hole in an application that is running as root - for example, Xorg. In some cases it is possible to gain such priveleges via a non-root application, as a certain Marcus Hess (a.k.a. "jaeger") did - though that was on UNIX, and I'm a bit hazy on the details.

user · 2006-08-15 01:06:46

about RBAC,

http://www.grsecurity.net/

Latest Version:
2.1.9
Latest update: 08/13/06

PS: oh i almost forgot this, if someone bugging you, who think knew everything about tcp/ip packet AND IF your ip is not belong to private network,
http://tor.eff.org

PPS: tor-based safe chat
http://www.scatterchat.com/

Gullible Jones · 2006-08-15 01:30:59

There's also RSBAC. FWIW, neither are in the main kernel tree because of portability issues (extremely severe ones in the case of GrSecurity, apparently).

Also, Tor is available in the Extra repo (and yes, it's up to date).

bboozzoo · 2006-08-15 07:51:07

There was a project once, hopefully it's still alive, http://www.bastille-linux.org/ has anyone tried it?

Gullible Jones · 2006-08-15 14:55:15

I made a PKGBUILD of it at one point but it got deleted... I guess I'll try again at some point. If it works well I'll submit it to the AUR.

Arch Linux

#1 2006-08-11 21:08:47

Paranoid Security

#2 2006-08-11 21:21:34

Re: Paranoid Security

#3 2006-08-11 21:37:51

Re: Paranoid Security

#4 2006-08-11 22:13:49

Re: Paranoid Security

#5 2006-08-12 00:45:18

Re: Paranoid Security

#6 2006-08-12 12:41:33

Re: Paranoid Security

#7 2006-08-12 18:56:42

Re: Paranoid Security

#8 2006-08-12 21:22:55

Re: Paranoid Security

#9 2006-08-12 22:44:04

Re: Paranoid Security

#10 2006-08-12 23:16:20

Re: Paranoid Security

#11 2006-08-14 12:43:08

Re: Paranoid Security

#12 2006-08-14 22:44:31

Re: Paranoid Security

#13 2006-08-15 01:01:39

Re: Paranoid Security

#14 2006-08-15 01:06:46

Re: Paranoid Security

#15 2006-08-15 01:30:59

Re: Paranoid Security

#16 2006-08-15 07:51:07

Re: Paranoid Security

#17 2006-08-15 14:55:15

Re: Paranoid Security

Board footer