Databases, Systems & Networks

Source: DigitalOcean – Justin Ellingwood

Introduction

WordPress is the most popular CMS (content management system) used on the internet today. While many people use it because it is powerful and simple, sometimes people make a trade-off for convenience at the expense of security.

This is the case in how you choose to assign directory ownership and permissions, and how you choose to perform upgrades. There are a variety of different methods to do this. We will choose what we consider a relatively secure way of upgrading and installing themes and plugins.

In this guide, we assume that you have gone through your initial server setup. You will also need to install a LAMP stack on your VPS.

We will also assume that you have installed WordPress on Ubuntu 12.04. You can follow our guide on how to install WordPress on Ubuntu 12.04 here.

Once you have the user and required software, you can start following this guide.

Set Up Secure Updates with SSH

If you do not have key-based updates and installations configured, you will get a prompt for connection information whenever you attempt to do either of these tasks.

It will ask you to provide FTP credentials, such as a hostname, FTP username, and FTP password:

FTP is an inherently insecure protocol, so we do not recommend you using it in most cases. We will be configuring our installation to use a secure alternative.

Changing Permissions

If you followed the guide on installing WordPress above, you will notice that you gave permission of the web directory to the Apache web user. This is a very quick way to get started, but can potentially be a security risk. In an ideal situation, you would separate the content owner from the web process. We will do this as part of our preparation for allowing SSH updates.

We will create a user called wp-user to own our WordPress installation.

sudo adduser wp-user

You will be asked a lot of question, including the password you want to set. We do not want to set a password, so press “ENTER” through all of the prompts, including the repeated password questions.

Next, change to the /var/www/html directory, where our WordPress files are being served.

cd /var/www/html

We will give our new user ownership over everything under this directory, changing it from the www-data Apache web user that we configured during installation.

sudo chown -R wp-user:wp-user /var/www/html

Lire la suite…

When NSA gets you worrying

In a post on Wednesday, researchers Alex Halderman and Nadia Heninger presented compelling research suggesting that the NSA has developed the capability to decrypt a large number of HTTPS, SSH, and VPN connections using an attack on common implementations of the Diffie-Hellman key exchange algorithm with 1024-bit primes. Earlier in the year, they were part of a research group that published a study of the Logjam attack, which leveraged overlooked and outdated code to enforce “export-grade” (downgraded, 512-bit) parameters for Diffie-Hellman. By performing a cost analysis of the algorithm with stronger 1024-bit parameters and comparing that with what we know of the NSA “black budget” (and reading between the lines of several leaked documents about NSA interception capabilities) they concluded that it’s likely NSA has been breaking 1024-bit Diffie-Hellman for some time now.

The good news is, in the time since this research was originally published, the major browser vendors (IE, Chrome, and Firefox) have removed support for 512-bit Diffie-Hellman, addressing the biggest vulnerability. However, 1024-bit Diffie-Hellman remains supported for the forseeable future despite its vulnerability to NSA surveillance. In this post, we present some practical tips to protect yourself from the surveillance machine, whether you’re using a web browser, an SSH client, or VPN software.

Disclaimer: This is not a complete guide, and not all software is covered.

Web Browser

To make sure you’re using the strongest crypto, you have to look at the encryption algorithms (or cipher suites) that your browser supports. There’s an excellent tool, How’s My SSL?, that will test your browser’s cipher suite support. The relevant area of the page is the bottom, Given Cipher Suites. You want to make sure that you don’t see the text “_DHE_” in the list of ciphersuites – although the Elliptic Curve variant of Diffie-Hellman, represented by suites with “_ECDHE_” is okay. It is important to note that there is a trade-off here: removing your clients support for “_DHE_” ciphers will eliminate the risk of this attack, but it may also remove Forward Secrecy support altogether for some sites. Here’s how to remove those “_DHE_” cipher suites if you still have them:

Firefox

(tested with 40.0.3)

Open a new tab, enter “about:config” into the location bar and hit the “Enter” key. If you get a warning page, click “I’ll be careful, I promise!” This will bring you to the Firefox configuration settings. In the search bar up top, type “.dhe_” and hit the “Enter” key. This should result in two settings being displayed: “security.ssl3.dhe_rsa_aes_128_sha” and “security.ssl3.dhe_rsa_aes_256_sha”. Double-click both of them to change the value from “true” to “false”.

Now, if you refresh the How’s My SSL page, the “_DHE_” ciphersuites should be gone!

Lire la suite…

Source: nixCraft

