=^.^=

Mass Virtual Hosting Part Two: Easy SFTP Chroot Jail

• karma

Plain FTP suffers from a number of problems, foremost is transmission in cleartext. Unless SSL is used (I have come across very few occurrences of its use in the wild) usernames and passwords, as well as the files being transmitted, are sent over the wire unencrypted. This means anyone with a well-placed sniffer or man-in-the-middle setup between the client and server can intercept or mutilate the data without much skill or resource cost. FTP also suffers from NAT issues, in that some users must forward ports or use passive transfer mode - words most of the users who will be using your hosting service have probably never heard, don't want to hear and have no idea how to implement.

Enter SFTP: file transfer over Secure Shell. Not to be confused with FTPS, or "FTP Secure" (FTP with SSL), SFTP shares nothing in common with FTP other than its purpose: moving files around the network. SFTP uses a single, wholly encrypted tunnel from the client to the server to send and receive files. This avoids the problems associated with NAT and FTP's dual-connection implementation, provides a relatively secure means of authentication and prevents third-party manipulation of the data in transit. SSH also warns users when a server's RSA keys change so diligent users can identify and avoid potential man-in-the-middle attacks. SFTP is not, however, a perfect solution. OpenSSH, the implementation which we will be dealing with in this article, can be found on most Linux and BSD servers. Due to its ubiquity it is a prime target for 0-day exploits on one hand, and well hardened against known exploits on the other (you do keep your software patched and up-to-date, right?).

SSH, like any service that uses a username-password authentication scheme - including FTP, is vulnerable to brute-force or dictionary cracking attacks. This problem can be virtually eliminated by disabling user-pass authentication altogether and using on shared keys (please my article Passwordless or Single Password SSH with Key Exchange for instructions on implementing this configuration) however this is probably not an appropriate solution for your public hosting project as the process is difficult for regular users to implement, particularly if they are using a Windows client such as FileZilla. One solution which I highly recommend is fail2ban, it will read your sftpd logs and temporarily block an IP address associated with a specified number of failed attempts over a given period of time. I have provided simple instructions for implementing fail2ban for SSH in my article Stifling Brute Force Attacks with fail2ban. Because we are dealing with a situation where users are prone to forget their password you may wish to use fairly loose criteria in configuring fail2ban, enough failures should be tolerated that a forgetful user won't be quickly blocked but an automated attack should be picked up. You might also wish to block access to sftpd rather than all ports as affected users might understand sftp disappearing after several failed attempts but could think the server is down if they are unable to access their website (assuming it is hosted from the same server).

The "chroot jail" concept is as old as the hills and has provided a way for us to separate vulnerable services from the filesystem-at-large by faking them into thinking a certain directory is the absolute root (/) of the filesystem. In this article we're going to apply this concept to regular users using OpenSSH's built-in functionality available since version 4.9. Before then it was a royal pain to implement whereas most popular FTP daemons had supported the feature out-of-the-box for years, now SFTP can finally be considered a complete and suitable replacement.

One probably does not wish to restrict SSH access for ALL user accounts, since one probably needs remote administrative access to the machine. Therefore one shall create a group to which users who must be chroot jailed will be added. For the purposes of this article we shall call the group hosted but you may call it anything:

# groupadd hosted

Next add users to the group, if you want to make sure these users do not get regular shell access (the ability to log in and run commands etc) be sure to specify a dummy shell, such as /bin/false or /sbin/nologin (Gentoo):

# useradd -G hosted -s /bin/false demo-user
or
# usermod -G hosted -s /bin/false demo-user

Don't forget to give your test account a password if it is a new account.

# passwd demo-user

Now open your sshd config file (most users: /etc/ssh/sshd_config) and go to the very bottom. If there is a Subsystem sftp line already delete it. Add the following:

Subsystem       sftp    internal-sftp
Match Group hosted
        ChrootDirectory %h
        ForceCommand internal-sftp
	AllowTcpForwarding no

The Match Group directive tells sftpd to use the proceeding settings for any user in the group hosted. Now you must change the owner (and optionally group) of the user's home directory to root:

# chown root: /home/demo-user

