The paranoid #! Security Guide

http://crunchbang.org/forums/viewtopic.php?id=24722

by lampe3 • 13 years ago

164 51 13 years ago

crunchbang.org

MoreConsiderate• 13 years ago

"Now why was this planted in front of me..."

jjoergensen• 13 years ago

Interesting talk that was linked to from the guide http://www.youtube.com/watch?v=HHoJ9pQ0cn8

teddyh• 13 years ago

Personally, I prefer the Securing Debian Manual http://www.debian.org/doc/manuals/securing-debian-howto/

Nitpick; "shred" is a better alternative to "srm", since "shred" is always installed.

pwelch• 13 years ago

Does shred work with SSD drives?

pyre4• 13 years ago

Does srm? My understanding is that you can't really do this with SSD drives because even writing to the same file, the underlying location of the data may change due to the internal wear-leveling mechanisms. There is no way to guarantee that you are overwriting the same physical 'block' of data on the hardware.

krenoten• 13 years ago

srm and shred are both filesystem and hardware dependent, and are likely not to actually overwrite the original bits on disk for many common setups these days. Never write anything raw to disk that could complicate your life if it were disclosed to the entire world somehow.

jerrya• 13 years ago

Is there anything like this guide specific to securing "modern cloud machines" eg. the variety of Amazon AMIs?

pavs2• 13 years ago

I think its very difficult, if not impossible to have "paranoid level" security for a machine that someone else has full physical access. The assumption here is that amazon also have paranoid level security and their employees are 100% honest and will do nothing to compromise your machine.

sweis• 13 years ago

I am working on securing virtual machines against physical attacks (which yes, does sound impossible). Our approach requires code changes on the hypervisor level, which currently rules outs Amazon but is viable for bare-metal cloud providers. It also requires some specific CPU features and a TPM.

alexwright• 13 years ago

The assumption here is that Amazon also have paranoid level security and their employees are 100% honest..

Add 100% competent to that too. I expect a bug is much more likely that a dishonest sysadmin or dev.

gnosis3• 13 years ago

Would anyone here have any idea why "net.ipv4.tcp_timestamps=0" is recommended as a security enhancement?

Spittie• 13 years ago

From what I've read online, it should be possible to estimate the uptime of your machine with TCP timestamps.

I'm not sure why this would be a problem, maybe an attacker can see that you haven't rebooted to install a kernel update?

gnosis3• 13 years ago

Ah, interesting. I think I recall reading that attacks against crypto can be helped by uptime estimates.

Uptime can be used as a source of "randomness" in PRNGs, so knowing that bit of information could clearly be beneficial to an attacker.

drKarl2• 13 years ago

I was wondering... would using a different keyboard layout like Colemak or Dvorak defeat keyloggers? I mean, what does keyloggers capture, the interrupts of the keyboard or the keystrokes? Would it get the keys pressed on the keyboard even if those translate to different keys on the keyboard layout or they would capture the keys as if using Qwerty, so the passwords captured would be different?

venomsnake• 13 years ago

It won't because by the non password text entered I will be able to derive the layout and have good aproximation of the layout used.

drKarl2• 13 years ago

Good catch

unimpressive• 13 years ago

Even if you only had the text of the password, one of the first things that you'd try if your keylogged password didn't work would be to see if the characters map to a different layout. (There are only so many after all.)

If you want an excuse to try switching to Dvoraks, how about not having the semicolon on the home row?

daviddede• 13 years ago

Why people still recommend chkrootkit? It is an old tool that havent't been updated in a long while and wont find any new linux rootkits/malware.

pavs2• 13 years ago

How is rkhunter?

nisa• 13 years ago

Out of the box it's probably useless but if you spend some time to configure rkhunter it can be a worthwhile help in finding malware. But for anything that goes beyond script-kiddie attempts I'd not count on it.

- It can verify hashes using the package manager.

- It can report use of deleted files. After clearing the false-positives this can help to detect some malware that is only in memory and already deleted on disk

- Support for unhide¹ - This should help against rootkits - but I'm not sure how reliable it is nowadays

1: http://www.unhide-forensics.info/

Nux• 13 years ago

If you're running a web server then "maldet"[1] is a must, maybe in combination with ClamAV (clamscan).

It's insanely useful especially on "shared" web servers; much more so than chkrootkit or rkhunter.

[1] http://www.rfxn.com/projects/linux-malware-detect/

tehwalrus2• 13 years ago

This guy references a very very long video about "why you shouldn't use TrueCrypt hidden volumes" - the relevant question and answer is about an hour in (57 mins will do it) - http://www.youtube.com/watch?v=HHoJ9pQ0cn8&t=57m

autodidakto3• 13 years ago

TLDW: Appelbaum believes it's better to defend your fifth amendment right than to lie (EFF agrees, Assange doesn't). And in areas of zero freedom, it's better to have the ability to give up your password (plausible confession -- my term) than to have the adversary believe that there's a hidden volume they haven't beat out of you yet.

There's more to this long running debate, but that's the gist of Appelbaum's position.

My take: Plausible deniability gives you the option to defend the fifth, lie, or give up your data, but your confession may never be plausible. Which is better depends on the sensitivity of your data and the willingness of your adversary.

irahul• 13 years ago

. And in torture friendly areas, it's better to have the option to give up your password and be killed quickly than to have the adversary believe that there's a hidden volume they haven't beat out of you yet.

