Hot answers tagged linux
19
There are a number of defenses you can use to help prevent and recover from theft.
The first thing you should look into is full-disk encryption, e.g. LUKS, TrueCrypt, or PGP. This will prevent an attacker from reading any data on the disk, even if they steal the hardware. You will need to enter the password at boot, though, so for unattended remote hardware ...
8
There is a handy script distributed alongside openssl, CA.sh to do most of this stuff. Its location is distribution specific. In Debian and derivatives you can locate it using:
# apt-file search CA.sh
openssl: /usr/lib/ssl/misc/CA.sh
And RedHat and derivatives the (approximate) equivalent is:
# yum provides */CA
1:openssl-1.0.1e-4.fc18.x86_64 : Utilities ...
7
Going by your threat model which is theft of the server, I would choose to go with full disk encryption in the form of LUKS or similar.
For that threat model though, encryption shouldn't be your focus. Instead, make sure your datacentre has appropriate physical security in the form of access control, surveillance and the likes.
5
Metasploit is meant to be run under a linux environment.
Wrong. Metasploit is simply a collection of Ruby scripts, so all you need is Ruby installed. Also, Metasploit has a Windows installer so go crazy with it...
5
I would consider 2 possible approaches - I note that you are trying to verify an exploit for escalation of privilege exploiting a bug in the kernel. For the sake of the experiment, I would ignore user space software even though this is probably a bad idea.
Approach #1 assuming that you may need access to data on the server in question, I would install a VM ...
4
There is one mcrypt which is a command-line utility and library for file encryption; and another mcrypt which is completely unrelated, and appears to be a direct rip-off of TrueCrypt, which is an implementation of an encrypted filesystem (and that rip-off might be illegal and/or malicious as well). GnuPG is an implementation of the OpenPGP standard, which ...
4
Virtual machine, but real CPU. Regardless of how you elect to see it, the code for your server still runs on the machine of the supposed attacker. Similarly, disk encryption of any kind would not help either, even if you personally typed the password yourself upon boot: at some point, the data is still decrypted, on the attacker's machine.
Virtual machines ...
4
(Caveat: I certainly don't claim that HAVEGE lives up to its claims. I have not checked their theory or implementation.)
To get randomness, HAVEGE and similar systems feed on "physical events", and in particular on the timing of physical events. Such events include occurrences of hardware interrupts (which, in turn, gathers data about key strokes, mouse ...
4
Filtering arbitrary connections could be done with a kernel module by hooking netfilter. And anything done in kernel land with a kernel module, can be undone with a kernel module. Also, nothing is keeping root form just installing their own kernel...
root is GOD, never forget that.
3
Just off the top of my head:
If user's credentials are compromised, locking out that account in the user directory is much quicker and reliable than editing /root/.ssh/authorized_keys on all systems to remove that user's key.
Linux auditing daemons distinguish between "uid" and "effective uid". Users who ssh in as themselves and then sudo to gain ...
3
Device security is limited to the type of device.
What are the security risks of Bluetooth and what technologies and
best practices should be used to protect my device?
Each device provides a level of services. The services provided create the restrictions or limitations to access and exploit. The best protection is to keep Bluetooth turned off (if ...
3
"Root is God". Well, there are gods... and then, there are elder gods.
The root user can do a lot of things on a machine. In particular, he can replace the files which are used to boot the machine; thus, he can potentially replace your kernel with another of his own, which would let him pass. SELinux can be used as a way to make a declawed, neutered root ...
2
Since both tmux and wemux use their own server-like process and joining/authentication procedures, they inherently increase the so-called "attack surface": that's more code which may have bugs, and bugs can easily become vulnerabilities.
However, at least tmux has good repute, with, as far as this page says, was only ever affected by one known ...
2
The --modprobe option is part of the command line syntax of the iptables-restore command. It isn't something that iptables-restore parses as input.
So if there's a sudo rule that allows you to run iptables-restore with arbitrary arguments, you can pass --modprobe=/bin/sh or variants thereof. But if all you can do is pass input to iptables-restore, then this ...
2
If you give someone code to run on their own computer, there is always the possibility that they will do something with it that you didn't want or expect. If you've given them the source code, you've made that easier for them. If you absolutely must give people the actual code, and you don't want them to play with it, here are two possibilities gleaned from ...
1
Find what the exploit takes advantage of. Is it your Linux kernel (version)? Then all systems with that version number may be effected.
Assuming you have a vulnerability, you should know what it attacks. If for some reason you don't know what the exploit does don't test it on production servers. If the exploit is a script, then you can just peak and see ...
1
Wireshark is usually a poor choice for things that must run continuously. dumpcap, part of the wireshark suite, is a better choice. You should be able to specify the hone device with -i hone (or -i /dev/hone) to dumpcap. Alternatively, dumpcap can read from a named pipe, which could read from the device. See: ...
1
Rook is correct, of course. Given that you would be setting this up as root, someone could just as easily take it apart as root. However, you could make that time consuming.
The most direct approach would be to edit sys_socket.c, or perhaps just socket.c (the usermode-wrapper) to include a IP filter.
If you edit sys_socket.c you would have to recompile the ...
1
So Rook's answer to you is yes/no. Basically without downloading the linux kernel source and rewriting some of it yourself, what he proposes is your answer. You could do most of what you want, but you could not achieve preventing root from being able to bypass changing it.
You could make it so that you have root account that never sees the light of day, and ...
Only top voted, non community-wiki answers of a minimum length are eligible