Due to these permissions the user will not be able to create new files at the top level of their directory tree, which to you looks like /home/demo-user and to them /. That's fine because we're going to give them a directory for the site they want to host with appropriate ownership, then they can do whatever they want in that. I typically set users up thus:

# mkdir ~demo-user/demo-site.com
# mkdir ~demo-user/demo-site.com/htdocs
# mkdir ~demo-user/demo-site.com/log
# mkdir ~demo-user/demo-site.com/cgi-bin
# chown demo-user: ~demo-user/demo-site.com/ -R

Restart your sshd (/etc/init.d/ssh(d) restart) and try logging in as your jailed user via sftp. If it works, congratulations. If you chose to restrict regular SSH access you may need to include /bin/false (or /sbin/nologin etc) to your /etc/shells valid shells list or the user may not be able to log in at all. Try logging in via SSH to ensure access has been blocked.

Mass Virtual Hosting Part One: Database-Backed User Accounts and Authentication

• karma

In situations where the creation of UNIX system accounts (for file system permissions and s/ftp authentication, etc.) should be automated or managed remotely it is possible to use MySQL to store user and group information, thanks to libnss-mysql. There is another project named NSS MySQL which provides the same functionality but for the purposes of this article we will only deal with the former, as it has been more recently updated and is the only one included in Gentoo's Portage package management system.

NSS stands for Name Service Switch, it provides a convenient way to replace or supplement the traditional /etc/passwd /etc/shadow /etc/groups system with anything from LDAP to MySQL tables. It sits at the layer below PAM (which can only handle authentication) and this allows it to transparently handle user and group lookups and modifications from unmodified system tools. For example, using ls to show a directory listing would pull the correct user and group names from the database and using passwd to change the password of an account in the database would interface with the database and not /etc/shadow.

Once you have installed libnss-mysql (emerge libnss-mysql on Gentoo - add it to your package.keywords to grab the last, CVS-based and bug-fixed release) create a database somewhere accessible to both the intended management interface and the system where account information is to be supplemented. Sharing this database across multiple libnss-mysql enabled hosts allows one to maintain a consistent authentication system across them.

# The tables ...
CREATE TABLE groups (
  name varchar(16) NOT NULL default '',
  password varchar(34) NOT NULL default 'x',
  gid int(11) NOT NULL auto_increment,
  PRIMARY KEY  (gid)
) TYPE=MyISAM AUTO_INCREMENT=5000;

CREATE TABLE grouplist (
  rowid int(11) NOT NULL auto_increment,
  gid int(11) NOT NULL default '0',
  username char(16) NOT NULL default '',
  PRIMARY KEY  (rowid)
) TYPE=MyISAM;

CREATE TABLE users (
  username varchar(16) NOT NULL default '',
  uid int(11) NOT NULL auto_increment,
  gid int(11) NOT NULL default '5000',
  gecos varchar(128) NOT NULL default '',
  homedir varchar(255) NOT NULL default '',
  shell varchar(64) NOT NULL default '/bin/bash',
  password varchar(34) NOT NULL default 'x',
  lstchg bigint(20) NOT NULL default '1',
  min bigint(20) NOT NULL default '0',
  max bigint(20) NOT NULL default '99999',
  warn bigint(20) NOT NULL default '0',
  inact bigint(20) NOT NULL default '0',
  expire bigint(20) NOT NULL default '-1',
  flag bigint(20) unsigned NOT NULL default '0',
  PRIMARY KEY  (uid),
  UNIQUE KEY username (username),
  KEY uid (uid)
) TYPE=MyISAM AUTO_INCREMENT=5000;

# The permissions ...
GRANT USAGE ON *.* TO `nss-root`@`localhost` IDENTIFIED BY 'rootpass';
GRANT USAGE ON *.* TO `nss-user`@`localhost` IDENTIFIED BY 'userpass';

GRANT Select (`username`, `uid`, `gid`, `gecos`, `homedir`, `shell`, `password`,
              `lstchg`, `min`, `max`, `warn`, `inact`, `expire`, `flag`)
             ON `auth`.`users`
             TO 'nss-root'@'localhost';
GRANT Select (`name`, `password`, `gid`)
             ON `auth`.`groups`
             TO 'nss-root'@'localhost';

