Hot answers tagged

92

Use a strong and difficult password for the root user. Secondly, always login and work from another user with no administrative rights (also strong password). Enable the BIOS password option. Every time you power on your computer, the bios itself will ask you for a password before even booting on. It will also prevent everyone from applying changes to the ...


89

You could write some Python code to upload an SSH server binary and then run it, this will give you full SSH access under the privileges of the Apache user. From there you can easily read the Python app's config files and connect to the database using the credentials from there, which will allow you to grab confidential data (no exploits needed here as the ...


84

I hate to be this guy, but Law 3: If a bad guy has unrestricted physical access to your computer, it’s not your computer anymore. You are asking how to best lock a plywood door. People are giving you very good suggestions for locks, but none of them matter since your system is physically vulnerable and your attackers are competent. They will just ...


65

Depending on the performance you require and money you are willing to expend, a removable "Live USB" or completely bootable normal system on a USB "hard drive" (a small ssd would work great) might be an ideal solution considering your "unique" constraints of needing high security against local attackers. It would allow you to just leave the compromised ...


20

Here is an all inclusive solution since you stated you were not worried about hardware/USB/physical attacks. Install Virtualbox/VMWare/Other on your desktop. Go about creating your guest and put that guest on a removable USB key. When you're done with your work, power off the virtual machine, remove the key, and it's a wrap. There are plenty of other ...


20

There's some things to consider that differ from all the answers previously given: what you're looking for is privacy, not security. While they seem very similar, the goals of each are different, and the ways to implement each are different. If you were looking to implement security, you would remove other users' admin access, lock down each users' ...


17

It certainly does. gdb will not isolate the process at all and will merely give you some control over it to understand what it does. To do that kind of analysis, you should resort to a fully isolated system such as a VM with no network access. Break points will be respected, but you should always account for human errors which can have drastic ...


12

I like the answers that suggest you run Linux from removable media. It hides the fact that you're taking precautions from your not-so-nice house mates. There's a few problems with it, though, from a practical standpoint. You're sacrificing drive speed and space, but what's more important is that carrying your whole operating system around with you is ...


10

You can not secure the system under the conditions in your question. No matter what, with physical access to your machine there is no security. With the exception of the bios password every counter measure on this page could be circumvented by booting into rescue mode (in one form or another). The BIOS password is easy to reset. It's usually a jumper or ...


9

Just buy a notebook and carry it around with you. If you don't want other people to check your data, don't leave your data near them. If any part of your machine is compromised, everything on your machine is compromised. Hacking hardware is not necessarily expensive and you don't really know how far would this person go to get access to your data. The ...


8