I have a backup sync program on local server. I have an ssh password less login set up, and I can run commands on an external server in bash script doing:

ssh root@server2 "sync; sync; /sbin/shutdown -h now"

How do I run multiple commands in bash on a remote Unix or Linux server? What is the best Way to SSH in and Run various unix commands in bash?

There are various ways to run multiple commands on a remote Unix server. The syntax is as follows:

Simple bash syntax to run multiple commands on remote machine

Simply run command2 if command1 successful on a remote host called foo
$ ssh bar@foo "command1 && command2"
Run date and hostname commands:
$ ssh user@host "date && hostname"
You can run sudo command as follows on a remote box called server1.cyberciti.biz:
$ ssh -t vivek@server1.dbsysnet.com "sudo /sbin/shutdown -h now"
And, finally:
$ ssh root@server1.dbsysnet.com "sync && sync && /sbin/shutdown -h now"

Lire la suite…

One of the most daunting prospects of administering your own server on a public network is dealing with your server’s security. While security threats in a networked world are real and it is always important to be mindful of security issues, protecting against possible attacks is often a matter of exercising basic common sense and adhering to some general best practices.

This guide takes a broad overview of common security concerns and provides a number of possible solutions to common security problems. You are encouraged to consider deploying some of these measures to “harden” your server against possible attacks.

It’s important to remember that all of the solutions we present in this document are targeted at specific kinds of attacks, which themselves may be relevant only in specific configurations. Security solutions need to be tailored to the kind of services that you’re providing and the software you’re running, and the decision whether or not to deploy a specific security solution is often a matter of personal discretion and cost-benefit analysis.

Perhaps most importantly, it should be understood that security is a process, not a product (credit to Bruce Schneier.) There is no “magic bullet” set of guidelines that can be followed to ensure the security of any system. Threats are constantly evolving, so vigilance is required on the part of network administrators to prevent unauthorized access to systems.

Keep Systems and Software Up To Date

One of the most significant sources of security vulnerabilities are systems running out of date software with known security holes. Make a point of using your system’s package management tools to keep your software up to date; this will greatly assist in avoiding easily preventable security intrusions.

Running system updates with the package management tool, using apt-get update && apt-get upgrade (for Debian and Ubuntu Systems) or yum update (for CentOS and Fedora systems) is simple and straightforward. This practice ensures that if your distribution maintains active security updates, your system will be guarded against many security holes in commonly used software packages.

System update tools will, however, not keep software up to date that you’ve installed outside of package management. This includes software that you’ve compiled and installed “by hand” (e.g. with ./configure && make && make install) and web-based applications that you’ve installed from a software developer’s site, as is often the case with applications like WordPress and Drupal. Also excluded from protection will be libraries and packages you’ve installed with supplementary package management tools like Ruby’s Gems, Perl’s CPAN tool, Python easy_install, and Haskell Cabal. You will have to manage the process of keeping these files up to date yourself.

The method you use to make sure that your entire system is kept up to date is a matter of personal preference, and depends on the nature of your workflow. We would recommend trying very hard to use the versions of software provided by your operating system or other programming platform-specific package management tools. If you must install from “source,” we would recommend that you save the tarballs and source files for all such software in /src/ or ~/src/ so that you can keep track of what software you’ve installed in this manner. Often, you can remove a manually compiled application by issuing make uninstall in the source repository (directory). Additionally, it may be helpful to maintain a list of manually installed software, with version numbers and download locations. You may also want to investigate packaging your own software so that you can install it with apt, yum or pacman.

Because of the complexity of maintaining software outside of the system’s package management tools we strongly recommend avoiding manually installing software unless absolutely necessary. Your choice in a Linux distribution should be heavily biased by the availability of software in that distro’s repositories for the systems you need to run on your server.

Lire la suite…

Source: munin-monitoring.org
There are a number of situations where you’d like to run munin-node on hosts not directly available to the Munin server. This article describes a few scenarios and different alternatives to set up monitoring. Monitoring hosts behind a non-routing server.

In this scenario, a *nix server sits between the Munin server and one or more Munin nodes. The server in-between reaches both the Munin server and the Munin node, but the Munin server does not reach the Munin node or vice versa.

To enable for Munin monitoring, there are several approaches, but mainly either using SSH tunneling or “bouncing” via the in-between server.

Bouncing

This workaround uses netcat and inetd/xinetd to forward the queries from the Munin server. All incoming connections to defined ports are automatically forwarded to the Munin node using netcat.