GRANT Select (`username`, `uid`, `gid`, `gecos`, `homedir`, `shell`)
             ON `auth`.`users`
             TO 'nss-user'@'localhost';
GRANT Select (`name`, `password`, `gid`)
             ON `auth`.`groups`
             TO 'nss-user'@'localhost';

GRANT Select (`username`, `gid`)
             ON `auth`.`grouplist`
             TO 'nss-user'@'localhost';
GRANT Select (`username`, `gid`)
             ON `auth`.`grouplist`
             TO 'nss-root'@'localhost';

Modify the permissions section to reflect your needs. libnss-mysql uses a so-called 'user' account for routine operations and a 'root' account for privileged operations, designated by nss-user and nss-root respectively above. Next we must configure the library, edit /etc/libnss-mysql.cfg and change only the authentication information at the bottom of the file:

host        localhost
database    auth
username    nss-user
password    userpass
#socket      /var/lib/mysql/mysql.sock
#port        3306

The SELECT queries at the top of the file can be modified later to integrate into an existing user database of your own design, it is important that only the columns (under any name) specified in the original queries are returned and in that order. Next alter /etc/libnss-mysql-root.cfg to reflect the libnss-mysql 'root' user's MySQL credentials (for obvious reasons these files should have restrictive permissions):

username    nss-root
password    rootpass

libnss-mysql makes use of persistent DB connections, which can be problematic in multithreaded environments as a new connection is established for each thread. For that reason it is recommended to pass the connections through something like mysql-proxy or nsscache/nscd. The problem can also be mitigated by reducing the timeout for persistent connections (default 8 hours) on the MySQL server to something like 1 minute, however this may not be a great idea if the MySQL server is used for other purposes (web hosting etc). Now that we have configured libnss-mysql we must teach NSS to use it. Alter these lines in /etc/nsswitch.conf to reflect:

passwd: files mysql
shadow: files mysql
group:  files mysql

files means first read the traditional /etc/passwd shadow and group files, failing lookup use libnss-mysql (mysql). This lets regular system accounts which we have already created remain valid, important because we don't want to have to import root, your regular user account(s) and all of the daemon accounts. More importantly still if connectivity to the database is lost it is still possible to log in to perform administrative duties. You will note that we created the groups and user tables with an AUTO_INCREMENT set to 5000. Most systems begin creating local user accounts at UID 1000, this amount of space between file-based accounts and database-backed accounts should be enough to keep accounts from overlapping, however your situation may require adjustment. Let's create a test account and see how we did:

INSERT INTO users (username,gecos,homedir,password)
    VALUES ('test', 'Test Account', '/home/test', ENCRYPT('test'));
INSERT INTO groups (name)
    VALUES ('test');
INSERT INTO grouplist (gid,username)
    VALUES (5000,'test');

Here we have created a user named test, with the password 'test', in the group test. The gid value in the last INSERT query should be changed to reflect the UID of the new users in subsequent runs. Create /home/test and chown test:test /home/test. When you ls -lsah /home do you see test and test under user and group next to the test directory? If so congratulations, you have successfully configured libnss-mysql. You may wish to further test your configuration by logging in via ssh/sftp.

It should be easy to see how one can manipulate these queries to add, delete and manage system accounts directly from inside your web-based management interface or other applications, the potential here is limitless.

Addendum:
I encountered a problem setting up a new mysql (server) installation on a host that was configured to use libnss-mysql. The message goes something like:

#  /usr/bin/mysql_install_db
Installing MySQL system tables...    
100706  9:09:15 - mysqld got signal 11 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
We will try our best to scrape up some info that will hopefully help diagnose
the problem, but since we have already crashed, something is definitely wrong
and this may fail.                                                           

key_buffer_size=0
read_buffer_size=262144
max_used_connections=0
max_connections=100    
threads_connected=0    
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_connections = 76800 K
bytes of memory                                                                  
Hope that's ok; if not, decrease some variables in the equation.                 

thd=(nil)
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went   
terribly wrong...                                                      
Cannot determine thread, fp=0x841099c, backtrace may not be correct.   
Bogus stack limit or frame pointer, fp=0x841099c, stack_bottom=0xbffe0000, thread_stack=196608, aborting backtrace.
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains                                        
information that should help you find out what is causing the crash.                                               