How will giving up the password ensure there isn't 'another' hidden volume?

andrewcooke2• 13 years ago

how does this change if you're not american (no fifth, presumably)? or entering the uk (where not giving up the password is a crime)?

gnosis3• 13 years ago

To call this a "a very very long video about "why you shouldn't use TrueCrypt hidden volumes"" is not accurate and does not do justice to a very interesting talk.

First, Part 1 is only 1 hour and 17 minutes long (though perhaps it felt much longer to you).

Second, while the subject of TrueCrypt comes up a couple of times in the Q&A period, it's not the main subject of the talk. The talk is about privacy, anonymity, surveillance, and what can be done about them.

I highly recommend watching this video, especially for people who might not be up to date on all the latest privacy-enhancing technology or who might not be very aware of how much digital surveillance there is these days. Even if you do know about these things, it's still interesting to hear an intelligent, articulate presentation about them.

mpyne• 13 years ago

First, Part 1 is only 1 hour and 17 minutes long

There is no such thing IMO as only 1:17 when referring to a presentation/talk. I tune out after about 10 minutes, 15 or so tops (e.g. for the git imerge discussion).

Anything that is so complicated that it requires that much exposition is something that I will read about or probably not find out at all.

tehwalrus2• 13 years ago

I agree - the article refers to it as such (or rather, says "if you want to know why you shouldn't use hidden volumes, watch this", which is crazy - I sat through an hour of obvious stuff for the one argument I wanted to hear! :/

thex86• 13 years ago

TrueCrypt. The most shady piece of security software I have seen. It's 2013 and there is still no public repository and no changelogs are published. Don't you expect the software you will trust all your secrets with to be at least open about these things?

People keep on saying Schneier says it's good, did he actually check each and every line of the source code? Not to mention that I read somewhere that they ban you on their forums if you ask them these questions.

Let's see the ChangeLog:

"Improvements and bug fixes:

Minor improvements and bug fixes (Windows, Mac OS X, and Linux"

Minor improvements and bug fixes :) This is how you write your ChangeLog friends!

dmix• 13 years ago

LUKS/dmcrypt is an excellent fully open source alternative to Truecrypt.

http://code.google.com/p/cryptsetup/

npsimons2• 13 years ago

Exactly; I don't see why people have such a hard-on for TrueCrypt when you get LUKS out of the box on a Debian install. It's a no-brainer.

andrewcooke2• 13 years ago

it doesn't support hidden volumes (deniable).

schrodingersCat• 13 years ago

Anyone had luck compiling this on OSX?

pyre4• 13 years ago

If the NSA has the ability to break into TrueCrypt drives, then they aren't going to tip their hat on the matter, even in the case of child pornographers. They would probably only be willing to let that information out for very high value targets, because in the meantime, people are still using it and they can still get access to it. If people know that the NSA (or whomever) can get into TrueCrypt volumes, then they stop using it.

localhorse• 13 years ago

Do they need to tip their hats, even when dealing with "high value" targets? Once you've found what you're looking for, you could easily find other damning information that could have plausibly come from somewhere else, no?

noinsight• 13 years ago

There's another implementation for TrueCrypt these days, tc-play, https://github.com/bwalex/tc-play that looks promising.

autodidakto3• 13 years ago

DragonflyBSD is impressive and is trying to improve on modern OSes (See HAMMER filesystem). I hope tc-play becomes crossplatform.

imperialWicket• 13 years ago

There are some good notes here, but they're relatively desktop oriented. For the truly paranoid desktop user https://tails.boum.org/ accomplishes much of this out of the box.

autodidakto3• 13 years ago

Alternatively, there's Whonix (https://whonix.org/wiki/Main_Page). More steps but potentially more secure. Major difference is that whonix runs in a VM (or two), is persisted (though you could use VM snapshots), and the tor proxy setup is safer (thanks to security-by-isolation and tor socks, no app can figure out the host's ip nor connect directly to the net).

Qubes OS is a new xen based OS that takes security by isolation to a new level. Still young but I'm keeping my eye on it.

The article just convinces me of the need for highly tested/developed security focused distros. There are so many ways to screw up.

D9u• 13 years ago

I was surprised to see that you were the first one to mention Virtual Machines in these comments.

I would use a VM on a "live" system, booted from removable media, to which no data is ever written. (DVD)

But it wouldn't be any Linux distro.

BSD is what I prefer. Take your pick of the available options, NetBSD, OpenBSD, FreeBSD, *BSD.

ikt• 13 years ago

Can't help but think of: http://xkcd.com/538/

sorry

gits1225• 13 years ago

Also, The CryptoParty Handbook: http://www.cryptoparty.in/documentation/handbook

lvh• 13 years ago

Why do they try to give me a bunch of (ostensibly unsigned) SHA sums over an insecure, unencrypted medium? Surely anyone who could modify the content could also just as easily modify the checksum.

zokier• 13 years ago

https://twopointfouristan.wordpress.com/2011/04/17/pwning-pa...

This post linked from TFA is pretty good justification for SecureBoot, even if the protection provided by SB as it's implemented now can be bit questionable.

gregd• 13 years ago

Avast doesn't like a png file being served on this site. Specifically:

http:// ompldr.org / vaG5mcQ / sudoaptgetinstallmthrfckr-610x250.png

click at your own risk..

The paranoid #! Security Guide

Related Stories