Not sure why nobody has mentioned this yet (maybe I don't understand the site that well). Put a camera in your room (one WITHOUT wifi capabilities). Get your linux system set up, casually mention it to your housemates in passing conversation. Record them breaking into your personal computer and reading your information. Have them arrested and fined, use the ...


5

I would get two USB sticks. The first would have the capability to be set as read-only at the hardware level with password protection, and the second would be either a normal stick or a PIN-enabled stick (but these tend to self-destruct if the wrong PIN is entered a few times, so beware...). Install your operating system on to the first stick, and configure ...


5

Wiping the LUKS header would make the data completely irrecoverable, even if the password/encryption key is later discovered, since the passwords/keys used by LUKS merely encrypt a master key stored in the header and that master key actually encrypts the data. So first, deleting the first 2MBs of the device where the LUKS volume resides should make further ...


5

If your server has been compromised, then assume they have root access. Even if it appears that you removed offending shell scripts (which a lot of times is all the "clean up" entails), it's entirely possible for them to dig deeper into the system. You have no idea what exploits exist for the server software, so it's entirely possible that uploading a simple ...


4

To expand on @tlng05's point, rootkit authors are professionals, often with decades of experience. Unless you have decades of experience fighting rootkits, then they'll know about more hiding places than you do :P If you suspect there's a rootkit, then your only choice is to wipe the system. This is a classic example of Ken Thompson's reflection on ...


4

I think that having sensitive data (whether it is the password, or derived key, etc) in memory is not something that most systems deal with. That being said, here are several possible mitigation methods for protecting private data in-memory. This could apply to a variety of subjects, Server, Mobile or Desktop. The principals are the same. I'm also not sure ...


4

This would be my plan of action: Lock down the BIOS by adding a BIOS password to the setup. I would not add a startup password to allow users to use the computer without my supervision. Disable automatic booting from USB, CD and network. Force boot from USB/CD and install Linux with an encrypted home folder and encrypted swap on the hard disk. If possible, ...


3

Other folks had some great ideas. I didn't read down to determine whether or not this was already mentioned, so I apologize if it has been. I know you mentioned you cannot physically lock the door to your room, but how about working solely off of an external hard drive, encrypting it, and locking that up elsewhere, in a lockbox or safe or something like that?...


3

I did some admin-work in the past in a company where past admins didn't leave many notes. But there was hardware that was vital, connected to the networks, and not trustworthy. From that experience I can tell you that the old saying is right: if you have physical access and are determined, game over is only a question of time investment. You can make it ...


3

The web servers you've menationed as being shipped with Linux distributions (Apache and Nginx) are two of the three most commonly used web servers (stats from the May 2016 Netcraft report). As such it's safe to say that a very large number of companies consider them safe for widespread use on the Internet (which is by definition a fairly hostile environment)...


3

Also, I forgot to mention. If you want to set a BIOS password, and depending on how much hassle you want to go through, you could invest in a case that has a lock for the side. While that wouldn't entirely prevent intrusion, it would prevent people from tampering with it if they didn't want to be detected. That way they can't just remove the CMOS or access ...


3

I see lots of people mentioning that physical access is game over. While this is true given a well resourced attacker, there is a defence against less well resourced ones: Qubes OS and antievilmaid. https://www.qubes-os.org/ Qubes is essentially Xen running Fedora VMs (you can have other VMs, including Debian and Windows). antievilmaid is a program which ...


3

I encountered the following ages ago from somebody who was excessively paranoid: Full disk encryption where /boot was on removable media and the master password had to be entered from a grid display so that the keystrokes that corresponded to the letters of the master password changed every time the computer booted. My personal recommendation involved here ...


3

It probably helps a little, raising the bar and requiring a more sophisticated attack, but I wouldn't hang my security hat on this. The better way to think about it is that, in the worst case, they have the ability to add arbitrary code to your program. They can do anything that C code can do, including read/writes to files on your filesystem (ie reading ...


2

There is an explanation in the actual book (maybe this 'leaksource' site isn't reliable ;-). You type commands: mkdir /tmp/etc; ln -s /bin/bash /tmp/etc/passwd (A)The heap contains two buffers and 104 bytes is the maximum distance between the first buffer and the datafile allocation buffer. (B)/tmp was not omitted, /etc/passwd will be appended to the end ...


2

There are plenty of security measures to take, starting with the most basic but most important: good firewall rules. But this can be very complicated in some situations. Instead of taking the approach to try to make something very difficult, why not take the easy detection way ? In order for a keylogger to function, it would require an active process. Take ...


2

Your question of why the forward rule doesn't work is essentially a networking question, so I'll explain using an analogy. Imagine there are three people involved in the sending of a letter - Alice, Bob, and you. Alice wants to get a message to Bob, but using you as a middleman (proxy). Alice could use one of two techniques: Method 1: Write a letter ...


2

From here: The bug allows users to work around screen locking (e.g. gnome-screensaver) by hitting Control+Alt+keypad multiply or Control+Alt+keypad divide. This terminates the input grab the screensaver has and thus allows a user to interact with the desktop, skipping the password entry. Therefore enabling this feature will allow the ...


2

Nmap has alternative output formats for exactly this reason. The Normal output (-oN) that you show is for human-readability only, and shouldn't be processed with scripts, since it is subject to undefined change from version to version. Most fully-featured Nmap output viewers (like Zenmap or ScanHub) use the XML output format (-oX), which is the machine-...


2

I'd recommend looking for non-recent versions of OpenSSH in your search. Since it's a relatively well maintained library, if there's any known exploits, they've likely already been patched. However if you look through the CVE list for working DOS methods on older OpenSSH versions, you'll be able to access all those nasty bugs that have already been patched! ...



Only top voted, non community-wiki answers of a minimum length are eligible