This crash occured while the server was calling initgroups(). This is
often due to the use of a mysqld that is statically linked against glibc
and configured to use LDAP in /etc/nsswitch.conf. You will need to either
upgrade to a version of glibc that does not have this problem (2.3.4 or  
later when used with nscd), disable LDAP in your nsswitch.conf, or use a
mysqld that is not statically linked.                                    
Installation of system tables failed!                                    

Examine the logs in /var/lib/mysql for more information.
You can try to start the mysqld daemon with:            
/usr/sbin/mysqld --skip-grant &                         
and use the command line tool                           
/usr/bin/mysql to connect to the mysql                  
database and look at the grant tables:                  

shell> /usr/bin/mysql -u root mysql
mysql> show tables                 

Try 'mysqld --help' if you have problems with paths. Using --log
gives you a log in /var/lib/mysql that may be helpful.          

The latest information about MySQL is available on the web at
http://www.mysql.com                                         
Please consult the MySQL manual section: 'Problems running mysql_install_db',
and the manual section that describes problems on your OS.                   
Another information source is the MySQL email archive.                       
Please check all of the above before mailing us!                             
And if you do mail us, you MUST use the /usr/bin/mysqlbug script!

Of course, I was running glibc 2.11.2 and have nothing in the way of LDAP configured. Unfortunately there is no workaround, you must run the mysql daemon on  a separate server that does not use libnss-mysql.

Remote Controlled Netfilter with ClearOS API

• karma

In my last post I shared a scriptlet that could be used to remote block access to your network with apache, sudo and iptables. This script suffers from the major flaw that appended iptables rules are read last and anywhere a universal ACCEPT rule preceded the script's additions they would be ignored. Another major drawback is in the rules disappearing if the firewall is reloaded, the host is rebooted and so on. Fortunately ClearOS has an easy to use API that lets you directly manipulate its firewall properties the same way as webconfig. This script doesn't require sudo rules or apache to be running. It DOES require ClearOS, and this is how to install it:

The SSL certificate webconfig provides will probably cause problems, so call the script like this if you use wget:

wget -O - 'https://192.168.8.1:81/rcleartables.php?action=deny&name=$name&ip=$ip' --no-check-certificate >/dev/null 2>&1

Note that this script requires a name variable, it should be a unique identifier containing letters and numbers (no spaces). I keep the name and other data associated with the blocks on the client end of things so the blocks can be removed by a button that executes the script with action=remove and also take care of cleaning stale blocks by way of recorded  timestamps. How you choose to extend the functionality is up to you.

<?php
/*
           # Remote Controlled iptables ClearOS API
           # June 2010 http://foxpa.ws
           # WTFPL v.2 http://foxpa.ws/wtfpl/

/// DOCUMENTATION

DANGER: Improperly configured, this script could be used by an attacker to
        block legitimate traffic.

This script adds or removes a name/IP pair pssed to it through the GET
variables "ip", "name" and "action" to or from the ClearOS Incoming Block
firewall ruleset. Valid action values are deny, and remove.
The script will exit with a 0 on error or a 1 upon successful execution.
Place the script in /var/webconfig/htdocs and chown it to webconfig.

To block an IP, one would GET request it thus:
https://address:81/rcleartables.php?action=block&ip=222.222.222.222&name=
On a successful block you would receive HTTP headers and a single 1 in the
body, or a 0 if the block was unsuccessful.

$whitelist is an array of IP addresses that should never be blocked
$allowed_clients should be an array of IP addresses allowed to have access to
this script. leave it blank to allow any host (not recommended).
$shared_secret is an optional key that can be passed to the script as an MD5
hash via GET var "key" to authenticate your application. Blank to disable.
$log_path should be the path to the specific file you would like to log actions
to. Blank to disable logging. Remember to update your log rotater's config.
*/

// CONFIGURATION
$whitelist = array();
$allowed_clients = array('');
$shared_secret = '';
$log_path = '/var/log/riptables.log';

