New answers tagged linux
1
Bluetooth 2.1 and forward require encryption on all connections other than service discovery. A key is exchanged during pairing and used for all future service delivery. If your hardware is using a standard prior to 2.1, then it is possible it could use an unencrypted connection, but otherwise it is guaranteed to use encryption.
In fact, the NSA has even ...
13
Introduction
I'll try to the best of my knowledge to approach your questions without touching the technical parts of the Bluetooth technology itself. I've learned a lot of the following while I had to write a security report to shape a BYOD policy. Knowing you, I won't have to lecture you on that there's nothing 100% secure, everything we do is just to make ...
0
No, or at least we don't know of a way to accomplish what you're asking as of now.
However, we do recommend that you install a virtual linux system and run metasploit that way.
1
Depending on what modules are available, you might be able to use xt_sysrq for some fun.
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 ...
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 ...
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...
6
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 ...
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 ...
0
There is no encryption algorithm involved. The use of “encryption” is a misnomer, due to the historical password hashing algorithm being based on DES, which is primarily used for encryption and known as such. id is in fact the hashing method, and all documentation should properly use the word “hash” throughout instead of “encrypt”.
For id = 1, the algorithm ...
0
I think they really mean hashing method for the hash in use. The format is:
"$id$salt$hashed", where "$id" is the algorithm used (On GNU/Linux, "$1$" stands for MD5, "$2a$" is Blowfish, "$5$" is SHA-256 and "$6$" is SHA-512 ...)
the source of which is available on wikipedia.
I've just looked at the manual and it does indeed say "encryption method". ...
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 ...
0
I have run screen on bastion hosts in the past but have been trying to get away from it for just the reason you mention. If the bastion host is intruded upon they can get access to all of your open sessions. So running screen/tmux on a bastion host is NOT recommended.
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 ...
0
I read of one... You find a very remote place, preferably not on a map anywhere. You put the Linux run time you want to protect in a vault like bunker with no physical access, running on its on dedicate power supply (of course this has to be a perpetual motion machine based power supply), in a facility that has no staff, no network connections and is ...
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 ...
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.
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 ...
0
Root is not god if you have SELinux enabled. That is the only way I can see to accomplish what you want. Block it with iptables and run SELinux in strict mode.
You might have uid 0 but you won't have the capabilities(7).
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: ...
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 ...
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 ...
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 ...
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.
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 ...
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 ...
Top 50 recent answers are included
