I've been fighting to get haproxy to log in FreeBSD.. but I've found it! This is how:

- in haproxy.conf, under global, set:

log 127.0.0.1:514 syslog info

- in your /etc/rc.conf, set:

syslogd_flags="-a 127.0.0.1/32:*"

- touch:

touch /var/log/haproxy.conf

- in /etc/syslogd.conf, set:

!haproxy
*.* /var/log/haproxy.log


Now restart syslogd (/etc/rc.d/syslogd restart), and restart haproxy. Now tail -f /var/log/haproxy.log .. cool huh!

You might want to add it to /etc/newsyslog.conf, because these logs can grow pretty fast.

[ add comment ]   |  permalink  |   ( 3.1 / 135 )

---

If you run Apache and PHP, always consider setting some basic security settings that will slow down (at least) any unwanted visitors.

httpd.conf:

ServerTokens prod
ServerSignature Off
TraceEnable off

php.ini :

Expose_php = off
disable_functions   = system, shell_exec, prop_open, phpinfo, passthru
error_log = /var/log/phperrors.log # (touch and chown www!)
display_errors = Off
error_reporting  =  E_ALL & ~E_NOTICE
log_errors = On

These settings will not easily reveal version numbers and it will disable some hacker-friendly functions in PHP. PHP (unless specified individually) will not show errors, but log them to a file. Errors occuring on the website will show up as a blank page. Errors only give away potential weaknesses.

You should also consider running a firewall (ipfw, pf) with a default to deny policy for outgoing as well as incoming. Only open up ports that are needed and documented - for both directions. FreeBSD's ipfw supports filtering depending on uid as well. So you could say:

ipfw add allow tcp from me to 1.2.3.4 80 setup uid www

.. to allow the webserver to get that RSS feed from server 1.2.3.4.

VirtualHosts

For each vhost configuration you can set a number of PHP options. One that always should be set is:

php_admin_value open_basedir /usr/home/user/www/www.website.com/:/dev/urandom:/var/tmp/

This way php has no access outside of the defined directories.

[ add comment ]   |  permalink  |   ( 2.9 / 135 )

---

The security of a server depends on a couple of things. One of those are the applications that are installed on the server. Thus it is important to keep track of the security advisories that are out there, and update applications if they have 'issues' as soon as patches come available.

When using FreeBSD's ports, this can all be monitored automatically, and with a little effort, we can build it into Nagios. This way we don't have to periodically check Charlie's email, but Nagios will start to complain as soon as any issue is detected.

server.cfg:

define service{
        use                             local-service
        host_name                       localhost
        service_description             portaudit
        check_command                   check_snmp_pkgvuln
        normal_check_interval           720
        }

Now if there is a port installed on your system that has a known security vulnerability, Nagios will tell you about it.


[ add comment ]   |  permalink  |   ( 3 / 121 )

---

Keeping your systems up to date is important. Not only the applications running on it, but also the system itself. Is the OS secure? Are there any known vulnerabilities that might affect you, or even better, is there a fix available that I can install?

Both Linux and FreeBSD have binary upgrade methods available, that make keeping the system up to date easy-going. With a little bit of shell scripting and some knowlegde of Nagios, it's possible to monitor the status of the OS patch level, and notify the administrator if updates are available.

For FreeBSD, we can add to cron something like:

0 4 * * * /usr/sbin/freebsd-update cron

This will perform nightly checks to see if security updates are available. If they are, we see some changes happening in /var/db/freebsd-update/. If patches ara available for install, it will create a file in /var/db/freebsd-update/ named [somehash]-install. So, if we test for the existance of this file, we can know if updates are available.

For instance, create /usr/local/sbin/checkfreebsd-update with:

#!/bin/sh
if [ -h /var/db/freebsd-update/*-install ]
then
        echo -n "WARNING Please upgrade `uname -r` -> p" ; \
        cat /var/db/freebsd-update/tag | awk -F\| '{print $4}'
        exit 1
else
        echo "OK System Up-To-Date"
        exit 0
fi

So if the system is up to date, it will return a "OK .." and it will exit with a 0, meaning all is OK. Otherwise, it will exit with a 1, and it will even tell you to which patch level you can update.

Add this to snmpd.conf like so:

extend freebsd-update /usr/local/sbin/checkfreebsd-update

And in Nagios, you can now monitor if updates are available. Install the check_snmp_extend.sh script from Nagios / SNMP tools and configure it like:

checkcommands.cfg:

define command{
        command_name    check_snmp_extend
        command_line    $USER1$/check_snmp_extend.sh $HOSTADDRESS$ $ARG1$
}

servers.cfg:

define service{
  use generic_service
  hostname host.to.check.com
  service_description        freebsd-update
  check_command              check_snmp_extend!freebsd-update
}

Now you will be notified via Nagios if updates are available. How cool is that!

[ add comment ]   |  permalink  |   ( 2.9 / 133 )

---

Wouldn't anybody like their website to be setup redundant? Redundancy keeps your website running if certain components that make it up, fail. It can also increase scalability. But it brings more advantages. For a system administrator, being able to take out a machine from a pool of servers for maintenance, or even reboot it without anyone noticing, can be a real plus in an environment where security is important.

Very often you see updates to servers are being delayed for weeks, months or even years because people are afraid to brake things. Irony has it that waiting will brake everything if you wait long enough.

Haproxy is an open source load balancing (and alot more!) application, and it totaly rocks. There are numerous companies using haproxy in huge setups, setups that needed quick growth, scalability, and high availability. Checkout highscalability.com for some testimonies of very happy users.

Haproxy on itself brings redundancy, scalability and easy administration to your server farm. But the machine that haproxy is running on, will become a SPOF.

Imagine the following:

   [internet]
   |
   [haproxy]
   /   |   |  \
  [1] [2] [3] [4]

We can see that incoming requests will be devided over 4 machines. One or perhaps even two machines could fail in this setup, and your website is still running. But what if your haproxy machine fails?

In comes CARP. CARP is a protocol which allows multiple hosts on the same local network to share a set of IP addresses.

The most common appliance for CARP is to build a redundant firewall using BSD's packet filter pf. A standard firewall is just such a SPOF for all the machines behind it, so why not make it redundant, right? CARP works realy well, as does BSD's pf, which even figures out how to save the state of all ongoing TCP/IP connections when failover occurs (carp/pf does this by using a third, dedicated interface on both machines connected through a x-cable).

A simple diagram might look something like this:

   [internet]
   /   \
  [fw1]-[fw2]
   \   /
   [ D M Z ]

We see that our internet uplink is redundant (not uncommon for most ISP's), we have two firewall machines held redundant by CARP, so there is at least a redundant path to my DMZ.

With CARP already in the picture, it becomes clear that we can use CARP for more than just firewall redundancy. We can configure a third CARP address on both machines, and bind haproxy on that IP address. Consequently I change the DNS of my website to point to this new IP address.

   [internet]
   /   \
  [fw1]--[fw2]
  [hap1][hap2]
   \   /
   [ D M Z ]

By default, all our traffic will go through fw1/hap1, distributing the load over servers in my DMZ. But if fw1 goes down, fw2 takes over and my website is still load balanced over machines in my DMZ. For haproxy it's all transparent: the configuration on both CARP machines is the same, it even binds on the same IP on both machines, so we can also sync it's configuration. Of course haproxy know's nothing about the counter-haproxy on the other machine so there's no sharing of information there (haproxy's stats for example), but that's OK.

[ add comment ]   |  permalink  |   ( 3 / 134 )

---

| 1 |

Error - Page Generated in 0.1638 seconds | Site Views: 1539