// FUNCTIONS
function log_action($line)
{
	global $log_path, $remote_addr;
	if(!empty($log_path))
	{
		$fh = fopen($log_path, 'a');
		$date = date("Y-m-d H:i:s", time());
		fwrite($fh, "$date $remote_addr - $line\n");
		fclose($fh);
	}
}

// SANITY CHECKING
if(empty($_GET['ip']))
{
	log_action("IP not specified");
	die('0');
}
if($_GET['action'] == 'deny' and empty($_GET['name']))
{
	log_action('Rule name not specified');
	die('0');
}
$ip = $_GET['ip'];
$name = $_GET['name'];
$remote_addr = $_SERVER['REMOTE_ADDR'];
$octets = explode('.', $ip);
foreach($octets as $octet)
{
	if($octet > 255 or $octet < 0)
	{
		log_action("Invalid IP Address $ip");
		die('0');
	}
}
$ip = escapeshellcmd($ip);
if(!empty($shared_secret) and $_GET['key'] != md5($shared_secret))
{
	log_action("DANGER Invalid shared secret. Remember to encrypt your key variable with MD5.");
	die('0');
}
if(!empty($allowed_clients[0]))
{
	$valid = false;
	foreach($allowed_clients as $allowed)
	{
		if($allowed = $remote_addr)
			$valid = true;
	}
	if(!$valid)
	{
		log_action("DANGER Client is not in \$allowed_hosts array. This could be a sign of exposure.");
		die('0');
	}
}

// THE BRAINS
require_once("/var/webconfig/api/FirewallIncoming.class.php");
$fw = new FirewallIncoming();

if($_GET['action'] == 'deny')
{
	$fw->AddBlockHost($name, $ip);
	$fw->Restart();
	log_action("$ip was blocked");
	print('1');
}
elseif($_GET['action'] == 'remove')
{
	$fw->DeleteBlockHost($ip);
	$fw->Restart();
	log_action("$ip was removed");
	print('1');
}
else
{
	log_action('Invalid action parameter.');
	die('0');
}

?>
<?php
/*
# Remote Controlled iptables ClearOS API
# June 2010 http://foxpa.ws
# WTFPL v.2 http://foxpa.ws/wtfpl/

/// DOCUMENTATION

DANGER: Improperly configured, this script could be used by an attacker to
block legitimate traffic.

This script adds or removes a name/IP pair pssed to it through the GET
variables "ip", "name" and "action" to or from the ClearOS Incoming Block
firewall ruleset. Valid action values are block, and remove.
The script will exit with a 0 on error or a 1 upon successful execution.
Place the script in /var/webconfig/htdocs and chown it to webconfig.

To block an IP, one would GET request it thus:
https://address:81/rcleartables.php?action=block&ip=222.222.222.222&name=
On a successful block you would receive HTTP headers and a single 1 in the
body, or a 0 if the block was unsuccessful.

$whitelist is an array of IP addresses that should never be blocked
$allowed_clients should be an array of IP addresses allowed to have access to
this script. leave it blank to allow any host (not recommended).
$shared_secret is an optional key that can be passed to the script as an MD5
hash via GET var "key" to authenticate your application. Blank to disable.
$log_path should be the path to the specific file you would like to log actions
to. Blank to disable logging. Remember to update your log rotater's config.
*/

// CONFIGURATION
$whitelist = array();
$allowed_clients = array('');
$shared_secret = '';
$log_path = '/var/log/riptables.log';

// FUNCTIONS
function log_action($line)
{
global $log_path, $remote_addr;
if(!empty($log_path))
{
$fh = fopen($log_path, 'a');
$date = date("Y-m-d H:i:s", time());
fwrite($fh, "$date $remote_addr - $line\n");
fclose($fh);
}
}

// SANITY CHECKING
if(empty($_GET['ip']))
{
log_action("IP not specified");
die('0');
}
if($_GET['action'] == 'block' and empty($_GET['name']))
{
log_action('Rule name not specified');
die('0');
}
$ip = $_GET['ip'];
$name = $_GET['name'];
$remote_addr = $_SERVER['REMOTE_ADDR'];
$octets = explode('.', $ip);
foreach($octets as $octet)
{
if($octet > 255 or $octet < 0)
{
log_action("Invalid IP Address $ip");
die('0');
}
}
$ip = escapeshellcmd($ip);
if(!empty($shared_secret) and $_GET['key'] != md5($shared_secret))
{
log_action("DANGER Invalid shared secret. Remember to encrypt your key variable with MD5.");
die('0');
}
if(!empty($allowed_clients[0]))
{
$valid = false;
foreach($allowed_clients as $allowed)
{
if($allowed = $remote_addr)
$valid = true;
}
if(!$valid)
{
log_action("DANGER Client is not in \$allowed_hosts array. This could be a sign of exposure.");
die('0');
}
}

