New answers tagged

4

So I have found a few resources which seem to indicate that the main infection method is done by gaining access to the system using SSH bruteforce: A Avast antivirus research: The infection starts by an attempt to brute force SSH login credentials of the root user. If successful, attackers gain access to the compromised machine, then install the Trojan ...


0

There are several flaws in your procedure. Ubuntu only monitors issues that are relevant for the software versions included in supported releases. If an issue is discovered that affects software in 10.04 but not in any of the currently supported releases, they won't pay attention to it, so your system will remain vulnerable. Fixing issues by installing the ...


0

Most applications should be using static ports on the servers side. In other words, one side of a connection should always be using a predictable port. Unfortunately, as you stated, living with a firewall can be a pain at first, while you build a robust policy set. You have to identify each and every service necessary and add appropriate policies to your ...


3

It is better to try to manually patch serious security bugs than doing nothing, but it will be terribly hard to close everything. That's why we use distribs. There are teams of maintainers that keeps staying informed on security threats, look whether they can apply to their code and then either patch or upgrade. The problem when you use a no longer ...


4

I've been maintaining a private fork of a CMS for approx. 7 years. The initial release had some serious security issues which did not get fixed properly by the original vendor in time. This is why I have fixed it myself and this is where I have lost the compatibility to most of the original patches/upgrades. This is possible, it takes a lot of time. And it ...


3

