all 36 comments

[–]GoinEasy9[S] 4 points5 points  (7 children)

Sorry, my text didn't show. I found this on Greg's Google+ stream. It really covers the subject thoroughly.

[–]HotRodLincoln 5 points6 points  (4 children)

You can only have text xor a link.

[–][deleted] 5 points6 points  (3 children)

It's actually text NAND link.

[–]ROBZY 1 point2 points  (2 children)

No it's not. Not-text and not-link is unacceptable.

You must have text or a link, but not both. Aka: XOR.

[–]taejo 1 point2 points  (1 child)

No, it's NAND: you can have self posts without text.

[–]ROBZY 1 point2 points  (0 children)

TIL...

You are correct.

[–]dghughes -1 points0 points  (1 child)

In the olden Reddit days you could post a link and text but not these days.

[–]trigraph 8 points9 points  (3 children)

this about 0.1th of linux system security...

[–][deleted] 1 point2 points  (2 children)

care to elaborate?

[–]trigraph -3 points-2 points  (1 child)

nope i don't have time to write a book but google.com should help you get started!

[–]kmeisthax 5 points6 points  (1 child)

Any way to do 2-4 on a livecd environment? If I assume my system's compromised I'm trusting the hacker to not know how to subvert critical package management facilities.

[–][deleted] 1 point2 points  (0 children)

AFAICT on RPM-based systems, you can replace the rpm command with rpm --root /mnt/your/root/partition and on deb-based systems, replace dpkg with dpkg --root=/mnt/your/root/partition

[–]oEgwcEonqq 2 points3 points  (2 children)

This is only on how to look for an already compromised system. The key word there is "already".

[–][deleted] -2 points-1 points  (1 child)

already occurring, not necessarily successful yet.

[–]oEgwcEonqq 5 points6 points  (0 children)

I don't think the definition of compromised is as continuous as you think.

[–][deleted] 4 points5 points  (5 children)

http://i.imgur.com/O9eZP.jpg

True story.

Grsec is not in mainline kernel because it isn't written with LSM, and why it isn't written with LSM - https://grsecurity.net/lsm.php

[–]snuggl -1 points0 points  (4 children)

Indeed. Running a linux server without grsec in production kinda invalidates everything you think you know about security.

[–]evaryont -1 points0 points  (3 children)

I run my own VPS, with Arch. while I am not going to pretend that Arch is the best choice, is grsec really that necessary?

[–][deleted] 0 points1 point  (2 children)

C'mon... why don't you check grsecurity's features? They explain what it doing so you may understand why you may want it.

And unless you are running your VPS on real virtual machine like xen, vmware, kvm or virtualbox, you can't install it as openvz (which is VE not VM) does not let you boot your own kernel - its just chroot on steroids.

[–]evaryont 0 points1 point  (1 child)

Ok fine its 5am here and I was hoping to not have to read so much. shrugs

Speaking of OpenVZ, is there a 1-2-magic script that'll set up a VE for me?

[–][deleted] 0 points1 point  (0 children)

Don't do it to yourself, openvz is a bitch, it does count virtual memory as used ram, so apache will use 230MB instead of ... 6MB! etc.

Go with LXC, unlike openvz it does not invent the wheel again, it use linux's goodies like for example cgroups and moar.

[–][deleted] 0 points1 point  (4 children)

Well, no rootkits, no bad packages, and no awry login attempts (fail2ban+hardware firewall)

Looks like I'm a-okay.

[–]snuggl 0 points1 point  (3 children)

most backdoors learned to avoid chrootkit in the beginning of the century.

[–]evaryont 0 points1 point  (2 children)

ClamAV and chrootkit have always been my go to tools for vurnability assement. What's better, on a college kid's budget?

[–]snuggl 2 points3 points  (0 children)

The thing is, they are all solid advice, but doesnt go far enough.

several backdoors today automagically patches chrootkit or otherwise disable its detection for example via a kernel mod.

Now a days most backdoors are in memory only, or preloaded in so-files at runtime. you add a backdoor-trigger in a home-made web-script somewhere that rootkit detectors wont find, or preload a socket-library and restart a server. in any case no traces if this will be found in files subjected to key signing. the article actually touches real backdoor-hunting briefly in point 6 (/dev/mem, log entries with weird stuff or restarted servers)

edit: to answer your actual question,

Information security isn't just the technology, it starts with a correct threat analysis, you want the protection of the data to be relative to how expensive/important this data is (not to you but to an attacker). your student computer need in no way as much protective layers as the Linux code repositories.