// THE BRAINS
require_once("/var/webconfig/api/FirewallIncoming.class.php");
$fw = new FirewallIncoming();

if($_GET['action'] == 'deny')
{
$fw->AddBlockHost($name, $ip);
$fw->Restart();
log_action("$ip was blocked");
print('1');
}
elseif($_GET['action'] == 'remove')
{
$fw->DeleteBlockHost($ip);
$fw->Restart();
log_action("$ip was removed");
print('1');
}
else
{
log_action('Invalid action parameter.');
die('0');
}

?>

Remote Controlled Netfilter with httpd, iptables and sudo

• karma

For a more secure and robust method of executing commands remotely, please see Part Six of my Mass Virtual Hosting series.

Is your web server behind a Linux firewall? Have you ever wanted to quickly make a ban at the firewall level from within your site? This extremely simple script will help you accomplish just that.

ClearOS users please see this article instead.

Requirements:

  • A linux router/firewall
  • Netfilter and iptables
  • An httpd capable of running PHP
  • PHP
  • Probably sudo

Selecting and configuring your httpd goes beyond the scope of this article. I recommend lighttpd but apache works just as well for a slightly higher memory footprint. For obvious reasons, make sure the web server is only reachable from the private network.

It's important to point out here that we're talking about exposing a service with root access to iptables on your firewall; this is not without great risk and you must take every precaution to secure and restrict access to the web daemon.

Once you have your httpd configured and running install riptables.php somewhere in the default host's document root. Load it in your web browser. If you get a '0' in the page body the script is running properly. In most cases you will need to add a line to sudoers that grants your httpd access to your iptables binary.  Open sudoers thus:

# visudo

and add this line, replacing apache with the account your httpd runs under and /sbin/iptables with the full path to your iptables binary (some systems, including ClearOS, replace /sbin/iptables with a shell script; use /sbin/iptables-bin instead):

apache ALL=(root) NOPASSWD: /sbin/iptables

Save sudoers and open riptables.php. Adjust the configuration variables to reflect your environment. Depending on your system you may need to seed the logfile to give your httpd write access:

# touch /var/log/riptables.log
# chown httpd: /var/log/riptables.log

where httpd is the account your web daemon runs under. Save the script and do a test run; from a root shell on your router type:

# iptables-save | grep "222.222.222.222"

You should see no results. Load the following URL into your browser, replacing the appropriate parts such as IP address:

http://192.168.0.1/riptables.php?action=deny&ip=222.222.222.222

If your browser loaded a '1' then the block was added successfully. Run the iptables-save line again. You should see:

-A INPUT -s 222.222.222.222 -j DROP
-A FORWARD -s 222.222.222.222 -j DROP
-A OUTPUT -d 222.222.222.222 -j DROP

If so everything is in working order. If not, check your log. Remove the block thus:

http://192.168.0.1/riptables.php?action=remove&ip=222.222.222.222

An additional mechanism for authentication, which comes in handy if the IP(s) you have granted access run multiple web apps, is the shared secred. Put a passphrase into the $shared_secret variable, then when you call the script from your webapp append the key variable with an md5'd hash of the secret.
The script can be called from within your web application by crafting a GET request or as simply as running wget:

exec("wget -O - 'http://$fw_address/riptables.php?action=$action&ip=$ip' >/dev/null 2>&1");

Download riptables.php here.

Note that IP chain rules are followed in order. If there is an ACCEPT rule for 0.0.0.0/0 before the rules this script adds they must be removed or it will not work.