Joanna Rutkowska, leader of the Qubes project, does a great job into documenting the concepts on which Qubes is relying. I therefore strongly suggest you to get the information at the source, and in particular to read the two following documents: Software compartmentalization vs. physical separation (Or why Qubes OS is more than just a random collection of ...


1

Those credentials have to be placed somewhere. If you decide to place them at a place like /usr/lib/cgi-bin, you'd have to grant your web user access to that directory structure which would in turn make your system more vulnerable. It is more common to place them one level above the web root as a compromise between the two. This way you don't open much of ...


0

In theory, Qubes would be more secure as it's running fewer services by default. No network discovery, file sharing, etc, so less probability for any of those to get remotely exploited. It also benefits from being open source as well as being a niche OS, which means there's less malware targeting it. In reality though, unless you have reasons to believe you ...


0

I was just wondering if there was anything barring me from testing my own network for security vulnerabilities? Yes. Some ISPs may have terms that prohibit certain activities which appear to be attacks. To thwart this issue, you could use your own equipment to attack. So, instead of having your firewall be plugged into your "modem" (e.g., cable modem, ...


1

It's perfectly legal to attack a machine or network as long as you have the explicit permission of the owner. Since it's your network, you can do whatever you would like.* There are other laws you may still bump into. For example, you can't change your WiFi access points to transmit on an unlicensed frequency. If you install a virus "for testing purposes"...


2

There is nothing hindering you from testing within your own network. To get a rudimentary understanding of what is involved with testing, I suggest you familiarize yourself with the Penetration Testing Execution Standard, OSSTMM, and other similar pentesting frameworks. Once you begin establishing the who, what, when, where and why, it will make things ...


0

If you're trying to get the MAC address of Wi-Fi access points, you can run sudo iwlist scanning, and look for the ESSID of the device that interests you.


1

Another idea: You could buy a cheap single-board computer (think Raspberry Pi). The Pi 3 is fast enough to replace a desktop PC if you're only browsing the internet and watching movies etc and costs about $40. It's powered by an usb phone charger cable (or another computer's usb port) and supports hdmi output. It's small enough that you can hide it in a ...


1

Yes, it does make your system less secure, since it exposes internals to the world, and the next time an exploit is detected for a service you use, you can be an early target. That being said, it may still be a good idea. Sunlight is the best disinfectant and by Kerkchoff's principle, secrecy of your implementation should not be a precondition for security....


0

The risk from "inadvertently add[ing] an extraneous user to the group" is minimal. And fACLs are not obsolete. Used properly fACLs supplement the the things which are difficult to do with the base permissions system, but they do open the possibility of creating a labrynthine mess the likes of which are only normally seen on badly managed MSWindows shares. ...


1

The principle at play here is the least privilege. A chmod permission of 600 or 700 gives only the owner rights to the file, while 660 or 770 gives the same rights to the group too. Whether this is intended or not depends on the use case. Either might be appropriate. A server might - and will probably - have different categories of users (students, ...


0

Use a hot-swap cage for you hard drive, and remove the hard drive when not in use. Take away with you or keep in a safe place. Such drive can be connected to the usual SATA connection. Unlike with USB, you do not loose your speed and it can be any capacity. The OS can boot from this drive no problem - and they really cannot get anything from your computer ...


1

SSH public key authentication does not support anything like key revocation. The list of "allowed" keys is store in the ~/.ssh/authorized_keys and if you remove the key from there, you revoke the access (if this is what you want to hear). Revocation list is related to Public Key Infrastructure usually based on the X.509 certificates with certificate ...


1

No. This is provably nonsense. There are countless people in security who started at all sorts of ages; some who have had careers in entirely different fields before moving to security. Sure, it can help in some areas if you have known security concepts for longer, but it's much more important to have an open mind to learning the subject.


0

My primary PC consists of a passwordless desktop PC, that anyone in the house can use. From this machine I connect to a Windows 10 machine running on Azure. I don't have an issue with anyone installing keyloggers etc (I don't think!) but there are a number of 2 factor authentication options freely available to home users that would make the password for that ...


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 ...


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 ...


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 ...


1

While it might be in theory impossible to prevent an attack given physical access, you can do a lot to limit the physical access to what matters, thus limiting the attack vectors. I think your best option would be a custom Linux boot CD plus an encrypted USB stick for storage. Many distros make creating a custom CD fairly easy, including Arch and Gentoo. A ...


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 ...


2

Apart from what others said (Live CD, full disk encryption etc), the following are some precautions. (1) Download your Linux distro on a trusted computer. Don't do that on your Windows system because the ISO image may get replaced/infected/amended secretly. Don't just trust checksums (checksum utilities can be fake, too). (2) Sign on your Live CD/DVD/USB ...


0

Yes; it is possible for the root user on Linux to execute arbitrary machine code in ring 0. The attacker using root could either use a system call or the insmod command to load a kernel module, which runs at the same privilege level as the kernel. Because of this ability to load a kernel module, the relevant system calls and commands require root. ......


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 ...


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 ...


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' ...


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

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?...


85

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 ...


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 ...


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 ...


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 ...


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, ...


66

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 ...


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 ...


1

The docs for diskcryptor state: DiskCryptor releases from 0.1 to 0.4 were fully compatible with TrueCrypt, as they used a corresponding partition format and encrypted data with AES-256 algorithm in LRW mode. Starting from DiskCryptor 0.5, the program relies upon its own partition format, developed specifically for encrypting partitions with data on them, ...


0

One could run a Virtual Box machine with windows OS and then mount the Diskcryptor encrypted drive that way and allow the flow of files from VM to Host for transferring. I have not done this yet, but in theory, it is a viable option for Linux transition from previous Windows environments, which also requires minimal resources to accomplish. No need for ...


0

There are two ways to approach this, depending on just how inaccessible you want to make the data. If you simply want to require knowledge of the LUKS passphrase to regain access to the data (more or less the normal case, but expediated), then you can use cryptsetup luksSuspend on the dm-crypt device name. According to the man page, this: Suspends an ...


0

If properly configured, then yes, the IP address of the backend server would be hidden. This is the operating principle behind DDoS protection services like Cloudflare: Hide the real server behind a proxy server that can tolerate a large volume of traffic while filtering out bad requests. That said, if it's imperative that your backend server IP remains ...


0

Using a reverse proxy in web servers allows you many features. One of these is automatic data traversal to multiple servers through reverse proxies and load balancers. The server should be completely anonymous at this point. The only way the attacker could find out the proxied server is if there was a vulnerability in the framework that allows them to run ...


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 ...


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 ...


2

The most secure way is to use a Trusted Platform Module. This is specific hardware made for storing keys and doing cryptographic operations. This is secure even against sophisticated attackers with physical access (e.g. the FBI), but you need specific hardware which will cost more. Without this, attackers may just read the key from memory. In that case you ...


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 ...


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 ...



Top 50 recent answers are included