Tag Info

New answers tagged

0

You don't have to overthink this problem. If someone is willing to physically change the printout on the on-site printer, it's easy to just steal the computer and go away. Or force shutdown the server, create a image of the disk, backdoor the image, and put it back. And this is highly improbable, unless you are a very important target, and I think you are ...


5

To meet this requirement, I think you'll want to look into a dedicated log server. No remote access, not even SSH. Syslog is the only service. Credentials are unique to the logging server. That's pretty reliable. Depending on your case, it could be anything from a pimped-out, highly reliable commercial chassis to a RaspberryPi hanging on a nail.


1

This is an attempt to exploit CVE-2014-6271 (the “shellshock” vulnerability, if we must). Its appearance in this message is no indication that it was successful; any client can include any string in the Referer: header and have it included in logs here. The attempt didn't succeeded in this specific case, because the log message is telling you there was no ...


1

So it looks like someone is trying to use the shellshock vulnerability which was recently discovered in the bash shell. The key give-away is the part of the log which reads: referer: () { :;}; /bin/bash What the attacker (or unknowing participant) has done is to set their web browser's http referer header to everything you see after the word "referer" in ...


1

While Linux has a file security model similar to that of early Unix, I think there has been a change in how the computers are used. In the 70's and 80's, Unix was run on large computers hosting many concurrent users. For example, a single computer could be used by all students in a computer science program. With that type of usage, protecting machine ...


0

This is an old piece of malware. Though technology isn't a panacea, if you're having this problem it seems like your technical protection needs an update. If updated, I feel like offering that if it were easy to do this at a server it would already be implemented at the workstations: To identify files associated with CryptoLocker you need a signature, and ...


1

As mentioned in a comment above, there are two basic strategies for protecting the IP in your source code: Make your source code more difficult to understand. This is typically done through obfuscation. Obfuscators attempt to make the source code difficult to reverse compile and/or difficult to understand once they've been reverse compiled. I'm no expert ...


2

WARNING: Creativity ahead, which is often bad for security (at least without thorough review). This sounds like a case in which an SSH agent could be useful. An SSH agent provides a socket interface over which SSH clients can ask the agent to perform key operations for them, which enables the following common uses: You can have the long-running agent ...


4

1: Use hardware tokens, like a Yubikey configured for challenge-response based authentication. Or smartcards. You load up the key on them all and hand them out. They're designed to keep the secrets secret. 2: Stop using a single key, start using one keypair per user for accountability and practical revocability.


0

Well besides the sudo answer (which is really clever btw), another solution is a restricted shell. In this case you would have to write one. In this case the only commands you need to accept are "ssh <hostname>" and "exit" so it's not so hard. I'm really only posting this for completeness, but the general technique is valuable in other contexts.


0

A couple of pointers: Using SAMBA significantly reduces your security. for what you propose SSH would be a better fit (when utilizing Public keys) nginx does NOT use .htaccess (and htaccess is horrible for performance and security). you should configure everything in the (virtual-) host directives. (so in the /etc/nginx/sites-available for most *NIX'es) ...


9

This can be done using techniques like: Docker virtual Machines Jails Clusters (out of scope for home use) The trick here is to NOT use a single user environment like Windows. but use a environment where you could safely test any file without risk of infection. So you need a READ-ONLY Environment (full OS, not just the location being tested) which makes ...


-3

If you're using Linux exclusively, you can completely isolate applications (pretty much like what docker does) using systemd: https://chimeracoder.github.io/docker-without-docker/ Applications inside a container have no access to the outside - just make sure they don't run as root. If you want something more portable, chroots might work for you, assuming ...


4

Your assumptions are correct. Security by isolation is indeed a good principle to follow. There is also a whole Operating System which implements this idea on the Desktop: Qubes OS (Which is running on the laptop I'm using to write this). To get back to your server model, I think one VM per service is a good idea, but it will become resource intensive. ...



Top 50 recent answers are included