< ?php
/*
           # Remote Controlled iptables
           # June 2010 http://foxpa.ws/
           # WTFPL v.2 http://foxpa.ws/wtfpl/

/// DOCUMENTATION

DANGER: This script requires sudo and an httpd in most environments.
        If you don't know why that's dangerous, you don't want to use this
        script.

DANGER: Improperly configured, this script could be used by an attacker to
        block legitimate traffic.

This script blocks, allows or removes an IP as passed to it through the GET
variables "ip" and "action." Valid action values are block, allow, remove.
The script will exit with a 0 on any error or a 1 on a successful execution.

To block an IP, one would GET request it thus:
   http://server-address/riptables.php?action=block&ip=222.222.222.222
On a successful block you would receive HTTP headers and a single 1 in the
body, or a 0 if the block was unsuccessful.

To grant httpd access to iptables you may need to edit sodoers to reflect:
apache ALL=(root) NOPASSWD: /sbin/iptables
where apache is whatever account your web daemon of choice runs under.

$whitelist is an array of IP addresses that should never be blocked
$allowed_clients should be an array of IP addresses allowed to have access to
this script. leave it blank to allow any host (not recommended).
$shared_secret is an optional key that can be passed to the script as an MD5
hash via GET var "key" to authenticate your application. Blank to disable.
$sudo_path should be the complete path to your sudo binary. Leave blank
if you do not require sudo.
$iptables_path should be set to reflect your system's configuration. Typical
locations include /sbin and /usr/sbin. Be sure to leave off the trailing slash.
$iptables_bin shoild be the name of your iptables binary, usually just iptables
except on systems where it has been replaced with a shell script.
$log_path should be the path to the specific file you would like to log actions
to. Blank to disable logging. Remember to update your log rotater's config.
*/

// CONFIGURATION
$whitelist = array();
$allowed_clients = array();
$shared_secret = '';
$sudo_path = '/usr/bin/sudo';
$iptables_path = '/sbin';
$iptables_bin = 'iptables';
$log_path = '/var/log/riptables.log';

// FUNCTIONS
function log_action($line)
{
	global $log_path, $remote_addr;
	if(!empty($log_path))
	{
		$fh = fopen($log_path, 'a');
		$date = date("Y-m-d H:i:s", time());
		fwrite($fh, "$date $remote_addr - $line\n");
		fclose($fh);
	}
}

function ip_deny($ip)	// This function drops all packets from an IP
{
	global $sudo_path, $iptables_path, $iptables_bin;
	$string1 = "$sudo_path $iptables_path/$iptables_bin -A INPUT -s $ip -j DROP";
	$string2 = "$sudo_path $iptables_path/$iptables_bin -A FORWARD -s $ip -j DROP";
	$string3 = "$sudo_path $iptables_path/$iptables_bin -A OUTPUT -d $ip -j DROP";
	exec($string1, $output1, $return1);
	exec($string2, $output2, $return2);
	exec($string3, $coutput3, $return3);
	if($return1 != 0 or $return2 != 0 or $return3 != 0) // Check for non-zero exit status
	{
		log_action("Attempted to block $ip but failed. Error:\nString1: $string1\nOutput1: {$output1[0]}\nString2: $string2\nOutput2: {$output2[0]}\nString3: $string3\nOutput3: {$output3[0]}\n");
		return 0;
	}
	else
	{
		log_action("$ip was blocked.");
		return 1;
	}
}

function ip_accept($ip) // This function explicitly allows an address, useful where DROP is default
{
	global $sudo_path, $iptables_path, $iptables_bin;
	$string1 = "$sudo_path $iptables_path/$iptables_bin -A INPUT -s $ip -j ACCEPT";
	$string2 = "$sudo_path $iptables_path/$iptables_bin -A FORWARD -s $ip -j ACCEPT";
	$string3 = "$sudo_path $iptables_path/$iptables_bin -A OUTPUT -d $ip -j ACCEPT";
	exec($string1, $output1, $return1);
	exec($string2, $output2, $return2);
	exec($string3, $coutput3, $return3);
	if($return1 != 0 or $return2 != 0 or $return3 != 0) // Check for non-zero exit status
	{
		log_action("Attempted to accept $ip but failed. Error:\nString1: $string1\nOutput1: {$output1[0]}\nString2: $string2\nOutput2: {$output2[0]}\nString3: $string3\nOutput3: {$output3[0]}\n");
		return 0;
	}
	else
	{
		log_action("$ip was accepted.");
		return 1;
	}
}

