sendmail-wrapper for PHP

Years ago I wrote about the extensive sendmail wrapper with sender throttling, a pretty simple Perl script. It reliably provided throttling of the email volume per day by the sender’s original UID (user id). It also logged the pathes of scripts that sent emails directly via sendmail (e.g. via PHP’s mail() function). The main flaw in the original sendmail wrapper was security, though. As in Linux, every executable script must be readable by the user that calls it, the throttle table in MySQL was basically open and every customer could manipulate it. Every customer could raise his own throttling limit and circumvent it.

Today, I’m publishing my new sendmail-wrapper that is going to fix all the flaws of the previous version and add some nice extras.
The new sendmail-wrapper is written entirely in PHP and does not require any external libraries. It is a complete rewrite and has pretty much nothing in common with the old Perl version.

This project is hosted on Github

Features:

  • Lets you monitor any mail traffic from PHP scripts
  • Allows throttling (limiting) emails sent by PHP’s mail() function
  • Throttle by sent email and/or recipient count per day
  • Logs both to syslog and database with message metadata
  • Logs common mail headers like From, To, Cc, Bcc, Subject
  • Fixes Return-Path header on the fly for users who did not correctly set it
  • Highly secured setup, customers cannot access the logging/throttling database
  • Standalone PHP application without any external library dependencies
  • Built for shared webhosting environment where PHP runs as cgi/FastCGI/suPHP
  • No cronjobs required, sendmail-wrapper will reset counters automatically every day

Read More

Webapp-scanner

Webhosting customers are messies, at least some of them – or (sadly, that’s the truth) the bigger part of them. Some people still think they can run the same blog software or CMS for years without ever caring about upgrading. I tell my customers over and over how important it is, to keep their website up-to-date and don’t let any outdated code lying around. Still, as long as their website doesn’t get hacked or defaced, they don’t really seem to care.

If you’re in the same situation as me and you are providing webhosting services to your friends or customers, read on.

This project is hosted on Github

Read More

Process hiding: hidepid capabilities of procfs

Five years ago I wrote about kernel based process hiding in Linux (see articles Simple process hiding kernel patch, Process hiding Kernel patch for 2.6.24.x, RSBAC – Kernel based process hiding). It got time to continue the story and finally present you a real solution without the hassle of a self-compiled kernel.

How can I prevent users from seeing processes that do not belong to them?

In January 2012, Vasiliy Kulikov came up with a kernel patch that solved the problem nicely by adding a hidepid mount option for procfs. The patch landed in Linux kernel 3.3.

In the meantime, this patch luckily also landed in the 3.2 kernel of Debian Wheezy (see backport request in Debian bug report #669028). This feature has been also pushed back into the kernel of Red Hat Enterprise Linux 6.3 (see RHEL 6.3 Release Notes), and from there to CentOS 6.3 and Scientific Linux 6.3. Recently, this feature was even backported to the 2.6.18 kernel in RHEL 5.9.

As Proxmox VE currently runs on a RHEL based 2.6.32 kernel, it’s also supported in my favorite OpenVZ/KVM virtualization platform. Great!

Read More

Proxmox VE: Restricting Web UI access

With the release of Proxmox VE 3.0 back in May 2013, the Proxmox VE web interface does no longer require Apache. Instead, they’re using now a new event driven API server called pveproxy. That was actually a great step ahead, as we all know Apache get’s bulkier every day and the new pveproxy is a much more lightweight solution. But the question arose:

How do I protect my Proxmox VE WebUI with basic user authentication?

 

Basically, we do not trust any web application out there so we better double protect the whole WebUI with plain old basic auth – previously done in Apache by .htaccess.

The main idea:

  • Restrict access to the pveproxy (= Web UI) to localhost
  • Install a local Nginx web proxy server that forwards requests from port 443 to pveproxy’s port 8006 and restrict access to it using HTTP BASIC AUTH

Read More

EncFSVault as a FileVault replacement

EncFSVault provides a replacement for Apple’s FileVault. There are a lot of issues with FileVault. Personally I don’t like any proprietary software for security sensitive storage of my data. But the main reason I was not able to use FileVault was the fact that FileVault still doesn’t provide support for case sensitive HFS+ file systems as of OS X Leopard 10.5.6. That’s a shame!
My choice was EncFSVault. Good or bad choice?

Read More

Simple PHP mail wrapper

If you run a webserver with several hundreds of virtual hosts running PHP, you definitely need to monitor or log the access to PHP’s mail() function. I describe in a short tutorial how to painlessly setup a simple sendmail wrapper to accomplish this.
This has been tested on a Debian Lenny 5.0 system running PHP 5.2.8 and Postfix.

Read More

Process hiding Kernel patch for 2.6.24.x

Currently all Linux kernel security patch projects seem to be sleeping. There is no useful kernel patch that provides us with a decent patch set allowing us to strengthen the Linux kernel. Some years ago I was using Grsecurity, a wonderful solution to enforce security on 2.4.x kernels at that time. The project seems to be pretty dead by now.

During the last months I was using RSBAC, a great set of security enhancements to the 2.6.x kernels. RSBAC seems to be a great project and I like the way they provide pre-patched vanilla kernels. But again, reaction time is way too slow. Root exploits for Linux kernels seem to appear all the time and force a server administrator to react fast. The lately published vmsplice root exploit made me give up on RSBAC as it’s just always a step behind. I decided to switch back to self compiled vanilla kernels from kernel.org.

Read More

RSBAC – Kernel based process hiding

A webserver usually is the primary target to intrude into any network. If you provide web hosting services for your customers you have to provide them with a lot of features to make them happy. The main requirement for any hosting provider is PHP, probably the widest spread web scripting language out there.

Some customers only start to get happy if you give them PHP without any safe_mode restrictions, if you provide them with custom CGI scripting next to the basic good old SSI features (which in my eyes no one really needs since we got PHP) by Apache HTTP Server, if you give them FTP access and let them manage their account by themselves.

Rule Set Based Access ControlIn every feature there is always a hidden security risk. We cannot give all this to our customers without thinking about security and its consequences if a user gets hold of data which does not belong to himself or even breaks into the whole system. So, let’s start at the basics: No customer should be able to see any other running processes on the system except the ones that belong to himself. We want to hide all processes that the given customer is not allowed to see. That’s process hiding. And because on a Linux box it’s always smart to implement something from bottom up, we name it kernel based.

There is no simple solution for this problem. Some rootkits simply overwrite the ‚ps‘ command. But we want something more trustworthy, somehow deeper anchored in the system (got that?). The only kernel patch I found was the one from RSBAC.org (Rule Set Based Access Control), a full blown kernel security patch. The only feature we actually need is „CAP process hiding“.

Read More

css.php