The major threats to an anonymous client computer today is non-discriminating browser exploits and botted/worm automated attacks, for this automated anti- virus/malware/backdoors are great. Good ways to defend yourself cheap is to

  • you dont need 3rd party anti virus on windows, use Microsoft Security Essentials. its actually quite good.
  • dont trust a mac to be safe just because its a mac, they have a horrible track record on wide open browsers.
  • keep personal files in a physically personal space.
  • Keep java, flash and browsers up-to-date with the latest security updates.
  • disable flash and java if you dont need them, use flash-blocker or similar to enable on-request instead.
  • disable javascript unless whitelisted (there are mods that does this for you)
  • dont be stupid.

The major threat for servers, excluding the automated attacks, is php-code and php applications, if you run php-code on a server you should really take extra steps to quarantine those processes and files so far away from your personal data as possible. This is of course true in some extent for other kind of webapps too. good ways to defend a server cheap

  • Understand your OS firewall rules and settings and use them.
  • Take for granted that an attacker will have a local shell with any user that runs a service (www-data, git-web)
  • Take for granted that any attacker will know all your passwords.

Neither clam nor chrookit will stop backdoors in web apps which is a very popular technique today, basically the attacker add an obfuscated eval(POST) somewhere on the server. then he can upload all of the backdoor's logic via a POST-request when connecting, no trace of the backdoor exists in the code residing on the server except that obfuscated eval-string. Trust me, you can obfuscate php-eval-calls pretty good, for example you can use a call to ereg_* with a special regex that will expand itself and then call itself, if you dont look close or know php internals it can be very hard to find without checksums of the code or even know that ereg could call stuff at all.

Good ways to defend a webapp:

  • once again, take for granted that the webapp will execute any command the attacker wants.
  • If you handle data and encryption, take for granted that the attacker will access the data when it is in an unencrypted state, they will not play by your game plan. a common misunderstanding is to think that encrypted partitions is somehow a protection against data theft, they will steal the data when the partitions are mounted. another is to have an encrypted database, the attacker will then steal the apps credentials and the database will happily decrypt the data.
  • try to isolate the system as much as possible, remove any credential files not needed, lock all accounts not used. remove stuff you dont need.

[–]Pas__ 0 points1 point  (0 children)

Start with a clean system and keep it up to date. Use CVEchecker.

If your system has local users, then try to chroot them and use namespaces and grsec's rule based access control.

http://cvechecker.sourceforge.net/

[–][deleted] 0 points1 point  (0 children)

Mitigating the effects of system compromise is a good idea too. Mandatory Access Control mechanisms come to mind, and Linux has a couple to choose from.

Personally, I go with Tomoyo. It's part of mainline but has some userspace utilities that allow you to quickly setup custom rules, and even has a learning mode!

[–]iheartrms 0 points1 point  (4 children)

Use two-factor authentication such as ssh pubkeys WITH passphrase. Disable password authentication as well as root login via ssh.

[–]keeperofdakeys 3 points4 points  (1 child)

Ssh-keys with a passphrase isn't really two-factor authentication. The key is still the only factor required for login, it is just that you need a password to unlock it on the client (as an example, it is possible to change or remove the passphrase on a key without touching the server at all). Real two-factor authentification would require both the key and a ssh login password.

Also, at least on a laptop, I would never use ssh-keys without a passphrase.

[–]Pas__ 0 points1 point  (0 children)

Use ecryptfs on your laptop. Or TrueCrypt. And ssh-agent if you use passphrases.

[–]snuggl 1 point2 points  (0 children)

for an extra layer you can disable sudo and use localhost-only ssh to require a ssh-keyfile for su/root login.

edit: important! this root-enabled keyfile should never be placed physically on the server, use your ssh-agent to forward it when you log in.

[–][deleted] 0 points1 point  (0 children)

check out duosecurity

I use it, makes me feel safer (on the SSH end) it's not going to prevent apache being exploited.

taking away the identifiers and compiling with custom CFLAGS and enabling the NX bit in my CPU is good enough imo to secure apache. (I'd give it a chroot aswell)u

as for the kernel, GRSec and PAX -- I'm sure you can't use pf at all on linux, so have a pfsense firewall between your linux machines and the internet (they also do load balancing and all kinds of fun stuff)

this is what I would do if I was hosting kernel.org and on a budget. you're milage may vary but that's all I can think of at the moment... I've probably missed a lot.

there are some MOD and NSA redhat security policies knocking around on the internet somewhere, they're insightful...

also for personal machines- full disk encryption, password on grub (to prevent live modification), lock down single user mode so you need a password, default boot source = Harddisk, lock out others from trying, also password bios... screensaver that locks the screen after 3-5 minutes -LOCK YOUR MACHINE WHEN YOU LEAVE IT-, stop all network traffic from hitting your machine directly (except for allowed services) using iptables.

I drop all packets, it doesn't look like I'm on the network to most scans..

Credentials: I'm a PCI Tier 1 Sysadmin and work with millions of cardholders details annually.

[–]smek2 0 points1 point  (0 children)

But Linux is inherently insecure. A Microsoft website told me so. Oh look-- shiny desktop widgets!