function ip_remove($ip) // This function undelicately removes a block or explicit accept from an IP
{
	global $sudo_path, $iptables_path, $iptables_bin;
	exec("$sudo_path $iptables_path/$iptables_bin -D INPUT -s $ip -j DROP");
	exec("$sudo_path $iptables_path/$iptables_bin -D FORWARD -s $ip -j DROP");
	exec("$sudo_path $iptables_path/$iptables_bin -D OUTPUT -d $ip -j DROP");
	exec("$sudo_path $iptables_path/$iptables_bin -D INPUT -s $ip -j ACCEPT");
	exec("$sudo_path $iptables_path/$iptables_bin -D FORWARD -s $ip -j ACCEPT");
	exec("$sudo_path $iptables_path/$iptables_bin -D OUTPUT -d $ip -j ACCEPT");
	log_action("$ip was removed.");
	return 1;
}

// SANITY CHECKING
if(!empty($_GET['ip']))
	$ip = $_GET['ip'];
else
	die('0');
$remote_addr = $_SERVER['REMOTE_ADDR'];
$octets = explode('.', $ip);
foreach($octets as $octet)
{
	if($octet > 255 or $octet < 0)
	{
		log_action("Invalid IP Address $ip");
		die('0');
	}
}
$ip = escapeshellcmd($ip);
if(!empty($shared_secret) and $_GET['key'] != md5($shared_secret))
{
	log_action("DANGER Invalid shared secret. Remember to encrypt your key variable with MD5.");
	die('0');
}
if(!empty($allowed_clients[0]))
{
	$valid = false;
	foreach($allowed_clients as $allowed)
	{
		if($allowed = $remote_addr)
			$valid = true;
	}
	if(!$valid)
	{
		log_action("DANGER Client is not in \$allowed_hosts array. This could be a sign of exposure.");
		die('0');
	}
}

// THE BRAINS
if($_GET['action'] == 'deny')
{
	foreach($whitelist as $whiteip)
	{
		if($ip == $whiteip)
			die('0');
	}
	ip_remove($ip);
	print(ip_deny($ip));
}
elseif($_GET['action'] == 'accept')
{
	ip_remove($ip);
	print(ip_accept($ip));
}
elseif($_GET['action'] == 'remove')
{
	ip_remove($ip);
	print('1');
}
else
{
	log_action('Invalid action parameter.');
	die('0');
}

?>

Geofence with iptables: Blocking Countries at the Firewall

• karma

In some situations one may find it useful to block entire countries or restrict access to only one or a few. This is a technique known as geofencing, and if you've ever tried to watch a video only to be told that it's not available in your region you have been the victim of it. Geofencing, like geolocation, is possible because blocks of IP address space are handed out to specific countries, and additional details such as the province or city of the address holder may be obtained through reverse-whois. Data collected below the country level can be unreliable, often the location of a head office for a national ISP will appear to be the source of all if its users.

ahorli on the Clear forums just posted their geofencing solution for ClearOS at http://www.clearfoundation.com/component/option,com_kunena/Itemid,232/catid,7/func,view/id,10382/. It is intended to block specific countries that tend to produce a high volume of spam and automated attacks (in this case, Russia and China). I thought it would be neat to reverse the script so I could block every country except a specific one or two. Obviously this kind of tactic isn't going to stop someone who really wants into your box from outside the geofence - there's everything from proxies to VPNs to exploit. My interest here is in reducing automated attacks to those originating in the motherland, because that's the only place I expect to be connecting to our hypothetical server.

Download this script and put it somewhere appropriate, I would suggest /sbin or /usr/sbin. In order to work this requires that your default INPUT policy is DROP or REJECT. As mentioned above, geofencing is more art than science and when I ran this script my own subnet was not unblocked, I strongly recommend including your headquarters in the ALLOWSUBNET variable or you may find yourself one day without access. As you can see MAXZONEAGE is set to 6, so if we pop this in cron.weekly it should refresh its fence list every week. You should add the script to your firewall or local init scripts, on ClearOS use /etc/rc.d/rc.firewall.local.