Never Ending Security

It starts all here

Category Archives: Firewall

SQLassie – A database Firewall That Detects And Prevents SQL Injection Attacks At Runtime


SQLassie

SQLassie is a database firewall that detects and prevents SQL injection attacks at runtime.

Usage

SQLassie currently only supports MySQL. To start SQLassie, you’ll need to configure how SQLassie connects to the MySQL server, start SQLassie listening on a different port that is now protected, and then configure your applications to connect through this alternate port instead of directly to MySQL.

As an example, consider a scenario where you have a MySQL database engine running and listening for connections on the domain socket /var/run/mysql/mysqld.sock and are running a MediaWiki installation.

First, start SQLassie using

./sqlassie -s /var/run/mysql/mysqld.sock -l 3307

Then, edit MediaWiki’s configuration file LocalSettings.php connect to port 3307.

$wgDBServer = "127.0.0.1:3307"

Note that you can’t use localhost here; by default, MySQL interprets localhost as a request to use the direct database domain socket connection, and most web applications behave this way as well. Therefore, you have to use the explicit string 127.0.0.1 in order to force connections to go through the TCP port. Check your application’s documentation for more information.

Testing

Now that you’ve gotten everything up and running, check to see if your web application still loads. If it does, you can check to see if SQLassie is correctly filtering attacks against your database. Bring up a terminal and run

mysql -u <user> -p -h 127.0.0.1 -P 3307 -C

to connect to the database through SQLassie.

We can run a number of tests here. First, SQLassie will block most error messages that are produced by MySQL, because this information can be valuable to hackers. Start by running

SELECT * FROM foo;

Normally, MYSQL would respond with an error about no database being selected, but SQLassie intercepts the query and instead responds with Empty set. In this case, SQLassie recognized that the query was a SELECT query, and rather than give an error, it simply provided a response that made sense based on the query type.

Next, try running

SELECT first_name, last_name, age FROM user WHERE id = 1323 UNION SELECT User, Password, 1 FROM mysql.user;

SQLassie identifies this query as containing a schema discovery attack and blocks the query, responding with a fake empty Empty set message.

Compiling

SQLassie comes with two Makefiles: one meant for use with gcc, and one meant for use with clang++. Support for gcc is more thorough at this time, so to start building, change into the source directory

cd src

and link to the gcc Makefile by running

ln -s Makefile.gcc Makefile

Next, you’ll need to install some dependencies. On a Debian-based system, you should get everything you need by running

apt-get install make g++ bison flex libboost-regex-dev libboost-thread-dev libboost-program-options-dev libboost-test-dev libboost-filesystem-dev libmysqlclient-dev

Finally, compile by running

make

The resulting binaries will be placed in the bin directory.

More information can be found at: https://github.com/bskari/sqlassie and at: http://www.sqlassie.org

Building the Ultimate VirtualBox Lab


Building the Ultimate VirtualBox Lab – Introduction

In my never-ending quest to continue learning as much as I can in the IT industry, one thing has always caused me some headaches until now. Setting up the proper foundation for my testing in the form of a virtual test lab where I can install multiple servers and clients easily without having to worry about taking up 40GB+ for each virtual machine.

I have received a lot of comments, private messages, and emails from the community asking me what I suggest for them to do in order to learn System Administrator topics in order to help them in job interviews or to help them in their current job if they are already working in the field.

Introduction: Ultimate VBox Setup

One answer always comes to mind with these types of questions; Virtualization. Setup a virtual test lab by configuring a virtual server (virtual pc), download the trial versions of Microsoft’s operating systems, install them and practice practice practice. Setup a domain controller or two. Take one offline and practice bringing another one online to simulate a down domain controller, Setup SQL server, WSUS, and so on.

This article is part 1 of 6 in the series:

  • Part 1: Building the Ultimate VirtualBox Lab – Intro
  • Part 2: Building the Ultimate VirtualBox Lab – Configure Vbox
  • Part 3: Building the Ultimate VirtualBox Lab – Install pfSense
  • Part 4: Building the Ultimate VirtualBox Lab – Install Windows 2012 Base
  • Part 5: Building the Ultimate VirtualBox Lab – Prep for .vdi Compacting
  • Part 6: Building the Ultimate VirtualBox Lab – Linked Clones
  • Bonus: Building the Ultimate VirtualBox Lab – RDP to Virtual Machines

citrix-logo  hyper-v-logo Virtualbox_logo vmware-logo

In the past, I have setup many different virtual lab environments including:

For this article, I chose to go with Oracle VirtualBox. If money wasn’t an issue, I would probably choose VMWare Workstation. Actually, if money really wasn’t an issue, I would buy a nice server with a SAN and setup VMWare ESXi. Ok, enough dreaming.

One of the issues I faced was having enough resources on the host’s computer where I can run 3 or 4 servers along with a couple of client computers at the same time while not worrying about CPU, RAM, and hard drive space.

Since I recently built a new computer as my main box to handle video editing (and anything else I want to throw at it), I finally decided to search out the best methods for hosting all of my virtual machines on this box. These days, I use my laptop about 95% of the time and only touch my big desktop for video editing. Why not put this computer’s horsepower to use since I’m hardly using it as is.

The specs of this machine are as follows:

At this point what I want to do is give you a visual of what I have in mind. I am not an artist by any means so hopefully you can understand what I’m illustrating here. This is just a basic idea of the SSD/HDD configuration:

Click to enlarge
Drawing of Ultimate VirtualBox Setup

To help better explain the drawing, here is what is going on. We are going to be usingLinked Clones to setup many virtual machines. The main reason I am using Linked Clonesis to save on hard drive space.

A brief description of Linked Clones: Setup a “base” virtual machine, install all patches/updates, sysprep and shutdown the machine (You will not turn this machine back on). This will be the base image that all future machines (same OS) will use when setting them up. Any changes made to the Linked Clones will be saved in their own .vdi in their own folder.

This is a HUGE plus for me since my SSDs are not very large. Also, using SSDs for this task is a huge advantage. Since I will be having multiple virtual machines running at the same time, they will all be using the base image so having the fast read/write speed will help with performance. I have not tried it using non SSDs but am curious how well it works.

As a side note: You can still have a standard HDD for things like SQL Databases, WSUS updates storage, network share storage, and more where speed is not as crucial.

Download the software and ISO images to prepare for the setup:

This article was only the beginning, introducing you to building the ultimate VirtualBox test lab.

In the next article (coming soon), we will be setting up the environment. I will walk you step-by-step in the entire process and by the end of the series, you should have a well-rounded and stable virtual test lab. From there on, you can go wild with setting up different servers, clients, testing group policies, pushing out software, breaking servers and learning how to handle disaster recovery and so on.

Building the Ultimate VirtualBox Lab – Configure VBox

Begin to learn how to become a System Administrator on your own by building the ultimate VirtualBox test-lab.

We briefly discussed what to expect with this video series and the overall configuration with hardware as well as linked clones.

Virtualization is key when wanting to setup a virtual machine test-lab. This tutorial is going to be considered video number 1 in the Building the Ultimate VirtualBox Lab series and will show you how to setup your virtual server environment. The tips shown here will help with setting up the foundation before we begin setting up our virtual machines and linked clones.

Configure VBox

Let’s begin

  • Open Oracle VM VirtualBox Manager
  • File -> Preferences -> General
  • Default Machine Folder: Navigate to the folder you want to store all your VMs in
    Virtualbox Default Machine Folder
  • Select Network in the left column
  • Highlight the adapter and click the edit button
    VirtualBox Edit Network
  • Select the DHCP Server tab
  • Remove the check from Enable Server
    VirttualBox Disable DHCP Server

That’s it for configuring Virtualbox for our Ultimate VirtualBox lab.

The next tutorial will begin by setting up pfSense to act as our lab’s router out to the internet.

Building the Ultimate VirtualBox Lab – Install pfSense

Continuing on with our self-learning to become a System Administrator, this article of Building the Ultimate VirtualBox Lab series we are focusing on how to install pfSense in VirtualBox.

I suggest you check it out since it has a couple key configuration changes in VBox that will save you some headaches later.

Install pfSense in VirtualBox

Before we get started I would like to explain the reason I have decided to use pfSense within our virtual lab for learning. When setting up a virtual server test lab, I like to try and mimmic an actual business environment as closely as possible. Because we want to use virtualization for this task, what pfSense will do is act as our virtual test lab’s router (to allow the virtual machines access to the internet). This will keep my host’s machine safe as well as any computers/devices on my host’s network. I guess you can look at it as my host’s network is acting as an ISP for my virtual environment.

Another reason why I wanted to use pfSense is so I can produce some tutorials on some key features of pfSense in the future when things settle down here at the house (remodeling/selling/buying another new house, etc.)

Let’s Get Started

We need to setup pfSense first so that during the other VM setups we can get out to the internet to install updates.

You can find the download links on this page.

Normally I like to include a lot of screenshots within these tutorials, but I think since the below instructions are pretty straight forward (and there is an associated video), I think I will hold off on the screenshots. If you feel they would help with this tutorial, please let me know in the comments section below and I will happily add them.

Create a new VM with minimum specs (pfSense doesn’t need to be run on a powerful machine).

  • Name: pfSense
  • Type: Linux
  • Version: Other Linux
  • 256MB of RAM
  • 8GB for the Dynamically allocated vdi (hard drive) should work out fine. You don’t need this one to be stored on an SSD but if you have the space, go for it.
  • 1 CPU
  • 2 NICs
    • Adapter 1: Enable Network Adapter
      • Attached to: Bridged (This will be our WAN port in pfSense)
    • Adapter 2: Enable Network Adapter
      • Attached to: Internal (This will be our LAN port in pfSense)
  • Attach the pfSense ISO to the CDRom drive so we can boot off of the CD
  • Disable:
    • Floppy drive
    • Enable absolute pointing device
    • USB Controller
    • Audio
  • If using an SSD, tell VBox that the VM is stored on an SSD
    • Select the vdi under the SATA Controller
    • Put a check in the Solid-state drive option under Attributes (This tells the guest OS that it’s drive is an SSD so it can take appropriate actions to deal with an SSD such as Windows disabling defrag, etc..)

Power on the VM and begin the setup

  • Select option 1 to boot pfSense
  • Pay attention during the install, you will see an option to select “I” to install, otherwise it will auto continue with running the live CD. Select “I”
  • Follow the prompts to install pfSense (I selected the Quick/Easy install)
  • During the first boot off of the hard drive, we need to configure a few things
    • Do you want to set up VLANs now: N
    • Enter the WAN interface name: em0
    • Enter the LAN interface name: em1
    • Optional 1 Interface: (leave blank and press Enter)
    • Let’s configure our WAN port to be static
      • Select number 2 (Set interface(s) IP address
      • Select number 1 (WAN)
      • Configure WAN interface via DHCP?: N
      • Type in the IP you want to give it (has to be on your host’s subnet) (I’m setting mine to 10.2.0.199)
      • Type in the Subnet mask (more than likely you will be using 24)
      • Revert to HTTP….: N

At this point we are done setting up pfSense. Once we setup our first Windows VM we will web into pfSense to finish a couple small configuration changes to allow our VMs access to the internet.

Building the Ultimate VirtualBox Lab – Install Windows 2012 Base

We will be focusing on installing Windows Server 2012 Base for our Building the Ultimate VirtualBox Test Lab series. We will configure a few basic settings, and install all Windows Updates to ensure we are patched up.

Quick reminder: We are setting up linked clones so we can maximize disk usage on our virtual server. If we were to setup normal clones and/or VMs, we would quickly run low on disk space. Since we are using SSDs to store the VDI (virtual hard disk files for our virtualbox VMs), it is very important that we use Linked Clones for this task.

Setup Windows 2012 Base for Linked Clones

Windows 2012 ISO Download

All of the downloads can be found HERE.

Let’s begin

Configure a new Base VM

  • Name: *_Base (i.e. Windows_Server_2012_Base)

VirtualBox Name Server 2012

  • 1024 MB RAM
  • Create a virtual hard drive now
    • VDI
    • Dynamically allocated
    • 40GB
  • 1 CPU
  • Disable:
    • Floppy drive
    • Enable absolute pointing device
    • USB Controller
    • Audio
  • NIC: Internal
  • Attach ISO for installation

VirtualBox Attach ISO and SSD

  • If using an SSD, tell VBox that the VM is stored on an SSD
    • Select the vdi under the SATA Controller
    • Put a check in the Solid-state drive option under Attributes (This tells the guest OS that it’s drive is an SSD so it can take appropriate actions to deal with an SSD such as disabling defrag, etc..)

VirtualBox Configure For Linked Clones

Install and Configure VM

  • Install the guest OS
  • Install VBox Guest Additions

VirtualBox Windows Server 2012 Install Guest Additions

  • Configure the network adapter
    • Set the IP statically (your information will probably be different than mine):
      • IPV4: 192.168.1.8
      • Subnet: 255.255.255.0
      • Gateway: 192.168.1.1 (pfSense LAN IP)
      • DNS: 10.2.0.1 (for now, set it to your home router’s LAN IP or a public DNS so we can resolve hostnames until we setup our server to be a DNS server)

Finish Configuring pfSense

  • Web into pfSense using the it’s LAN IP from within the VM lan (on this Windows 2012 VM). (For me, I connect to https://192.168.1.1)
    • Username: admin
    • Password: pfsense
    • System -> Setup Wizard
      • Run through wizard
      • Take note of the WAN Gateway: Set this to your home’s router IP address. This will ensure that pfSense knows where to send all of the VM’s internet traffic out to the internet.
      • Set a new/secure password

Final Windows Configurations

  • Make sure the timezone is set properly and the VM has the correct time
  • Install .NETt Framework 3.5 Features (if Windows Server)
    • Server Manager -> Add Roles and Features

VirtualBox Add Role to Server 2012

  • Run through the wizard until you get to Features
  • Select .NET Framework 3.5 Features and finish the wizard
  • Install all available Windows updates / patches

VirtualBox - Windows Server 2012 Windows Updates

  • Configure Windows Updates to only check and notify if there are updates so we have control of the process.

Next Step

Now that the virtual machine is installed and updated, the next part in this series will walk you through step-by-step how to prep this VM and .vdi for compacting in order to be used as a Linked Clone.

Building the Ultimate VirtualBox Lab – Prep VDI for Compacting

we installed Windows 2012 and made some basic configuration changes.

This article we will be focusing on prepping the VM for compacting the .vdi (virtual hard disk) for  Installing Windows Server 2012 Base for our Building the Ultimate VirtualBox Test Lab series.

It is comprised of deleting some folders/files in order to free up as much space as possible, running sdelete.exe, sysprep, and a few other little changes in order to simplify all future linked clone installations.

Quick reminder: We are setting up linked clones so we can maximize disk usage on our virtual server. If we were to setup normal clones and/or VMs, we would quickly run low on disk space. Since we are using SSDs to store the VDI (virtual hard disk files for our virtualbox VMs), it is very important that we use Linked Clones for this task.

Prep VM for .vdi compacting

Let’s Begin

Windows Update

  • Power on the Windows 2012 VM.
  • Configure Windows Updates to only check and notify if there are updates so we have control of the process.
  • Or… disable it all together and make sure to check/update every month.
    Ultimate-Vbox-Configure-Windows-Updates

Clean-up storage

  • Remove SP (Service Pack) installation files (if any)
    • Launch an elevated cmd or PowerShell window
    • Run: dism /online /cleanup-image /spsuperseded
  • Remove Windows update backup files
    • Launch services
    • Stop Windows Update service
      Ultimate-Vbox-Stop-Windows-Update
    • Delete the following folder and all it’s contents: C:\Windows\SoftwareDistribution
    • Start Windows Update
  • Disable hibernation
    • Launch an elevated cmd or PowerShell window
    • Run: powercfg.exe /hibernate off
  • Defrag two times (If .vdi is on a non-SSD)
  • Run sdelete to prepare for vdi compacting
    • Download sdelete and extract it’s contents
    • Launch an elevated cmd or PowerShell window
    • Change your working directory to the extracted sdelete folder
    • Run: sdelete.exe -z c:
      Ultimate-Vbox-Sdelete

Compact vdi

  • Shutdown VM
  • On the host computer (the Virtual Server):
    • Launch a NON-elevated cmd or PowerShell window
    • Change your working directory to “C:\Program Files\Oracle\VirtualBox\”
    • Run: vboxmanage.exe modifyhd <image path and name>.vdi –compact
      Ultimate-VirtualBox-Lab-Compact-VDI

Prepare VM to be a template

  • Power on the VM
  • Within the VM, run sysprep
    • Launch a cmd or PowerShell window
    • Run: c:\windows\system32\sysprep\sysprep.exe
    • Select: OOBE
    • Select: Generalize
    • Select: Shutdown
      Ultimate-Vbox-Sysprep

At this point you DO NOT want to power on this VM until you are ready to install updates to the base system in the future.

Create Base Snapshot

(All linked clones will be based on this snapshot)

  • Name: Version 1.0
  • Description: Initial version of <Windows version> all patched up to <date>. Sysprep OOBE executed before shutdown.
    Ultimate-Vbox-Snapshot

Set the Base VM not to boot

  • Open the settings for this VM up in VirtualBox
  • System -> Motherboard
  • Boot Order: Uncheck all devices
    This will ensure the Base VM doesn’t accidentally get booted up
    Ultimate-Vbox-Disable-Boot

Next Step

Now that the VM’s virtual hard disk is cleaned up as much as possible and then compacted, the next part will walk you through step-by-step on creating our first Linked Clone

Building the Ultimate VirtualBox Lab – Linked Clones

we prepped our vm and compacted the .vdi to save as much space as possible.

This article, we will be setting up a few servers using the linked clone feature available in VirtualBox.

The reason I am using “linked” clones is because I am installing my lab environment on an SSD drive. Since I didn’t win the lottery or rob a bank, I am somewhat limited on the size of the SSD I can install the VMs on.

Below briefly explains what a full clone is compared to a linked clone. See Virtualbox.org for more information on the cloning process.

Full clone: In this mode all depending disk images are copied to the new VM folder. The clone can fully operate without the source VM.

Linked clone: In this mode new differencing disk images are created where the parent disk images are the source disk images. If you selected the current state of the source VM as clone point, a new snapshot will be created implicitly.

How to Setup Linked Clones

Let’s Begin

Setup a Linked Clone

  • In VirtualBox, right click the Base VM and select Clone
    Ultimate Vbox - Clone
  • Name the VM to your Server naming conventions (I am going to simplify things and name this one DC_1 for Domain Controller)
  • Select Reinitialize the MAC address
    Ultimate VirtualBox - Name and Initialize MAC
  • Select Linked Clone
    Ultimate Vbox - Linked Clone
  • Go into the Settings of the Linked Clone and select Hard Disk for the Boot Order
    Ultimate Vbox - Boot Order

Power-on Your New Linked Clone

You can now start your Linked Clone VM.

Since we SysPrep’ed the Base VMs, the initial boot of the linked clones will go through the standard Windows startup / configuration steps.

Don’t forget you will need to re-setup your IPv4 Static address as well as name the server. I personally like to give the main/first server in my environment a .10 address (i.e. 192.168.1.10). For non-servers, I like to stick with DHCP.

Setup other Base VMs for different operating systems by following the same procedures.
ultimate vbox - setup lots of linked clones

— UPDATE

I ended up enabling Windows Update on all of the linked clones individually rather than on the base system. This is because each linked clone will be running something different (ie. WDS, Exchange, SCCM, SQL, etc…).

Building the Ultimate VirtualBox Lab – RDP to VMs

We will be focusing on setting up pfSense firewall’s port forwarding to allow RDP (Remote Desktop) connections from the host computer (Virtual Server) to the individual virtual machines within VirtualBox’s internal VM network.

Call me weird or old-school but I’m not a huge fan on using the console session of VirtualBox to work on the VMs. Instead I like to use Remote Desktop to connect to the virtual machines.

Follow along in this step-by-step article on how to set up port forwarding through pfSense so we can easily remote desktop to the virtual machines from the host machine.

Disable pfSense’s ‘Block Private Network’ option

  1. Open Internet Explorer in one of your VMs
  2. Connect to your pfSense’s web interface
  3. System -> Setup Wizard
    Ultimate Vbox pfSense Setup Wizard
  4. Continue pressing Next until you get to Configure Wan Interface
  5. Scroll down to the bottom of the page
  6. Uncheck Block RFC1918 Private Networks optionUltimate-Vbox-pfSense-Disable-Block-Private-Network
  7. Continue pressing Next and then Reload to finish the configuration change

Configure NAT rule to allow pfSense to port forward ports to VM’s 3389 MSRDP port

  1. Firewall -> NATUltimate-Vbox-pfSense-Firewall-NAT
  2. Add a NAT port forward by pressing the icon with the plus symbolUltimate-Vbox-pfSense-Add-Port-Forward
  3. Destination: Any
  4. Destination Port Range: From: <whatever port you want to use>
  5. Destination Port Range: To: <leave blank>
  6. Redirect Target IP: <IP Address of the VM you want to connect to>
  7. Redirect Target Port: MS RDP
  8. Description: Remote Desktop to <server name>
  9. Save and then Apply ChangesUltimate-Vbox-pfSense-RDP-Port-Forward-Settings

Now when you want to connect via Remote Desktop, your server address will be:

  1. Server: <pfSense WAN IP>:
  2. Example: Server: 10.2.0.199:3395Remote-Desktop_Specific-Port

For other servers/clients that you want to connect to, simply add another NAT Port Forward rule but use a different Destination Port (ie. 5002, 5003, etc…).

PuppetLabs Firewall – Puppet Firewall Module


firewall

Build Status

Table of Contents

  1. Overview – What is the firewall module?
  2. Module Description – What does the module do?
  3. Setup – The basics of getting started with firewall
    • What firewall Affects
    • Setup Requirements
    • Beginning with firewall
    • Upgrading
  4. Usage – Configuration and customization options
    • Default rules – Setting up general configurations for all firewalls
    • Application-Specific Rules – Options for configuring and managing firewalls across applications
    • Additional Uses for the Firewall Module
  5. Reference – An under-the-hood peek at what the module is doing
  6. Limitations – OS compatibility, etc.
  7. Development – Guide for contributing to the module
    • Tests – Testing your configuration

Overview

The firewall module lets you manage firewall rules with Puppet.

Module Description

PuppetLabs’ firewall module introduces the firewall resource, which is used to manage and configure firewall rules from within the Puppet DSL. This module offers support for iptables and ip6tables. The module also introduces the firewallchain resource, which allows you to manage chains or firewall lists and ebtables for bridging support. At the moment, only iptables and ip6tables chains are supported.

The firewall module acts on your running firewall, making immediate changes as the catalog executes. Defining default pre and post rules allows you to provide global defaults for your hosts before and after any custom rules. Defining pre and post rules is also necessary to help you avoid locking yourself out of your own boxes when Puppet runs.

Setup

What firewall Affects

  • Every node running a firewall
  • Firewall settings in your system
  • Connection settings for managed nodes
  • Unmanaged resources (get purged)

Setup Requirements

Firewall uses Ruby-based providers, so you must enable pluginsync.

Beginning with firewall

In the following two sections, you create new classes and then create firewall rules related to those classes. These steps are optional but provide a framework for firewall rules, which is helpful if you’re just starting to create them.

If you already have rules in place, then you don’t need to do these two sections. However, be aware of the ordering of your firewall rules. The module will dynamically apply rules in the order they appear in the catalog, meaning a deny rule could be applied before the allow rules. This might mean the module hasn’t established some of the important connections, such as the connection to the Puppet master.

The following steps are designed to ensure that you keep your SSH and other connections, primarily your connection to your Puppet master. If you create the pre and post classes described in the first section, then you also need to create the rules described in the second section.

Create the my_fw::pre and my_fw::post Classes

This approach employs a whitelist setup, so you can define what rules you want and everything else is ignored rather than removed.

The code in this section does the following:

  • The ‘require’ parameter in firewall {} ensures my_fw::pre is run before any other rules.
  • In the my_fw::post class declaration, the ‘before’ parameter ensures my_fw::post is run after any other rules.

Therefore, the run order is:

  • The rules in my_fw::pre
  • Your rules (defined in code)
  • The rules in my_fw::post

The rules in the pre and post classes are fairly general. These two classes ensure that you retain connectivity and that you drop unmatched packets appropriately. The rules you define in your manifests are likely specific to the applications you run.

1.) Add the pre class to my_fw/manifests/pre.pp. Your pre.pp file should contain any default rules to be applied first. The rules in this class should be added in the order you want them to run.2.

  class my_fw::pre {
    Firewall {
      require => undef,
    }

    # Default firewall rules
    firewall { '000 accept all icmp':
      proto   => 'icmp',
      action  => 'accept',
    }->
    firewall { '001 accept all to lo interface':
      proto   => 'all',
      iniface => 'lo',
      action  => 'accept',
    }->
    firewall { "002 reject local traffic not on loopback interface":
      iniface     => '! lo',
      proto       => 'all',
      destination => '127.0.0.1/8',
      action      => 'reject',
    }->
    firewall { '003 accept related established rules':
      proto   => 'all',
      state => ['RELATED', 'ESTABLISHED'],
      action  => 'accept',
    }
  }

The rules in pre should allow basic networking (such as ICMP and TCP) and ensure that existing connections are not closed.

2.) Add the post class to my_fw/manifests/post.pp and include any default rules to be applied last.

  class my_fw::post {
    firewall { '999 drop all':
      proto   => 'all',
      action  => 'drop',
      before  => undef,
    }
  }

Alternatively, the firewallchain type can be used to set the default policy:

  firewallchain { 'INPUT:filter:IPv4':
    ensure => present,
    policy => drop,
    before => undef,
  }

Create Firewall Rules

The rules you create here are helpful if you don’t have any existing rules; they help you order your firewall configurations so you don’t lock yourself out of your box.

Rules are persisted automatically between reboots, although there are known issues with ip6tables on older Debian/Ubuntu distributions. There are also known issues with ebtables.

1.) In site.pp or another top-scope file, add the following code to set up a metatype to purge unmanaged firewall resources. This will clear any existing rules and make sure that only rules defined in Puppet exist on the machine.

Note – This only purges IPv4 rules.

  resources { 'firewall':
    purge => true
  }

To purge unmanaged firewall chains, also add:

  resources { 'firewallchain':
    purge => true
  }

Note – If there are unmanaged rules in unmanaged chains it will take two Puppet runs before the firewall chain is purged. This is different than the purge parameter available in firewallchain.

2.) Use the following code to set up the default parameters for all of the firewall rules you will establish later. These defaults will ensure that the pre and post classes are run in the correct order to avoid locking you out of your box during the first Puppet run.

  Firewall {
    before  => Class['my_fw::post'],
    require => Class['my_fw::pre'],
  }

3.) Then, declare the my_fw::pre and my_fw::post classes to satisfy dependencies. You can declare these classes using an External Node Classifier or the following code:

  class { ['my_fw::pre', 'my_fw::post']: }

4.) Include the firewall class to ensure the correct packages are installed.

  class { 'firewall': }

Upgrading

Use these steps if you already have a version of the firewall module installed.

From version 0.2.0 and more recent

Upgrade the module with the puppet module tool as normal:

puppet module upgrade puppetlabs/firewall

Usage

There are two kinds of firewall rules you can use with firewall: default rules and application-specific rules. Default rules apply to general firewall settings, whereas application-specific rules manage firewall settings for a specific application, node, etc.

All rules employ a numbering system in the resource’s title that is used for ordering. When titling your rules, make sure you prefix the rule with a number, for example, ‘000 accept all icmp requests’. 000runs first, 999 runs last.

Default Rules

You can place default rules in either my_fw::pre or my_fw::post, depending on when you would like them to run. Rules placed in the pre class will run first, and rules in the post class, last.

In iptables, the title of the rule is stored using the comment feature of the underlying firewall subsystem. Values must match ‘/^\d+[[:alpha:][:digit:][:punct:][:space:]]+$/’.

Examples of Default Rules

Basic accept ICMP request example:

firewall { "000 accept all icmp requests":
  proto  => "icmp",
  action => "accept",
}

Drop all:

firewall { "999 drop all other requests":
  action => "drop",
}

Example of an IPv6 rule

IPv6 rules can be specified using the ip6tables provider:

firewall { "006 Allow inbound SSH (v6)":
  port     => 22,
  proto    => tcp,
  action   => accept,
  provider => 'ip6tables',
}

Application-Specific Rules

Puppet doesn’t care where you define rules, and this means that you can place your firewall resources as close to the applications and services that you manage as you wish. If you use theroles and profiles pattern then it makes sense to create your firewall rules in the profiles, so they remain close to the services managed by the profile.

This is an example of firewall rules in a profile:

class profile::apache {
  include apache
  apache::vhost { 'mysite': ensure => present }

  firewall { '100 allow http and https access':
    port   => [80, 443],
    proto  => tcp,
    action => accept,
  }
}

Rule inversion

Firewall rules may be inverted by prefixing the value of a parameter by “! “. If the value is an array, then every item in the array must be prefixed as iptables does not understand inverting a single value.

Parameters that understand inversion are: connmark, ctstate, destination, dport, dst_range, dst_type, iniface, outiface, port, proto, source, sport, src_range, src_type, and state.

Examples:

firewall { '001 disallow esp protocol':
  action => 'accept',
  proto  => '! esp',
}
firewall { '002 drop NEW external website packets with FIN/RST/ACK set and SYN unset':
  chain     => 'INPUT',
  state     => 'NEW',
  action    => 'drop',
  proto     => 'tcp',
  sport     => ['! http', '! 443'],
  source    => '! 10.0.0.0/8',
  tcp_flags => '! FIN,SYN,RST,ACK SYN',
}

Additional Uses for the Firewall Module

You can apply firewall rules to specific nodes. Usually, you will want to put the firewall rule in another class and apply that class to a node. Apply a rule to a node as follows:

node 'some.node.com' {
  firewall { '111 open port 111':
    dport => 111
  }
}

You can also do more complex things with the firewall resource. This example sets up static NAT for the source network 10.1.2.0/24:

firewall { '100 snat for network foo2':
  chain    => 'POSTROUTING',
  jump     => 'MASQUERADE',
  proto    => 'all',
  outiface => "eth0",
  source   => '10.1.2.0/24',
  table    => 'nat',
}

The following example creates a new chain and forwards any port 5000 access to it.

firewall { '100 forward to MY_CHAIN':
  chain   => 'INPUT',
  jump    => 'MY_CHAIN',
}
# The namevar here is in the format chain_name:table:protocol
firewallchain { 'MY_CHAIN:filter:IPv4':
  ensure  => present,
}
firewall { '100 my rule':
  chain   => 'MY_CHAIN',
  action  => 'accept',
  proto   => 'tcp',
  dport   => 5000,
}

Additional Information

Access the inline documentation:

puppet describe firewall

Or

puppet doc -r type
(and search for firewall)

Reference

Classes:

Types:

Facts:

Class: firewall

Performs the basic setup tasks required for using the firewall resources.

At the moment this takes care of:

  • iptables-persistent package installation

Include the firewall class for nodes that need to use the resources in this module:

class { 'firewall': }

ensure

Parameter that controls the state of the iptables service on your system, allowing you to disable iptables if you want.

ensure can either be ‘running’ or ‘stopped’. Default to ‘running’.

package

Specify the platform-specific package(s) to install. Defaults defined in firewall::params.

service

Specify the platform-specific service(s) to start or stop. Defaults defined in firewall::params.

Type: firewall

This type enables you to manage firewall rules within Puppet.

Providers

Note: Not all features are available with all providers.

  • ip6tables: Ip6tables type provider
    • Required binaries: ip6tables-save, ip6tables.
    • Supported features: address_type, connection_limiting, dnat, hop_limiting, icmp_match,interface_match, iprange, ipsec_dir, ipsec_policy, ipset, iptables, isfirstfrag, ishasmorefrags, islastfrag,log_level, log_prefix, mark, mask, owner, pkttype, rate_limiting, recent_limiting, reject_type, snat, socket,state_match, tcp_flags.
  • iptables: Iptables type provider
    • Required binaries: iptables-save, iptables.
    • Default for kernel == linux.
    • Supported features: address_type, connection_limiting, dnat, icmp_match, interface_match, iprange,ipsec_dir, ipsec_policy, ipset, iptables, isfragment, log_level, log_prefix, mark, mask, netmap, owner,pkttype, rate_limiting, recent_limiting, reject_type, snat, socket, state_match, tcp_flags.

Autorequires:

If Puppet is managing the iptables or ip6tables chains specified in the chain or jump parameters, the firewall resource will autorequire those firewallchain resources.

If Puppet is managing the iptables or iptables-persistent packages, and the provider is iptables or ip6tables, the firewall resource will autorequire those packages to ensure that any required binaries are installed.

Features

  • address_type: The ability to match on source or destination address type.
  • connection_limiting: Connection limiting features.
  • dnat: Destination NATing.
  • hop_limiting: Hop limiting features.
  • icmp_match: The ability to match ICMP types.
  • interface_match: Interface matching.
  • iprange: The ability to match on source or destination IP range.
  • ipsec_dir: The ability to match IPsec policy direction.
  • ipsec_policy: The ability to match IPsec policy.
  • iptables: The provider provides iptables features.
  • isfirstfrag: The ability to match the first fragment of a fragmented ipv6 packet.
  • isfragment: The ability to match fragments.
  • ishasmorefrags: The ability to match a non-last fragment of a fragmented ipv6 packet.
  • islastfrag: The ability to match the last fragment of an ipv6 packet.
  • log_level: The ability to control the log level.
  • log_prefix: The ability to add prefixes to log messages.
  • mark: The ability to match or set the netfilter mark value associated with the packet.
  • mask: The ability to match recent rules based on the ipv4 mask.
  • owner: The ability to match owners.
  • pkttype: The ability to match a packet type.
  • rate_limiting: Rate limiting features.
  • recent_limiting: The netfilter recent module.
  • reject_type: The ability to control reject messages.
  • snat: Source NATing.
  • socket: The ability to match open sockets.
  • state_match: The ability to match stateful firewall states.
  • tcp_flags: The ability to match on particular TCP flag settings.
  • netmap: The ability to map entire subnets via source or destination nat rules.

Parameters

  • action: This is the action to perform on a match. Valid values for this action are:
    • ‘accept’: The packet is accepted.
    • ‘reject’: The packet is rejected with a suitable ICMP response.
    • ‘drop’: The packet is dropped.

    If you specify no value it will simply match the rule but perform no action unless you provide a provider-specific parameter (such as jump).

  • burst: Rate limiting burst value (per second) before limit checks apply. Values must match ‘/^\d+$/’. Requires the rate_limiting feature.
  • chain: Name of the chain to use. You can provide a user-based chain or use one of the following built-in chains:’INPUT’,’FORWARD’,’OUTPUT’,’PREROUTING’, or ‘POSTROUTING’. The default value is ‘INPUT’. Values must match ‘/^[a-zA-Z0-9-_]+$/’. Requires the iptables feature.
    • checksum_fill: When using a jump value of ‘CHECKSUM’ this boolean will make sure that a checksum is calculated and filled in a packet that lacks a checksum. Valid values are true or false. Requires the iptables feature.
  • connlimit_above: Connection limiting value for matched connections above n. Values must match ‘/^\d+$/’. Requires the connection_limiting feature.
  • connlimit_mask: Connection limiting by subnet mask for matched connections. Apply a subnet mask of /0 to /32 for IPv4, and a subnet mask of /0 to /128 for IPv6. Values must match ‘/^\d+$/’. Requires the connection_limiting feature.
  • connmark: Match the Netfilter mark value associated with the packet. Accepts values mark/maskor mark. These will be converted to hex if they are not hex already. Requires the mark feature.
  • ctstate: Matches a packet based on its state in the firewall stateful inspection table, using the conntrack module. Valid values are: ‘INVALID’, ‘ESTABLISHED’, ‘NEW’, ‘RELATED’. Requires the state_match feature.
  • destination: The destination address to match. For example: destination => '192.168.1.0/24'. You can also negate a mask by putting ! in front. For example: destination => '! 192.168.2.0/24'. The destination can also be an IPv6 address if your provider supports it.

    For some firewall providers you can pass a range of ports in the format: ‘start number-end number’. For example, ‘1-1024’ would cover ports 1 to 1024.

  • dport: The destination port to match for this filter (if the protocol supports ports). Will accept a single element or an array. For some firewall providers you can pass a range of ports in the format: ‘start number-end number’. For example, ‘1-1024’ would cover ports 1 to 1024.
  • dst_range: The destination IP range. For example: dst_range => '192.168.1.1-192.168.1.10'.

    The destination IP range is must in ‘IP1-IP2’ format. Values in the range must be valid IPv4 or IPv6 addresses. Requires the iprange feature.

  • dst_type: The destination address type. For example: dst_type => 'LOCAL'.

    Valid values are:

    • ‘UNSPEC’: an unspecified address
    • ‘UNICAST’: a unicast address
    • ‘LOCAL’: a local address
    • ‘BROADCAST’: a broadcast address
    • ‘ANYCAST’: an anycast packet
    • ‘MULTICAST’: a multicast address
    • ‘BLACKHOLE’: a blackhole address
    • ‘UNREACHABLE’: an unreachable address
    • ‘PROHIBIT’: a prohibited address
    • ‘THROW’: an unroutable address
    • ‘XRESOLVE: an unresolvable address

    Requires the address_type feature.

  • ensure: Ensures that the resource is present. Valid values are ‘present’, ‘absent’. The default is ‘present’.
  • gid: GID or Group owner matching rule. Accepts a string argument only, as iptables does not accept multiple gid in a single statement. Requires the owner feature.
  • hop_limit: Hop limiting value for matched packets. Values must match ‘/^\d+$/’. Requires thehop_limiting feature.
  • icmp: When matching ICMP packets, this indicates the type of ICMP packet to match. A value of ‘any’ is not supported. To match any type of ICMP packet, the parameter should be omitted or undefined. Requires the icmp_match feature.
  • iniface: Input interface to filter on. Values must match ‘/^!?\s?[a-zA-Z0-9-._+:]+$/’. Requires theinterface_match feature. Supports interface alias (eth0:0) and negation.
  • ipsec_dir: Sets the ipsec policy direction. Valid values are ‘in’, ‘out’. Requires the ipsec_dir feature.
  • ipsec_policy: Sets the ipsec policy type. Valid values are ‘none’, ‘ipsec’. Requires the ipsec_policyfeature.
  • ipset: Matches IP sets. Value must be ‘ipset_name (src|dst|src,dst)’ and can be negated by putting ! in front. Requires ipset kernel module.
  • isfirstfrag: If true, matches when the packet is the first fragment of a fragmented ipv6 packet. Cannot be negated. Supported by ipv6 only. Valid values are ‘true’, ‘false’. Requires the isfirstfragfeature.
  • isfragment: If ‘true’, matches when the packet is a tcp fragment of a fragmented packet. Supported by iptables only. Valid values are ‘true’, ‘false’. Requires features isfragment.
  • ishasmorefrags: If ‘true’, matches when the packet has the ‘more fragments’ bit set. Supported by ipv6 only. Valid values are ‘true’, ‘false’. Requires the ishasmorefrags feature.
  • islastfrag: If true, matches when the packet is the last fragment of a fragmented ipv6 packet. Supported by ipv6 only. Valid values are ‘true’, ‘false’. Requires the islastfrag.
  • jump: The value for the iptables --jump parameter. Any valid chain name is allowed, but normal values are: ‘QUEUE’, ‘RETURN’, ‘DNAT’, ‘SNAT’, ‘LOG’, ‘MASQUERADE’, ‘REDIRECT’, ‘MARK’.

    For the values ‘ACCEPT’, ‘DROP’, and ‘REJECT’, you must use the generic action parameter. This is to enforce the use of generic parameters where possible for maximum cross-platform modeling.

    If you set both accept and jump parameters, you will get an error, because only one of the options should be set. Requires the iptables feature.

  • limit: Rate limiting value for matched packets. The format is: ‘rate/[/second/|/minute|/hour|/day]’. Example values are: ’50/sec’, ’40/min’, ’30/hour’, ’10/day’. Requires the rate_limiting feature.
  • line: Read-only property for caching the rule line.
  • log_level: When combined with jump => 'LOG' specifies the system log level to log to. Requires thelog_level feature.
  • log_prefix: When combined with jump => 'LOG' specifies the log prefix to use when logging. Requires the log_prefix feature.
  • mask: Sets the mask to use when recent is enabled. Requires the mask feature.
  • name: The canonical name of the rule. This name is also used for ordering, so make sure you prefix the rule with a number. For example:
firewall { '000 this runs first':
  # this rule will run first
}
firewall { '999 this runs last':
  # this rule will run last
}

Depending on the provider, the name of the rule can be stored using the comment feature of the underlying firewall subsystem. Values must match ‘/^\d+[[:alpha:][:digit:][:punct:][:space:]]+$/’.

  • outiface: Output interface to filter on. Values must match ‘/^!?\s?[a-zA-Z0-9-._+:]+$/’. Requires the interface_match feature. Supports interface alias (eth0:0) and negation.
  • physdev_in: Match if the packet is entering a bridge from the given interface. Values must match ‘/^[a-zA-Z0-9-._+]+$/’.
  • physdev_out: Match if the packet is leaving a bridge via the given interface. Values must match ‘/^[a-zA-Z0-9-._+]+$/’.
  • physdev_is_bridged: Match if the packet is transversing a bridge. Valid values are true or false.
  • pkttype: Sets the packet type to match. Valid values are: ‘unicast’, ‘broadcast’, and’multicast’. Requires the pkttype feature.
  • port: The destination or source port to match for this filter (if the protocol supports ports). Will accept a single element or an array. For some firewall providers you can pass a range of ports in the format: ‘start number-end number’. For example, ‘1-1024’ would cover ports 1 to 1024.
  • proto: The specific protocol to match for this rule. This is ‘tcp’ by default. Valid values are:
    • ‘tcp’
    • ‘udp’
    • ‘icmp’
    • ‘ipv4’
    • ‘ipv6’
    • ‘ipv6-icmp’
    • ‘esp’
    • ‘ah’
    • ‘vrrp’
    • ‘igmp’
    • ‘ipencap’
    • ‘ospf’
    • ‘gre’
    • ‘all’
  • provider: The specific backend to use for this firewall resource. You will seldom need to specify this — Puppet will usually discover the appropriate provider for your platform. Available providers are ip6tables and iptables. See the Providers section above for details about these providers.
    • random: When using a jump value of ‘MASQUERADE’, ‘DNAT’, ‘REDIRECT’, or ‘SNAT’, this boolean will enable randomized port mapping. Valid values are true or false. Requires thednat feature.
  • rdest: If boolean ‘true’, adds the destination IP address to the list. Valid values are true or false. Requires the recent_limiting feature and the recent parameter.
  • reap: Can only be used in conjunction with the rseconds parameter. If boolean ‘true’, this will purge entries older than ‘seconds’ as specified in rseconds. Valid values are true or false. Requires the recent_limiting feature and the recent parameter.
  • recent: Enable the recent module. Valid values are: ‘set’, ‘update’, ‘rcheck’, or ‘remove’. For example:
# If anyone's appeared on the 'badguy' blacklist within
# the last 60 seconds, drop their traffic, and update the timestamp.
firewall { '100 Drop badguy traffic':
  recent   => 'update',
  rseconds => 60,
  rsource  => true,
  rname    => 'badguy',
  action   => 'DROP',
  chain    => 'FORWARD',
}
# No-one should be sending us traffic on eth0 from localhost
# Blacklist them
firewall { '101 blacklist strange traffic':
  recent      => 'set',
  rsource     => true,
  rname       => 'badguy',
  destination => '127.0.0.0/8',
  iniface     => 'eth0',
  action      => 'DROP',
  chain       => 'FORWARD',
}

Requires the recent_limiting feature.

  • reject: When combined with jump => 'REJECT', you can specify a different ICMP response to be sent back to the packet sender. Requires the reject_type feature.
  • rhitcount: Used in conjunction with recent => 'update' or recent => 'rcheck'. When used, this will narrow the match to happen only when the address is in the list and packets greater than or equal to the given value have been received. Requires the recent_limiting feature and the recent parameter.
  • rname: Specify the name of the list. Takes a string argument. Requires the recent_limiting feature and the recent parameter.
  • rseconds: Used in conjunction with recent => 'rcheck' or recent => 'update'. When used, this will narrow the match to only happen when the address is in the list and was seen within the last given number of seconds. Requires the recent_limiting feature and the recent parameter.
  • rsource: If boolean ‘true’, adds the source IP address to the list. Valid values are ‘true’, ‘false’. Requires the recent_limiting feature and the recent parameter.
  • rttl: May only be used in conjunction with recent => 'rcheck' or recent => 'update'. If boolean ‘true’, this will narrow the match to happen only when the address is in the list and the TTL of the current packet matches that of the packet that hit the recent => 'set' rule. If you have problems with DoS attacks via bogus packets from fake source addresses, this parameter may help. Valid values are ‘true’, ‘false’. Requires the recent_limiting feature and the recent parameter.
  • set_mark: Set the Netfilter mark value associated with the packet. Accepts either ‘mark/mask’ or ‘mark’. These will be converted to hex if they are not already. Requires the mark feature.
  • socket: If ‘true’, matches if an open socket can be found by doing a socket lookup on the packet. Valid values are ‘true’, ‘false’. Requires the socket feature.
  • source: The source address. For example: source => '192.168.2.0/24'. You can also negate a mask by putting ! in front. For example: source => '! 192.168.2.0/24'. The source can also be an IPv6 address if your provider supports it.
  • sport: The source port to match for this filter (if the protocol supports ports). Will accept a single element or an array. For some firewall providers you can pass a range of ports in the format:’start number-end number’. For example, ‘1-1024’ would cover ports 1 to 1024.
  • src_range: The source IP range. For example: src_range => '192.168.1.1-192.168.1.10'. The source IP range must be in ‘IP1-IP2’ format. Values in the range must be valid IPv4 or IPv6 addresses. Requires the iprange feature.
  • src_type: Specify the source address type. For example: src_type => 'LOCAL'.

    Valid values are:

    • ‘UNSPEC’: an unspecified address.
    • ‘UNICAST’: a unicast address.
    • ‘LOCAL’: a local address.
    • ‘BROADCAST’: a broadcast address.
    • ‘ANYCAST’: an anycast packet.
    • ‘MULTICAST’: a multicast address.
    • ‘BLACKHOLE’: a blackhole address.
    • ‘UNREACHABLE’: an unreachable address.
    • ‘PROHIBIT’: a prohibited address.
    • ‘THROW’: an unroutable address.
    • ‘XRESOLVE’: an unresolvable address.

    Requires the address_type feature.

  • stat_every: Match one packet every nth packet. Requires stat_mode => 'nth'
  • stat_mode: Set the matching mode for statistic matching. Supported modes are random and nth.
  • stat_packet: Set the initial counter value for the nth mode. Must be between 0 and the value ofstat_every. Defaults to 0. Requires stat_mode => 'nth'
  • stat_probability: Set the probability from 0 to 1 for a packet to be randomly matched. It works only with stat_mode => 'random'.
  • state: Matches a packet based on its state in the firewall stateful inspection table. Valid values are: ‘INVALID’, ‘ESTABLISHED’, ‘NEW’, ‘RELATED’. Requires the state_match feature.
  • table: Table to use. Valid values are: ‘nat’, ‘mangle’, ‘filter’, ‘raw’, ‘rawpost’. By default the setting is ‘filter’. Requires the iptables feature.
  • tcp_flags: Match when the TCP flags are as specified. Set as a string with a list of comma-separated flag names for the mask, then a space, then a comma-separated list of flags that should be set. The flags are: ‘SYN’, ‘ACK’, ‘FIN’, ‘RST’, ‘URG’, ‘PSH’, ‘ALL’, ‘NONE’.

    Note that you specify flags in the order that iptables --list rules would list them to avoid having Puppet think you changed the flags. For example, ‘FIN,SYN,RST,ACK SYN’ matches packets with the SYN bit set and the ACK, RST and FIN bits cleared. Such packets are used to request TCP connection initiation. Requires the tcp_flags feature.

  • todest: When using jump => 'DNAT', you can specify the new destination address using this parameter. Requires the dnat feature.
  • toports: For DNAT this is the port that will replace the destination port. Requires the dnat feature.
  • tosource: When using jump => 'SNAT', you can specify the new source address using this parameter. Requires the snat feature.
  • to: When using jump => 'NETMAP', you can specify a source or destination subnet to nat to. Requires the netmap feature`.
  • uid: UID or Username owner matching rule. Accepts a string argument only, as iptables does not accept multiple uid in a single statement. Requires the owner feature.

Type: firewallchain

Enables you to manage rule chains for firewalls.

Currently this type supports only iptables, ip6tables, and ebtables on Linux. It also provides support for setting the default policy on chains and tables that allow it.

Autorequires: If Puppet is managing the iptables or iptables-persistent packages, and the provider is iptables_chain, the firewall resource will autorequire those packages to ensure that any required binaries are installed.

Providers

iptables_chain is the only provider that supports firewallchain.

Features

  • iptables_chain: The provider provides iptables chain features.
  • policy: Default policy (inbuilt chains only).

Parameters

  • ensure: Ensures that the resource is present. Valid values are ‘present’, ‘absent’.
  • ignore: Regex to perform on firewall rules to exempt unmanaged rules from purging (when enabled). This is matched against the output of iptables-save. This can be a single regex or an array of them. To support flags, use the ruby inline flag mechanism: a regex such as ‘/foo/i’ can be written as ‘(?i)foo’ or ‘(?i:foo)’. Only when purge is ‘true’.

    Full example:

firewallchain { 'INPUT:filter:IPv4':
  purge  => true,
  ignore => [
    # ignore the fail2ban jump rule
    '-j fail2ban-ssh',
    # ignore any rules with "ignore" (case insensitive) in the comment in the rule
    '--comment "[^"](?i:ignore)[^"]"',
    ],
}
  • name: Specify the canonical name of the chain. For iptables the format must be {chain}:{table}:{protocol}.
  • policy: Set the action the packet will perform when the end of the chain is reached. It can only be set on inbuilt chains (‘INPUT’, ‘FORWARD’, ‘OUTPUT’, ‘PREROUTING’, ‘POSTROUTING’). Valid values are:
    • ‘accept’: The packet is accepted.
    • ‘drop’: The packet is dropped.
    • ‘queue’: The packet is passed userspace.
    • ‘return’: The packet is returned to calling (jump) queue or to the default of inbuilt chains.
  • provider: The specific backend to use for this firewallchain resource. You will seldom need to specify this — Puppet will usually discover the appropriate provider for your platform. The only available provider is:

    iptables_chain: iptables chain provider

    • Required binaries: ebtables-save, ebtables, ip6tables-save, ip6tables, iptables-save, iptables.
    • Default for kernel == linux.
    • Supported features: iptables_chain, policy.
  • purge: Purge unmanaged firewall rules in this chain. Valid values are ‘false’, ‘true’.

Note This purge is purging unmanaged rules in a firewall chain, not unmanaged firewall chains. To purge unmanaged firewall chains, use the following instead.

resources { 'firewallchain':
  purge => true
}

Fact: ip6tables_version

A Facter fact that can be used to determine what the default version of ip6tables is for your operating system/distribution.

Fact: iptables_version

A Facter fact that can be used to determine what the default version of iptables is for your operating system/distribution.

Fact: iptables_persistent_version

Retrieves the version of iptables-persistent from your OS. This is a Debian/Ubuntu specific fact.

Limitations

SLES

The socket parameter is not supported on SLES. In this release it will cause the catalog to fail with iptables failures, rather than correctly warn you that the features are unusable.

Oracle Enterprise Linux

The socket and owner parameters are unsupported on Oracle Enterprise Linux when the “Unbreakable” kernel is used. These may function correctly when using the stock RedHat kernel instead. Declaring either of these parameters on an unsupported system will result in iptable rules failing to apply.

Other

Bugs can be reported using JIRA issues

http://tickets.puppetlabs.com

Development

Puppet Labs modules on the Puppet Forge are open projects, and community contributions are essential for keeping them great. We can’t access the huge number of platforms and myriad of hardware, software, and deployment configurations that Puppet is intended to serve.

We want to keep it as easy as possible to contribute changes so that our modules work in your environment. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.

You can read the complete module contribution guide on the Puppet Labs wiki.

For this particular module, please also read CONTRIBUTING.md before contributing.

Currently we support:

  • iptables
  • ip6tables
  • ebtables (chains only)

Testing

Make sure you have:

  • rake
  • bundler

Install the necessary gems:

bundle install

And run the tests from the root of the source code:

rake test

If you have a copy of Vagrant 1.1.0 you can also run the system tests:

RS_SET=ubuntu-1404-x64 rspec spec/acceptance
RS_SET=centos-64-x64 rspec spec/acceptance


More information can be found on: https://github.com/puppetlabs/puppetlabs-firewall and on http://forge.puppetlabs.com/puppetlabs/firewall

Advanced FireWall cookbook for Chef and Linux that uses Iptables and to dynamically configure inbound and outbound rules on each node.


The Advanced FireWall (afw) for Chef

__A__dvanced __F__ire__W__all (AFW) for Chef and Linux that uses Iptables to dynamically configure inbound and outbound rules on nodes.

AFW uses Chef searches extensively to open access to systems. Instead of specifying the IP addresses of a set of sources or destinations, AFW allows you to specify searches in Chef syntax to list those systems. It is designed to be a lot more dynamic and maintainable than regular firewalls, and allows for filtering inbound and outbound traffic.

AFW support raw rules, that are just straight iptables syntax passed to the template. For these, Chef searches are not supported, but it gives you access to the full set of features iptables provides.

AFW runs on any Linux 2.6 or 3.x. It does not rely on distribution specific wrapper, such as ufw for ubuntu, but calls iptables-restore directly.

Rules definitions

Rules must be added in roles or nodes attributes. A typical rule looks like:

:afw =>
  :rules =>
    'MongoDB App Entry Point' => {
      :protocol => 'tcp',
      :direction => 'in',
      :interface => 'default',
      :user => 'mongodb',
      :source => ['(roles:*webserver-node OR roles:*database-node OR roles:*api-node) AND SAMETAG',
                  '10.4.76.2',
                  'backup-server.example.net']
      :dport => '27017'
    },
}

Rules must be added into node[:afw][:rules], and follow this syntax:


:afw =>
  :rules =>
    '<rule name>' =>
      :direction => '<in|out>',
      :protocol => '<udp|tcp|icmp>',
      :user => '<local user from /etc/passwd>',
      :interface => '<default|all|eth0|eth1|br0|...>',
      :source => '<ip|fqdn|chef search>|['<ip|fqdn|chef search>',...]'>',
      :sport => '<integer(:integer))>',
      :destination => '<ip|fqdn|chef search>|['<ip|fqdn|chef search>',...]'>',
      :dport => '<integer(:integer)>',
      :env => '<production|staging|...>',
      :options => ['disable_env_limit', 'disable_syntax_check', ...]
}

  • Rule Name : A string that identifies the rule as uniquely as possible.
  • direction (mandatory): in is for inbound firewall rules. out for outbound firewall rules. Select whether the rule will apply to packets entering the system (in) or leaving it (out).
  • protocol (mandatory): Select the L4 protocol this rule applies to: udp, tcp or icmp.
  • user (mandatory): Set the local user allowed to transmit packets. The user is checked only for outbound firewall rules (iptables limitation) but must be set for inbound rules as well, to ease auditing rules & systems. Note: if the local user doesn’t exists, the provisioning will fail at the end, when the rules are loaded. If the user is installed by a package, the next chef run will succeed and fix the issue.
  • dport (mandatory): Set the destination port of the connections being filtered. This is mandatory. Except when it’s not (eg. icmp).
  • interface (optional): Select the network interface. If absent of set to all, the interface parameter won’t be set at all, setting the rule on all interfaces.
  • source (mandatory for in rules): Set the source IP of the packets. This parameter can either be a single IP or network (eg. 10.1.2.0/32), a Fully Qualified Domain Name (eg. bob.mydomain.com) or a Chef Search (eg. roles:mongodb). By default, searches are limited to the same chef_environment(eg. staging), to allow for firewall rules that open connections between environments, you will need an heresy parameter. In a chef-search, you can also use they keyword SAMETAG that will limit the search to the nodes that share the same tags. This is useful if, for example, you want to open connections to a database from all nodes within the same service tag, but not beyond. The syntax for a search would look like: ‘roles:whatever-api AND SAMETAG’. If you have multiple sources and destinations, you can set them in a array:
'AMQP Producers' => {
  :direction => 'in',
  :user => 'rabbitmq',
  :protocol => 'tcp',
  :interface => 'default',
  :source => ['producer1.internal.domain.com',
              'producer2.internal.domain.com',
              '192.168.1.1',
              'roles:megaserver'],
  :dport => '5672'
}
  • destination (Same as source)
  • sport (optional): Set the source port in the firewall rule. For in rules, that means the source port of the remote machine. For out rules, that means the source port of this node when establishing a connection to a remote node.
  • env (optional): The env parameters can be used to limit the application of a rule to a specific environment. If :env => 'staging' is set, the rule will be applied to nodes in the staging environment only.
  • options (optional):
  • disable_env_limit: disable_env_limit can also used to cross environment. If :options => ['disable_env_limit'] is set, the source and destination searches will return results from all environments, instead of limiting the result to the environment the node lives in. The following rule will allow production workers to connect to staging BackendDB. Don’t do that. Keep environments isolated as much as possible.
      'Production Worker to Staging BackendDB' => {
        :protocol => 'tcp',
        :direction => 'out',
        :user => 'application-user',
        :destination => 'roles:*backenddb* AND SAMETAG AND chef_environment:staging',
        :dport => '15017',
        :env => 'production',
        :options => ['disable_env_limit']
      }
  • disable_syntax_check: disable_syntax_check will turn off the rule validation step for a specific rule. This is useful if you want to define a rule without source/destination, and let another recipe populate the source/destination arrays later on.
      'API calls from servers' => {
        :protocol => 'tcp',
        :direction => 'in',
        :user => 'www-data',
        :dport => '80',
        :options => ['disable_syntax_check']
      },

You would then have a separate recipe that inserts IPs in this rule:

node[:afw][:rules]['API calls from servers'][:source] = []
ip_list = ['1.2.3.4', '4.5.6.7', '12.32.43.54']
ip_list.each do |ip|
  node[:afw][:rules]['API calls from servers'][:source].push(ip)
end

Creating rules from external cookbooks

If you want a cookbook to create firewal rules directly, as opposed to storing these rules in a roles, then you need to use the create_rule() function from the AFW module. Example: create outbound firewall rule for haproxy in the haproxy cookbook

depend in AFW in the metadata

cookbooks/haproxy/metadata.rb

[...]
depends 'AFW'

create the rule from the recipe using ruby

 # Call the AFW module to create the rule
 AFW.create_rule(node,
                 "Haproxy outbound to #{destination}:#{port}",
                 {'protocol' => 'tcp',
                  'direction' => 'out',
                  'user' => 'haproxy',
                  'destination' => "#{destination}",
                  'dport' => "#{port}"
                 })

Note that AFW.create_rule() must be called from a normal section of ruby code directly (not from aruby_block) to ensure that the rules are compiled at chef compile time. The AFW template will later (at runtime) populate these rules into the iptables-restore file.

preventing rule cleanup

The rules on the Chef server node object will be removed upon successfull execution of the cookbook. The point of cleaning up is to avoid stale rules that could be deleted from the definitions (roles & cookbooks) but survive in the node attributes forever.

You can change this behaviour. One of the scenarios where you would like to do so would be applying the rules from outside of cookbooks, with an external tool perhaps.

To disable automatic cleanup simply set this on the node:

node['afw']['enable_rules_cleanup'] = false

Please remember: You will have to remove unwanted rules manually.

Predefined rules

Predefined rules are iptables rules that are used directly by AFW. Those rules are used for specific purposes only, such as using a very particular module for which AFW wouldn’t have any support. Predefined rules only support 2 arguments: table and rule.

  • table: the netfilter table on which this rule must be applied. One of nat, raw, mangle or `filter.
  • rule: the firewall rule itself, in iptables-save format (do not specify a table in this format, or it will fail).

example:

  :afw => {
    :rules => {

      'Accept all packets router through the bridge' => {
        :table => 'filter',
        :rule => '-I FORWARD -o br0 -m physdev --physdev-is-bridged -j ACCEPT'
      },

      'Drop connection to the admin panel on the eth0 interface' => {
        :table => 'mangle',
        :rule => '-A INPUT -i eth0 -p tcp --dport 80 -m string --string "get /admin http/1.1" --icase --algo bm -m conntrack --ctstate ESTABLISHED -j DROP'
      },

      'DNAT a source IP to change the destination port' => {
        :table => 'nat',
        :rule => '-A PREROUTING -i eth3 -s 201.23.72.3 -p tcp --dport 8008 -j DNAT --to-destination 127.0.0.1:1234'
      },

      'Dont do conntrack on this specific user's UDP packets' => {
        :table => 'raw',
        :rule => '-A OUTPUT -o eth0 -p udp -m owner --uid-owner 105 -j NOTRACK'
      }
    }
  }

Rules Generation

The recipe will generate a rule file in /etc/firewall/rules.iptables that conforms to the iptables-save/restore syntax. At the end of the chef-run, and if the rules file has been modified during the run, the iptables-restore command will reload the entire ruleset.

Here’s an example of templated ruleset. Notice how the rules are regrouped by system user, to make them easier to read.

# Generated by AFW on Tue Sep 25 02:55:32 +0000 2012

*raw
:PREROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A OUTPUT -o lo -j NOTRACK
-A PREROUTING -i lo -j NOTRACK
COMMIT

*mangle
:PREROUTING ACCEPT [0:0]
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
COMMIT

*nat
:PREROUTING ACCEPT [0:0]
:POSTROUTING ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
COMMIT

*filter
:INPUT ACCEPT [0:0]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [0:0]
-A INPUT -i lo -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
-A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
-A OUTPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT
# some default rules we want to open everywhere
-A INPUT -p tcp --dport 22 -s 1.0.0.0/8 -j ACCEPT
-A INPUT -p tcp --dport 22 -s 12.30.0.0/16 -j ACCEPT
-A OUTPUT -p udp --dport 53 -d 1.0.0.0/8 -j ACCEPT

:app-user - [0:0]
-A OUTPUT -m owner --uid-owner 999 -m state --state NEW -j app-user
-A app-user -o eth0 -p tcp --dport 2003 -d 1.2.3.4 -m conntrack --ctstate NEW -j ACCEPT
-A app-user -o eth0 -p tcp --dport 27017 -d 1.1.4.3 -m conntrack --ctstate NEW -j ACCEPT
-A app-user -o eth0 -p tcp --dport 5672 -d 1.1.4.9 -m conntrack --ctstate NEW -j ACCEPT
-A app-user -o eth0 -p tcp --dport 80 -d 1.1.4.10 -m conntrack --ctstate NEW -j ACCEPT
-A app-user -o eth0 -p udp --dport 8125 -d 1.1.4.74 -m conntrack --ctstate NEW -j ACCEPT
-A app-user -j LOG --log-prefix "DROP_AFW_OUTPUT_app-user " --log-uid --log-tcp-sequence

:haproxy - [0:0]
-A OUTPUT -m owner --uid-owner 110 -m state --state NEW -j haproxy
-A INPUT -i eth0 -p tcp --dport 10097 -s 0.0.0.0/0 -m conntrack --ctstate NEW -j ACCEPT
-A haproxy -o eth0 -p tcp --dport 2003 -d 1.1.0.25 -m conntrack --ctstate NEW -j ACCEPT
-A haproxy -o eth0 -p tcp --dport 2003 -d 1.1.0.37 -m conntrack --ctstate NEW -j ACCEPT
-A haproxy -o eth0 -p tcp --dport 80 -d 1.1.4.58 -m conntrack --ctstate NEW -j ACCEPT
-A haproxy -j LOG --log-prefix "DROP_AFW_OUTPUT_haproxy " --log-uid --log-tcp-sequence

:nagios - [0:0]
-A OUTPUT -m owner --uid-owner 105 -m state --state NEW -j nagios
-A INPUT -i eth0 -p tcp --dport 5666 -s 1.1.0.33 -m conntrack --ctstate NEW -j ACCEPT
-A nagios -j LOG --log-prefix "DROP_AFW_OUTPUT_nagios " --log-uid --log-tcp-sequence

:ntp - [0:0]
-A OUTPUT -m owner --uid-owner 104 -m state --state NEW -j ntp
-A ntp -o eth0 -p udp --dport 123 -d ntp.example.net -m conntrack --ctstate NEW -j ACCEPT
-A ntp -j LOG --log-prefix "DROP_AFW_OUTPUT_ntp " --log-uid --log-tcp-sequence

:root - [0:0]
-A OUTPUT -m owner --uid-owner 0 -m state --state NEW -j root
-A INPUT  -p icmp -s 0.0.0.0/0 -m conntrack --ctstate NEW -j ACCEPT
-A root -o eth0 -p tcp --dport 514 -d 1.1.3.18 -m conntrack --ctstate NEW -j ACCEPT
-A root -o eth0 -p udp --dport 514 -d 1.1.3.18 -m conntrack --ctstate NEW -j ACCEPT
-A root -p icmp -d 0.0.0.0/0 -m conntrack --ctstate NEW -j ACCEPT
-A root -j LOG --log-prefix "DROP_AFW_OUTPUT_root " --log-uid --log-tcp-sequence

:snmp - [0:0]
-A OUTPUT -m owner --uid-owner 108 -m state --state NEW -j snmp
-A snmp -o eth0 -p udp --dport 162 -d 1.1.0.23 -m conntrack --ctstate NEW -j ACCEPT
-A snmp -j LOG --log-prefix "DROP_AFW_OUTPUT_snmp " --log-uid --log-tcp-sequence

:www-data - [0:0]
-A OUTPUT -m owner --uid-owner 33 -m state --state NEW -j www-data
-A INPUT -i eth0 -p tcp --dport 80 -s 1.1.4.4 -m conntrack --ctstate NEW -j ACCEPT
-A INPUT -i eth0 -p tcp --dport 80 -s 1.1.4.1 -m conntrack --ctstate NEW -j ACCEPT
-A www-data -j LOG --log-prefix "DROP_AFW_OUTPUT_www-data " --log-uid --log-tcp-sequence

-A INPUT -j LOG --log-prefix "DROP_AFW_INPUT " --log-uid --log-tcp-sequence
-A INPUT -j DROP

-A OUTPUT -j LOG --log-prefix "DROP_AFW_OUTPUT " --log-uid --log-tcp-sequence
COMMIT

The INPUT chain contains all of the rules for incoming connections. It does not redirect packets to other chains, but accept or drop them directly.

The OUTPUT chain is a little different. Depending on the owner of the socket emitting packets, it will direct the packets to a different chain, named after the socket owner. In the example above, the packet from the snmp user will be directed to the chain named snmp. You can see in this chain that the first two rules accept packet, while the 3rd one will LOG to syslog when it is reached (it shouldn’t be). Eventually, a DROP will follow that log rule to drop packets that aren’t suppose to be sent.

ATTRIBUTES

  • default[:afw][:enable] = true : enable or disable the firewall restore command. If set the false, the rules will still be populated in /etc/firewall/rules.iptables but the restore command will not be issued.
  • default[:afw][:enable_input_drop] = true : DROP all input packets by defaut
  • default[:afw][:enable_output_drop] = true : DROP all output packets by defaut
  • default[:afw][:enable_input_drop_log] = true : LOG when DROP input packets
  • default[:afw][:enable_output_drop_log] = true : LOG when DROP output packets

Dependencies

Ohai network_addr

This cookbooks relies on the custom AWeber Ohai plugin which sets the two following attributes:node[:network][:lanip] is set to the IP of the node on the LAN network node[:network][:laniface] is set to the network interface on the LAN While AFW can probably run with this plugin, it makes you life easier when you want to open rules on your LAN interface. We typically enfore eth0 to be the LAN interface, but feel free to use whatever you want.

Plugin source:

provides "network"

require_plugin "hostname"
require_plugin "#{os}::network"

network['interfaces'].each do |iface, addrs|

  addrs['addresses'].each do |ip, params|
    network["ipaddress_#{iface}"] = ip if params['family'].eql?('inet')
    network["ipaddress6_#{iface}"] = ip if params['family'].eql?('inet6')
    network["macaddress_#{iface}"] = ip if params['family'].eql?('lladdr')
  end

end

laniface = from("[ -e /vagrant ] && echo eth1 || echo eth0")

network['lanip'] = network["ipaddress_#{laniface}"]
network['laniface'] = laniface

network

LICENSE

 +-------------------------------------------------------------------------+
 | Advanced FireWall (AFW) Cookbook for Opscode Chef                       |
 |                                                                         |
 | Copyright (C) 2012, AWeber, Julien Vehent                               |
 |                                                                         |
 | This program is free software; you can redistribute it and/or modify    |
 | it under the terms of the GNU General Public License version 2          |
 | as published by the Free Software Foundation.                           |
 |                                                                         |
 | This program is distributed in the hope that it will be useful,         |
 | but WITHOUT ANY WARRANTY; without even the implied warranty of          |
 | MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the           |
 | GNU General Public License for more details.                            |
 |                                                                         |
 | You should have received a copy of the GNU General Public License along |
 | with this program; if not, write to the Free Software Foundation, Inc., |
 | 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301 USA.             |
 |                                                                         |
 +-------------------------------------------------------------------------+


More information can be found on:https://github.com/jvehent/AFW

libnfldap – A Python module to generate IPTables and IPSet rules from LDAP records


libnfldap

A Python module to generate IPTables and IPSet rules from LDAP records. See example.py for a demo.

Installation

Use PyPi:

$ sudo pip install libnfldap

Or build a RPM using:

$ python setup.py bdist_rpm

The later will require python-ldap to be installed separately, either using yum install python-ldap or pip install ldap. It’s up to you, the RPM will not attempt to install the ldap dependency.

Example

The script at example_allusers.py will build iptables and ipset rules for all users in LDAP. You can provide the script an ldap filter as argv[1] to limit the scope.

$ time python example_allusers.py '(uid=jvehent)'
IPTables rules written in /tmp/tmpT7JgOW
IPSet rules written in /tmp/tmpJYtWM5

real    0m0.605s
user    0m0.061s
sys     0m0.014s

example.py does something similar but for a single user identified by its uidNumber (unix user ID).

$ python example.py 2297
#Generating rules for user ID 1664
#====== ACL details ======
jvehent has access to .....

Authors

Julien Vehent & Guillaume Destuynder (@ mozilla)

More information can be found on: https://github.com/mozilla/libnfldap

How to install CSF firewall on your VPS


How to install CSF firewall on your VPS

Is by far the easiest firewall script to date I have worked with which even comes with a Webmin module a web interface front-end to manage the firewall configuration.  If you’re serious about your server security then add another layer of defense by installing CSF the user-friendly server firewall.  CSF has been tested to work with different Virtual Private Servers.  But I would suggest to use a Xen or KVM VPS instead of an Open VZ so you will have all the IPtables modules needed for CSF to work correctly. On a personal note after using CSF on my servers I have noticed a significant reduction of brute force attempts directed against FTP or SASL.

My CSF installation was done on an Ubuntu 12.04 LTS and Debian 7 Wheezy.

Install CSF Firewall

cd /usr/local/src

wget http://download.configserver.com/csf.tgz

tar -xzf csf.tgz

cd csf

sh install.sh

Iptables Module Test

Do a test to make sure you have the needed iptables modules installed for it to work.  This is one of the many reasons to use a Xen or KVM VPS so you don’t run into any missing iptables modules when using OpenVZ type VPS.

perl /usr/local/csf/bin/csftest.pl

You should get something like this.

iptables module test

Remove Advance Policy Firewall & Brute Force Detection

Run the this script if you already APF & BFD firewall installed like I do.

sh /usr/local/csf/bin/remove_apf_bfd.sh

Installing CSF Webmin Module

Install the Webmin module to manage the firewall through a web interface.   Since I already have Webmin installed on my server all I had to do was to go to Webmin > Webmin Configuration > Webmin Modules > Install from local file > Browse to /usr/local/csf/csfwebmin.tgz.

Click install.

install csf webmin module

CSF Firewall Webmin Menu

After it has been installed there will now be a menu call ConfigServer Security & Firewallunder the System menu.

csf webmin module

CSF Basic Security Test

CSF can perform a basic security check on your server with suggestions on how to fix any issues found.

Click  Check Server Security.

csf server security check

These were the results I got.  So I have some work to do.

csf security check results

Green indicator Firewall is running

Very important to keep on doing the test and fixing any issues found by the check until you get the OK.

One of the suggested fix is to enable the CSF upgrade connection to use SSL.

You can install the LWP perl module using Webmin’s perl module.

perl module

Then edit the csf.conf file.

vi /etc/csf.conf

ssl upgrade

green indicator

Firewall Configuration

Clicking on Firewall Configuration to make your edits.

firewall configuration

To quickly jump to sections of the firewall settings you can choose from the drop down menu.

firewall configuration menu

Before I start changing settings on the CSF firewall Webmin module I added my current IP address so I don’t lock myself out.  By clicking Quick Allow.

allow ip through

Or you could set the CSF firewall to test mode by setting the values like below.

csf testmode

Clicking on Firewall Configuration next to start managing the firewall configuration script.

firewall configuration

Using the recommended setting for RESTRICT_SYSLOG.

restrict_syslog recommended setting

Create a group for Syslog.

syslog group

Restricted UI set to the recommended setting.

restrict ui setting

Set the auto update to on so the cron script can check daily for newer versions of CSF.

auto updates on

If an update becomes available this will appear as below.  You can view details of the upgrade by clicking View ChangeLog.

Clicking Upgrade csf will perform upgrade.

csf update available

Allow which ports to receive and send connections otherwise those services will not be able to communicate.

allowed ports

I ran into an issue where my outbound SSH connections were being blocked by the firewall.  I forgot to add the new port number on the outbound TCP ports.  I am using a non-default SSH port.

outbound ssh port

Enable or disable ping replies.

allow ping replies

How many IPs to keep in the deny lists.  Change this setting depending on your server resources.

deny ip limit

The following settings are enable so LFD can check for login failures to ban.  The setting will also check to make sure CSF has not been stopped so it can be restarted.

lfd set to check for login failures

Set the default drop target for connections matching a rule.  Set it to DROP.  This will cause anyone trying to port scan your server to hang.

drop target

I like to enable the drop connections should I need to see which IPs got blocked.

drop logging

How to block countries from accessing your server

CSF, makes this very easy to do compared to other scripts I have used in the past.  You just need to add the country code separated by comma.

block countries

Blocking a specific IP address or a network

I have used this feature a lot whenever I get phishing emails or lots of spam coming from an IP address or IP addresses from the same network block I will add the IP address or network address in here with a comment.  Any IP address added here will be permanently blocked.  I have used this online whois to determine who owns the IP address and which ISP provides hosting.

deny ip

Login failure blocking when enabled will trigger LFD Login Failure Daemon to block any failed login attempts when it reaches the number of failed attempts set.

lf trigger

When you have LFD enabled you will sometimes need to add IP addresses you own in here so you don’t get locked out if you mistype a password.  Click edit then add in your IP address or network.  Then restart LFD.

lfd ignore list

Block lists

let us enable these block lists from Spamhaus, Dshield, Honeypot, Tor nodes, etc.

Clicking lfd Blocklist.  Uncommenting the blocklist you want to use.  Using this has reduced intrusion attempts against my server from compromised hosts.  What a great option to have on a firewall.  CSF makes it incredibly easy to enable.  Before you enable this blocklist or country blocking you need to consider if your server has enough to resources to handle the load.  My VPS typically have more than 3 GB of ram some even more.  I usually do not have less than 4 CPUs for my VPS.  So I am able to use all the blocklist rules with no noticeable performance hit.

Don’t forget to click change to apply the new settings.

vi /etc/csf/csf.blocklist

blocklist

If you’re curios to see what rules your CSF firewall has loaded click on view iptables rules. Depending on what you have enable be prepared to scroll for a long time.  This is just a sample of mine which shows connections from China are blocked.  I had to snipped it for the output was very long.

china blocked

If you want to see connections being dropped in real time you could do so by clicking watch system logs.  Then choosing from drop down kern.log.

watch system logs

dropped connections

If you wanted to permanently block an IP or IP range click Firewall Deny IPs.  Enter each IP or CIDR addressing one per each line.

Click change to apply configuration changes.

block ip permanently

block ip list

Login Failure Daemon (LFD)

LFD Daemon is a process which continuously scans the logs for failed login attempts the script will immediately block the offending host when a set number of failed attempts is reached per IP.  It can also detect distributed attacks.  Compared to Fail2ban which I used before the resource consumption created by LFD is much lower.

Very Important! If you want your home IP address not being blocked by LFD due to failed login attempts (You making SSH, IMAP, etc connections while putting in the wrong password) you will have to add them into csf.ignore.  Add the IPs you don’t want blocked one per each line. I learned this the hard way!

From the web interface choose from the drop down which LFD file to edit to add IP addresses you never want locked out.

lfd ignore web interface

vi /etc/csf/csf.ignore

If you end up blocking yourself you will have to login at the console to stop LFD  through init.  
/etc/init.d/lfd stop

Check if Syslog is running

syslog is running check

ConfigSecurity Firewall & LFD Brute Force Detection Blocking Specific Settings for Ubuntu & Debian

For LSF to block failed attempts against ProFTPD, SASL on Ubuntu & Debian the following log paths on CSF.conf have to be changed.

vi /etc/csf/csf.conf
HTACCESS_LOG = "/var/log/apache2/error.log"

MODSEC_LOG = "/var/log/apache2/error.log"

SSHD_LOG = "/var/log/auth.log"

SU_LOG = "/var/log/messages"

FTPD_LOG = "/var/log/proftpd/proftpd.log"

SMTPAUTH_LOG = "/var/log/mail.log"

POP3D_LOG = "/var/log/mail.log"

IMAPD_LOG = "/var/log/mail.log"

IPTABLES_LOG = "/var/log/syslog"

SUHOSIN_LOG = "/var/log/syslog"

BIND_LOG = "/var/log/syslog"

SYSLOG_LOG = "/var/log/syslog"

WEBMIN_LOG = "/var/log/auth.log"

Then on the CUSTOM LOG.

CUSTOM1_LOG = "/var/log/mail.log"

Then you will need to add the regex to catch the failed attempts against SASL.

vi /usr/local/csf/bin/regex.custom.pm

Add the following code in the middle of  “Do not edit before this point &  Do not edit beyond this point”  The numbers after “mysaslmatch” are used for the following: “1” is the number of failed attempts which triggers a block IPTable rule.  The next number indicates the port to monitor “25,58”. You could separate the multiple ports using a comma.  The next number “6000” is the time in seconds the host will be kept in the deny lists.

if (($lgfile eq $config{CUSTOM1_LOG}) and ($line =~ /^\S+\s+\d+\s+\S+ \S+ postfix\/smtpd\[\d+\]: warning:.*\[(\d+\.\d+\.\d+\.\d+)\]: SASL [A-Z]*? authentication failed/)) {

return ("Failed SASL login from",$1,"mysaslmatch","1","25","6000");

}

Restart the CSF firewall to apply settings.

csf -r

As soon as I have the SASL custom regex applied an offending host was caught abusing SASL.  The log which was emailed to me.  It has been very effective blocking brute force detection targeted against my FTP and SASL services that I decided to do away with Fail2ban.

sasl blocked host

Checking the Temporary IP Entries came up with the following results.

temporary block ips

From this window you can easily unblock or permanently ban an IP by clicking the icons.  Any hosts added to this list will be banned accessing any ports until the set banned time limit is reached.

blocked ip gui

If you want to allow only specific IPs from connecting to your SSH port you could do so by removing SSH port 22 in the IPv4 port settings.

Allow specific ips from connecting

Then adding the IP addresses you want to be able to connect to your SSH port in.

vi /etc/csf/csf.allow

###############################################################################
# Copyright 2006-2014, Way to the Web Limited
# URL: http://www.configserver.com
# Email: sales@waytotheweb.com
###############################################################################
# The following IP addresses will be allowed through iptables.
# One IP address per line.
# CIDR addressing allowed with a quaded IP (e.g. 192.168.254.0/24).
# Only list IP addresses, not domain names (they will be ignored)
#
# Advanced port+ip filtering allowed with the following format
# tcp/udp|in/out|s/d=port|s/d=ip
# See readme.txt for more information
#
# Note: IP addressess listed in this file will NOT be ignored by lfd, so they
# can still be blocked. If you do not want lfd to block an IP address you must
# add it to csf.ignore
123.123.123.124 # csf SSH installation/upgrade IP address - Wed Feb 26 13:16:28 2014
123.123.123.125 # Home IP address

 DDoS Protection

From Firewall Configuration click on drop down.

connection tracking

For some level of DDoS protection I have enabled connection tracking by doing so I am able to limit the number of connections to network services I want to limit connections it receives.  The values below are what works for my setup you will have to play around as to what settings works best for you.

CT_LIMIT = 100

CT_BLOCK_TIME = 1800 (30 mins blocked time)

CT_PORTS = 80,993

Leaving the rest of the settings to use the default values.

ct_limit

Leaving the rest of the settings up to you to change.  The CSF firewall settings are very well documented.  When you’re done making your edit apply new settings by clicking change.

apply setting changes

Command line CSF

Enable CSF

csf -e

Disable CSF

csf -x

Re-enable CSF and LFD

csf -e

Restart CSF

csf -r

Happy Fire-walling using CSF The User-friendly host-based firewall.

References:

http://forum.configserver.com/viewtopic.php?f=6&t=6968

https://www.virtualmin.com/node/13841

How to virtualize pfSense firewall including using VirtIO drivers on Proxmox VE


This install will cover how to install pfSense firewall as a virtual machine. Is it safe to virtualize a firewall?  I will leave it up for you to do your own research to find your answer there numerous online discussions which go over this topic.  These are just two which I have stumbled upon. From serverfault and Security Week.  Personally I am more in the camp of folks who agree it is safe to Virtualize a firewall. You can read about pfSense here.

How to virtualize pfSense firewall including using VirtIO drivers

The requirements of this tutorial are the following:

  1. A functioning Proxmox Hypervisor with version 3.3-5/bfebec03 or newer.
  2. You have already created the necessary network bridges.  I have gone over this on my other tutorial how to Virtualize IPCop on Proxmox.
  3. Administrative rights on the Proxmox server.
  4. (Might be optional) I have a Proxmox Community subscription plan for pricing you can check it here.  The subscription plan provides access to the Enterprise repository.  The cost is very reasonable when compared to other commercial virtualization platforms.  I paid 99.80 euro’s, at the time of conversion it was $115.41 per year.
  5. Comfortable using Linux.
  6. Some knowledge using vi

Creating a Linux Bridge

This is done on the Proxmox host.

This is the part I miss using VMware ESX control panel assigning virtual switches and nic cards.  Proxmox web interface has the ability to create Linux Bridges and OVS switches for virtual machines to use but the configuration I am going to use can’t be done through the Proxmox web interface.  This has to be done through the command line.

I prefer to  use vi when editing files so I had to install this.

apt-get install vim

Connect to Proxmox host using SSH.

ssh -l root proxmox-server-ip

What the following bridge settings mean.

bridge_stp off # disable Spanning Tree Protocol

bridge_fd 0 # no forwarding delay

bridge_ports eth0 # which nic card to attach

Move to the network directory.

cd /etc/network

Edit the interface file.

vi interfaces

Copy and paste below after any configuration already in there.  On my Proxmox host physical server I have 5 physical network cards installed.  I therefore created 4 network bridges.

Below is the process of creating one network bridge. Each time you add another network bridge just rename each network bridge as vmbr1, vmbr2, vmbr3, etc.

## this is for pfSense WAN nic

auto vmbr1
iface vmbr1 inet manual
bridge_ports eth1
bridge_stp off
bridge_fd 0

Save and exit.

:wq

Each time a network bridge is created a reboot is needed to apply new settings.  So it is better to add all of the bridge configuration one time.

reboot

Below is what my network bridge configuration file looks like.  Yours make look different depending on how many you have.

network bridges

I purposely left out network bridge vmbr0 from being assigned for use for virtual machines.  This is the network I will be using solely when I connect to my Proxmox web gui.  Proxmox scheduled backups is also going through this network.

Note: vmbr0 is the only network bridge which should have a gateway IP assigned!

vmbr0

The reason we don’t put a gateway IP address for the network bridges we create because we add the gateway IP on the virtual machines nic card.  Example: the image below shows my Windows 7 computer has a gateway IP address of 172.16.2.6 which is the IP address of my pfSense LAN nic card.

win7 gw

After Proxmox reboots your network settings should look similar to mine.  The IP address for vmbr0 and gateway settings have been erased for security reasons.  vmbr1 settings for Port/Slaves, IP address, Subnet mask and Gateway are intentionally left blank.  This is to make sure any network traffic coming through vmbr1/eth1 will pass through pfSense WAN virtual nic.

When you have met all of the requirements let us begin.

Download pfSense

From the pfSense website download the 64bit installer.

pfsense download

Check to make sure the pfSense ISO has not been altered.  On my Mac I open a terminal and use md5 to check the checksum against the md5 checksum posted on the pfSense website.

md5 checksum

Logging in to the Proxmox web GUI

Login to the Proxmox web gui this will be https://172.16.1.10:8006.  The Proxmox hypervisor will be using a self signed certificate do your acceptance for your specific browser of choice.  I will be using Firefox.

Upload the ISO to the Proxmox Hypervisor

On the left menu click on local the choose content tab then upload.  Navigate to where your pfSense ISO is then click upload.

iso upload

 Virtualizing pfSense using KVM (Kernel-based Virtual Machine)

Create a Virtual Machine

After you login click on the menu Create VM which is located on the top right.

create vm

Give your VM an ID and name.  Click next.

vmid

Choose other OS types since pfSense is built using FreeBSD. Click next.

choose other

For the ISO click on the drop down to choose your uploade pfSense ISO file. Click next.

iso file

Choose IDE for Bus/Device for now we will later replace this using a VirtIO driver. I choose Raw disk for my block format.  According to Proxmox developers this is the more performant. Click next.

block device

Allocate your CPUs. My Super Micro box has two sockets hence the settings below. Leave it at kvm64 bit. Click next.

cpu allocation

Allocate memory.  It will depend on how much your physical server has to spare and your intended use for your pfSense firewall.  Click next.

allocate memory

Add a nic card assign it to network bridge.  I have mine to use vmbr1 using an Intel E1000 driver for the nic card.  Click next the finish.

vmbr1

Then go back into the hardware tab and add another nic card using Intel E1000 driver.  Click add.

add 2nd nic

Be sure to add the second nic card to use a different network bridge.  Mine is setup as vmbr3.

vmbr3

Then go back into the hardware tab and add the third nic card using Realtec driver.  Add it no another bridge for mine it will vmbr4. Click add.

This third nic card will be assigned for our DMZ.

Yours will look similar to my hardware summary here except maybe for the CPU count.  If you’re curios to know what sort of resources you need for your environment consult thisguide.

hardware summary

 Launch the VM

Click on the newly create pfSense VM, then on the top right menu click Start.  When it starts immediately click on Console.  These two menus are pretty much close to each other. Choose noVNC.

novnc

Pay attention to the screen I mean it, it will fly past so quickly. When you see the install option menu enter i.  You know you will be successful when you see the image below.  Use the settings shown.  Enter.

video settings

Choose Quick/Easy Install. Enter.  OK. Enter.

easy install

Click OK to proceed with installation.

ok install

Installation proceeds.

install progress

Install standard kernel. Enter.

standard kernel

Reboot.

reboot

Note down the names your three identified nic cards.

em0

Choose n (No) when asked to setup vlans.  Enter.

no vlans

em0 (0) is numeral zero

Type in em0 (0) is numeral zero for the WAN interface. Enter.

em0

For the LAN nic hit enter em1.

no lan nic

For the DMZ nic enter re0.

You will be asked for Optional2 just hit enter for none.

card assignments

Confirm network settings. y enter.

confirm

Enabling VirtIO

This is the part we will load necessary modules so we can use VirtIO drivers.  We will be editing the file /boot/loader.conf.local.  Choose option 8. Enter.

option 8

I will be using vi to edit the configuration file.  We need to put it into this file so the instruction becomes permanent otherwise it will be gone each our pfSense virtual firewall reboots.

loader.conf

vi /boot/loader.conf

Add the following entries one on each line.

virtio_load="YES"
virtio_pci_load="YES"
if_vtnet_load="YES"
virtio_blk_load="YES"

When the done the file will look.

loader.conf

Save the file.

:wq

Type exit. Enter.  To close out the shell console.

This part we will shutdown our pfSense VM.  Choose option 6.  Enter.   Type y enter.

shutdown pfsense

Your VM icon will turn from white black indicating the VM has been shutdown.  Click your VM pfSense from the left menu of the Proxmox web GUI then go to hardware tab.  Click CD/DVD choose remove. Click yes.

remove cdrom

Now start the VM back up by clicking start from the top right menu.  Access the console again.

novnc

When the options menu comes up choose option 2. Enter.

option 1

You will again be asked if you want to setup vlans.  Choose n.  If you want to setup vlans you can read the pfSense online docs.

You’re shown available interfaces to configure.

assign

Enter the number of the interface you want to configure.  I am will be adding a static IP for the LAN interface.

Enter 2

Enter the LAN IP.  I am putting in IP address 172.16.2.6.  Enter.

enter lan ip

I am using the subnet mask 255.255.255.0, therefore I will put in 24 for bit count.  Enter.

24 bit count

When you get to this part just enter for none.  Enter.

upstream gateway

For LAN IPv6 enter for none.  Enter.

ipv6

Do you want to enable DHCP on the LAN interface.  I will enable DHCP for mine. Enter y.

enable dhcp

Enter the beginning IP for your DHCP client range.  This is what I have.  Enter

ip range

Enter the end of the IP range.  This is what I have. Enter.

end of ip range

Set to n when asked to revert the webconfigurator protocol to HTTP.  We want to access our pfSense web GUI through SSL.

pfsense gui

Now it indicates we will be able to access our pfSense firewall using IP 172.16.2.6 from a web browser.  Enter to take console back to menus.

Connecting to pfSense web gui

From another computer we will now connect to our pfSense Web GUI using the IP address you have used for your LAN nic.

Type in the URL in your browser

Note: Your browser will warn you since you’re connecting to self signed certificate. Just accept it.
https://172.16.2.6  (Replace with your own LAN IP)

Default login are:

Username: admin

Password: pfsense

default login

pfSense wizard will assists you setting up your newly installed pfSense firewall.  Click next.

pfsense wizard

You can sign up for the pfSense Gold Subscription.  I will skip this for now. Click next.

pfsense gold subscription page

Provide your pfSense hostname and domain.  Add your DNS name servers or have DHCP provide those for you.  I am using Google’s name servers. Click next.

pfsense hostname

Set your timezone. Use the default time server.  Click next

time zone

Set your WAN settings here.  Yours could be DHCP or PPOE.  I will set mine as static IP.  The static IP the address, subnet mask and gateway will be provided to you by your Internet Service Provider.  Click next.

wan stattic

stattic ip

After you set your WAN IP as static go to General Setup menu.  Look at the DNS settings if it has an option to use a GW set this to the default gateway provided to you by ISP provider.

Note: I had an issue where I was unable to update my pfSense firewall even though I was able to ping an external host from the pfSense console.  I was even able to do an nslookup successfully but each time I tried to update pfSense an error came back which said it was unable to contact the pfSense update server.  After putting this GW information for my DNS the update worked.

dns gw

We have already set our LAN IP through the console so just click next.

lan

Change the admin password for the web gui.  Click next.

web gui pass

Click reload.

reload

Congratulations!  You have just setup your pfSense router.

done

pfSense Dashboard.

dashboard

Let us check if our pfSense has any updates.  From the System menu > Firmware > Auto Update tab.

As I was checking the update it turns out pfSense version 2.2 just got released!  With a click of a button I was able to uprade my pfSense 2.1.5 to 2.2 easily.  After installation of the upgrade the firewall will automatically reboot.

Click invoke auto upgrade.  (Give it time to download could take a few minutes).

upgrade

Since there are significant changes introduce by 2.2, I did a simple to test to make sure my virtIO enabled nic cards still works using the ping option 7 from the pfSense console.  Test looked good.

ping check

From my Linux workstation I am also able to ping an external address.  The Linux worstation is using the IP address of the pfSense as its default gateway.  This is the LAN IP of the pfSense firewall.

ping external

You now have a functioning pfSense firewall but if you want to use the VirtIO device drivers continue with instructions below.

Change the block and nic device driver to use VirtIO on pfSense

Why would you want to do this?  Here is the answer from the libvirt.org website.

“Virtio is a virtualization standard for network and disk device drivers where just the guest’s device driver “knows” it is running in a virtual environment, and cooperates with the hypervisor. This enables guests to get high performance network and disk operations, and gives most of the performance benefits of paravirtualization.”

From the pfSense console choose option 8 for shell. Enter.

option 8

Type in

vi /etc/fstab

Change the following two lines.

/dev/ad0s1a       /           ufs       rw     1     1
/dev/ad0s1b       none    swap   rw      0    0

To read as.

/dev/vtbd0s1a    /            ufs       rw    1     1
/dev/vtbd0s1b    none     swap   sw    0     0

Save your changes.

:wq

Then exit out of the console. Type in exit.

Shutdown your pfSense server from the console.  Choose option 6. Enter.

Screen Shot 2015-01-21 at 4.53.05 PM

The configuration we will need to change could be found at the Proxmox hypervisor.  Log back into your Proxmox web gui then on the left menu click on your Proxmox host.  Mine is called proxmox-supermicro.

proxmox host

Then from the top right menu click console then choose noVNC.

noVNC

Then move to the directory where the configuration file we need is located.  This will contain all of the configuration files of your KVM based virtual machine which is what we’re using for our pfSense firewall. My pfSense virtual machine has the VM ID of 198.

cd /etc/pve/qemu-server/

Before you alter the original file it is wise to make a copy first.

cp 198.conf 198.conf.orig

After making the copy edit the file. We need to change this line

vi 198.conf

ide0: local:198/vm-198-disk-1.raw,format=raw,size=10G

to read as (the one marked in red is the numeral zero indicating this is the first block device).

virtio0: local:198/vm-198-disk-1.raw,format=raw,size=10G

Change the bootdisk also to.

bootdisk: virtio0

Save your changes.

:wq

Start up your pfSense virtual machine.  Good job!  Now you’re running your block device using the virtIO driver.  If you look at your hardware summary you will find your hard disk is using (virtio0).

summary

Set VirtIO nic drivers for pfSense

Note: Very important! Before proceeding with changing anything this needs to be done using the pfSense gui. Go to System then Advance then Networking. Disable hardware checksum offload. Click save.

offload

Shutdown your pfSense firewall from the console or web gui.

option 6

Click on your VM ID, then hardware tab then click nic card you want to change the driver then click edit. I am going to change all nic cards to use virtIO.

change to virtio

Start pfSense backup.  You will once again be asked to configure your network interfaces. Click n when asked to setup VLANS.  Pay attention to the naming convention which has changed for the network cards they all start with vtnet with 0,1,2 appended on each end for each network card.

setup vlans

Lets start to assigned each one.

Enter for WAN using vtnet0

Enter for LAN using vtnet1

Enter for DMZ using vtnet2

Enter for none.

Confirm y  to apply new settings.

vtnet

From the pfSense console choose option 7.  This will test if our new network card drivers are working.  Ping an external host IP.

ping host

Enjoy the awesome pfSense Open Source Enterprise grade firewall for free!

References:

https://doc.pfsense.org/index.php/VirtIO_Driver_Support

Installing IPCop as a Virtual Machine on Proxmox VE


Installing IPCop as a Virtual Machine on Proxmox VE

How I  virtualized my IPCop installation on Proxmox VE hypervisor.  This how-to assumes you already have a running Proxmox VE host.  If you want to try  Proxmox VE click here.  Other requirements are, there needs to be two physical network cards installed on the Proxmox host. Three if you intend to setup DMZ.

After downloading the latest IPCop installation iso.  I have to upload the iso to my Proxmox host local storage.

From the Proxmox web panel click on local (proxmox-name-of-your-proxmox-host).  Then click Content tab then Upload.  Which brings up the upload window.  Browse to location of the downloaded IPCop iso then click upload.

upload ipcop to proxmox

Creating a Linux Bridge

This is the part I miss using VMware ESX control panel assigning virtual switches and nic cards.  Proxmox web interface has the ability to create Linux Bridges and OVS switches for virtual machines to use but the configuration I am going to use can’t be done through the Proxmox web interface.  This has to be done through the command line.

Note: I found it easier to keep the other physical network cards unplugged except for one nic card which will be used by the Proxmox web control panel.  As I created each virtual bridge it was only then I plugged in the associated nic card.  This made it easier for me to identify as to which physical nic card to assign to each virtual bridge added.

The image below shows starting with one plugged in nic card.

one nic plugged

I prefer to  use vi when editing files so I had to install it first.

apt-get install vim

Connect to Proxmox host using SSH.

ssh -l root proxmox-server-ip

What the following bridge settings mean.

bridge_stp off # disable Spanning Tree Protocol

bridge_fd 0 # no forwarding delay

bridge_ports eth0 # which nic card to attach

Move to the network directory.

cd /etc/network

Edit the interface file.

vi interfaces

Copy and paste below after any configuration already in there.

## this is for IPCop WAN nic

auto vmbr1
iface vmbr1 inet manual
bridge_ports eth1
bridge_stp off
bridge_fd 0

Save and exit.

:wq

Each time a network bridge is created a reboot is needed to apply new settings.

# reboot

After Proxmox reboots your network settings should look similar to mine.  The IP address for vmbr0 and gateway settings have been erased for security reasons.  vmbr1 settings for Port/Slaves, IP address, Subnet mask and Gateway are intentionally left blank.  This is to make sure any network traffic coming through vmbr1/eth1 will pass through IPCop WAN virtual nic.

bridge network

My IPCop topology created using this free online drawing tool.

my-ipcop-topology

Create IPCop virtual machine

From the top right corner of web interface click on Create VM.  Name the Virtual Machine.  Click next.

ipcop vm name

Choose the new Linux versions. Click next.

ipcop linux version

Using default storage called local.  This will be where my virtual machine images will be stored.  From drop down choose IPCop iso we uploaded earlier. Click next.

ipcop iso

Hard disk settings.  Bus/Device is set to use IDE.  When I tried to use VirtIO, IPCop was unable to find the hard disk during installation. I picked raw format for speed.  Click next.

hard disk ipcop

For CPU type I am using KVM32.  Why I went with kvm32 click here.

ipcop cpu type

Allocate memory.  Click next.

ipcop memory

Add nic card for LAN (GREEN) use.  I am using the Intel E1000 model to make it easier to identify which nic card to assign for GREEN use. Click next.  Then click finish.

ipcop lan nic

Now add the WAN (RED) nic.  Click on IPCop vm then Hardware tab menu.  Then for bridge use vmbr1 we created earlier.  For nic card model use Realtec RTL8139.  Click add.

wan ipcop nic

This is what my hardware looks like.  Mac addresses erased for security reasons.

hardware summary

Click on Start to start the IPCop VM from the right top menu.  The status should show OK on the task panel below.  Status will also show resource usage.  To complete setup we will need to connect to VM using Console.  Click on console.  Which brings up the IPCop boot screen.  Click inside the console window then click enter key on the key board.

Note: if console window only shows white blank screen just click reload.

ipcop boot screen

Choose language.

choose ipcop language

Click ok to begin installation.

start ipcop install

Choose keyboard setting.

ipcop keyboard setting

Choose timezone and set correct time.

ipcop timezone

Accept hard drive to install on.  When ask are you sure you want to continue choose Ok.

ipcop hd

This will be a Hard Disk install.

hard disk ipcop

Installation begins.

ipcop install progress

We’re not restoring from backup click tab to skip.

skip backup restore

Install done.    Click enter.

install completes

Choose a name.

ipcop name

Enter domain name.

domain name

Choose static.  Depends of course on how your WAN setup.  Mine is a static IP.

choose static

 Network Card Assignment

This is why I wanted to use two different nic models so I could easily identify which nic card to assign.  I already know bridge vmbr0 is using eth0 on the Proxmox host.  This is also where the Promox web interface is listening on.

The Realtek virtual network device will be assigned to WAN (RED).  Choose select then RED. Tab to asssign.

red nic

Do the same for the Intel Card but this time assign it to GREEN for internal LAN use.

green

When all cards have been assigned tab to Done.

done

Assign Internal IP for GREEN interface.

internal ip

Assign WAN IP for RED interface.

wan ip

Assign DNS name servers to use and WAN gateway.

wan gw

Skip enabling DHCP unless you need it activated for your LAN.

skip dhcp

Create password for the next three screens for each IPCop user account.

password

Installation is finally done!

done!

After IPCop reboots login on the console to test if you can ping an internal IP and WAN IP.  Login as root.

You should be able to ping out to an external IP.  I am pinging Google’s nameserver below.

ping out test

I am also able to ping an internal IP.

ping success

I now have a functioning IPCop firewall.  But what if I wanted to add another nic card so I can place some hosts in DMZ?

Adding an IPCop DMZ

Here is one of the reasons it is good to use a DMZ network.  NY Times Article.

To make this work I had to add another physical network card on my Proxmox server.  I then had to add another bridge for DMZ use.

Again we have to edit the file.

vi /etc/network/interfaces

Adding this right below the vmbr1 we created earlier.

## this is for IPCop DMZ nic
auto vmbr2
iface vmbr2 inet manual
bridge_ports eth2
bridge_stp off
bridge_fd 0

Save the file.

:wq

Reboot Proxmox host.

Checking the network configuration on our Proxmox host you will find a new bridge called vmbr2.  With the associated physical nic eth2 showing it is active.  We now could assign this to our virtual IPCop firewall.

vmbr2

Go ahead and shutdown the IPCop vm we will then add a virtual nic from the hardware tab menu. I am adding another model Intel E1000 for this virtual nic which will attached to the physical nic card eth2.

dmz nic

Go ahead and start the IPCop vm to setup our new virtual nic card. Logging as root on the console. Then type setup > enter.

setup

Scroll down to Networking.  Tab to select.

networking setup

Scroll down to Drivers and card assignments.  Tab to select.

assign card and drivers

There is the unassigned Intel card.  Tab to select.

assign intel

Scroll down to Orange.  Orange in IPCop speak is the color assigned to DMZ zones.  Blue as you guessed it is assigned for Wifi hot spots. Tab to assign.

orange

All 3 virtual nics should be assigned.  Tab to done.

all cards assigned

Now we will need to add an IP for the Orange nic card.  This IP will be used as a gateway for any computers or devices which are connected to the Orange switch or Hub.

Scroll down to Address settings.  Tab to select.

address settings

Select which interface to configure. Tab to select.

orange ip

Put in IP from any of the private class range. Tab ok. Then tab Go Back > Go Back.  Then exit setup.

class b

You should be able to ping the IP in the Orange zone.

ping replies

Connecting to IPCop web interface

With our networking setup done time to connect to IPCop from the web browser. IPCop uses port 8443. Point your browser to your IPCop’s IP address (GREEN).

https://192.168.1.1:8443  (your browser will prompt you to accept an unsigned certificate. Go ahead and accept the IPCop certificate).

If you need to change IPCop default gui port to something else other than 8443, you could do so by doing it on the command line.  The command below will change the port to 5445.

/usr/local/bin/setreservedports.pl --gui 5445

Login using the credentials you created earlier to manage IPCop this would be admin.

First thing I like to do after I login is to check for IPCop updates. From the System menu > updates.  Here it shows I have three updates to apply by clicking on the green down arrow beside each update. Then click apply.

ipcop updates

After applying all updates I want to check if there are any open ports open through IPCop going into my LAN.  First I will change the gateway setting on my Mac to use the IP address of the GREEN zone which was 192.168.1.1.

mac gw

Using this website I can scan my IPCop WAN IP in this example I was using IP 123.123.123.123.  Below are my results if it were open a green indicator will show next to the port number.

scan results

Checking my IPCop firewall logs the DROP scan results show up.

drop results

Looking at my IPCop virtual machine’s status from Proxmox control panel.  I can see very low resource usage I even reduced my original memory allocation of 2.5 GB to 1 GB.

status

There is also a nice real time view for CPU, Memory, Network and Disk IO usage.  Available for each virtual machine.

stats

This is the part I really like about the Proxmox hypervisor I am able to backup a running virtual machine without shutting down the vm.  It will still be accessible while the backup snapshot is in progress.  Yes this feature comes free with the Proxmox hypervisor unlike free versions of ESX.  There was a time I had to use a commercial tool from Trilead to backup my virtual machines on free ESX. Not anymore!

When I did a backup to my nfs storage.

nfs storage

It took only 21 seconds to complete a backup of my IPCop vm.

backup time

Upon looking at the real space being used by my IPCop vm this tells me I could have allocated a smaller hard drive space when I created my virtual machine earlier.  If I was using qcow2 I can resize the virtual disk from the web control panel.  Why I decided to use the raw format? This was based on what I have read from Promox support forum if you want performance speed use the raw format.

I hope this will urge you to virtualize IPCop using the rock solid reliable Open Source bare metal hypervisor called Proxmox ve.

This concludes the tutorial Installing IPCop as a Virtual Machine on Proxmox VE.

References:

https://wiki.debian.org/BridgeNetworkConnections

http://forum.proxmox.com/threads/2020-Proxmox-Pfsense-working-setup-solved-2-NIC

Linux Bridges Explained


A bridge is a way to connect two Ethernet segments together in a protocol independent way. Packets are forwarded based on Ethernet address, rather than IP address (like a router). Since forwarding is done at Layer 2, all protocols can go transparently through a bridge.

The Linux bridge code implements a subset of the ANSI/IEEE 802.1d standard. [1]. The original Linux bridging was first done in Linux 2.2, then rewritten by Lennert Buytenhek. The code for bridging has been integrated into 2.4 and 2.6 kernel series.

Contents

  • 1 Bridging and Firewalling
  • 2 Status
  • 3 Downloading
  • 4 Kernel Configuration
  • 5 Manual Configuration
    • 5.1 Network cards
    • 5.2 Module loading
    • 5.3 Creating a bridge device
    • 5.4 Adding devices to a bridge
    • 5.5 Showing devices in a bridge
    • 5.6 Spanning Tree Protocol
      • 5.6.1 STP tuning
        • 5.6.1.1 Bridge priority
        • 5.6.1.2 Path priority and cost
        • 5.6.1.3 Forwarding delay
        • 5.6.1.4 Hello time
        • 5.6.1.5 Max age
    • 5.7 Multicast (IGMP) snooping
    • 5.8 Sample setup
  • 6 Configuration with /etc/net
  • 7 FAQ
    • 7.1 What does a bridge do?
    • 7.2 Is it protocol independent?
    • 7.3 Why is this code better than a switch?
    • 7.4 Why is this code worse than a switch?
    • 7.5 What is the performance of the bridge?
    • 7.6 My bridge does not show up in traceroute!
    • 7.7 It doesn’t work!
    • 7.8 No traffic gets trough (except ARP and STP)
    • 7.9 Does bridging work on 2.2?
    • 7.10 Are there plans for RSTP (802.1w) support?
    • 7.11 What can be bridged?
    • 7.12 Can I do bridging in combination with netfilter/iptables?
    • 7.13 Does it work with Token Ring , FDDI, or Firewire?
    • 7.14 I keep getting the message retransmitting tcn bpdu!
    • 7.15 It doesn’t work with my regular Ethernet card!
    • 7.16 It doesn’t work with my Wireless card!
    • 7.17 I still don’t understand!!
    • 7.18 I get the error ‘too much work in interrupt’
    • 7.19 Does DHCP work over/through a bridge?
  • 8 Contact Info
  • 9 External Links

Bridging and Firewalling

A Linux bridge is more powerful than a pure hardware bridge because it can also filter and shape traffic. The combination of bridging and firewalling is done with the companion project ebtables.

Status

The code is updated as part of the 2.4 and 2.6 kernels available at kernel.org.

Possible future enhancements are:

  • Document STP filtering
  • Netlink interface to control bridges (prototype in 2.6.18)
  • STP should be in user space
  • Support RSTP and other 802.1d STP extensions

Downloading

Bridging is supported in the current 2.4 (and 2.6) kernels from all the major distributors. The required administration utilities are in the bridge-utils package in most distributions. Package releases are maintained on the Downloadpage.

You can also build your own up to date version by getting the latest kernel from kernel.org and build the utilities based from the source code in bridge-utils GIT repository.

 $ git clone git://git.kernel.org/pub/scm/linux/kernel/git/shemminger/bridge-utils.git
 $ cd bridge-utils
 $ autoconf
 $ ./configure

Kernel Configuration

You need to enable bridging in the kernel. Set “networking -> 802.1d Ethernet Bridging” to either yes or module

Manual Configuration

Network cards

Before you start make sure both network cards are set up and working properly. Don’t set the IP address, and don’t let the startup scripts run DHCP on the ethernet interfaces either. The IP address needs to be set after the bridge has been configured.

The command ifconfig should show both network cards, and they should be DOWN.

Module loading

In most cases, the bridge code is built as a module. If the module is configured and installed correctly, it will get automatically loaded on the first brctl command.

If your bridge-utilities have been correctly built and your kernel and bridge-module are OK, then issuing a brctl should show a small command synopsis.

# brctl
# commands:
        addbr           <bridge>                add bridge
        delbr           <bridge>                delete bridge
        addif           <bridge> <device>       add interface to bridge
        delif           <bridge> <device>       delete interface from bridge
        setageing       <bridge> <time>         set ageing time
        setbridgeprio   <bridge> <prio>         set bridge priority
        setfd           <bridge> <time>         set bridge forward delay
        sethello        <bridge> <time>         set hello time
        setmaxage       <bridge> <time>         set max message age
        setpathcost     <bridge> <port> <cost>  set path cost
        setportprio     <bridge> <port> <prio>  set port priority
        show                                    show a list of bridges
        showmacs        <bridge>                show a list of mac addrs
        showstp         <bridge>                show bridge stp info
        stp             <bridge> <state>        turn stp on/off

Creating a bridge device

The command

 brctl addbr "bridgename"

creates a logical bridge instance with the name bridgename. You will need at least one logical instance to do any bridging at all. You can interpret the logical bridge as a container for the interfaces taking part in the bridging. Each bridging instance is represented by a new network interface.

The corresponding shutdown command is:

 brctl delbr bridgename

Adding devices to a bridge

The command

 brctl addif bridgename device

adds the network device device to take part in the bridging of “bridgename.” All the devices contained in a bridge act as one big network. It is not possible to add a device to multiple bridges or bridge a bridge device, because it just wouldn’t make any sense! The bridge will take a short amount of time when a device is added to learn the Ethernet addresses on the segment before starting to forward.

The corresponding command to take an interface out of the bridge is:

 brctl delif  bridgename device

Showing devices in a bridge

The brctl show command gives you a summary about the overall bridge status, and the instances running as shown below:

 # brctl addbr br549
 # brctl addif br549 eth0
 # brctl addif br549 eth1
 # brctl show
 bridge name     bridge id               STP enabled     interfaces
 br549           8000.00004c9f0bd2       no              eth0
                                                         eth1

Once a bridge is running the brctl showmacs will show information about network addresses of traffic being forwarded (and the bridge itself).

 # brctl showmacs br549
 port no mac addr                is local?       ageing timer
   1     00:00:4c:9f:0b:ae       no                17.84
   1     00:00:4c:9f:0b:d2       yes                0.00
   2     00:00:4c:9f:0b:d3       yes                0.00
   1     00:02:55:1a:35:09       no                53.84
   1     00:02:55:1a:82:87       no                11.53
  ...

The aging time is the number of seconds a MAC address will be kept in the forwarding database after having received a packet from this MAC address. The entries in the forwarding database are periodically timed out to ensure they won’t stay around forever. Normally there should be no need to modify this parameter, but it can be changed with (time is in seconds).

  # brctl setageing bridgename time

Setting ageing time to zero makes all entries permanent.

Spanning Tree Protocol

If you are running multiple or redundant bridges, then you need to enable the Spanning Tree Protocol (STP) to handle multiple hops and avoid cyclic routes.

 # brctl stp br549 on

You can see the STP parameters with:

 # brctl showstp br549
 br549
  bridge id              8000.00004c9f0bd2
  designated root        0000.000480295a00
  root port                 1                    path cost                104
  max age                  20.00                 bridge max age           200.00
  hello time                2.00                 bridge hello time         20.00
  forward delay           150.00                 bridge forward delay      15.00
  ageing time             300.00                 gc interval                0.00
  hello timer               0.00                 tcn timer                  0.00
  topology change timer     0.00                 gc timer                   0.33
  flags
 
 eth0 (1)
  port id                8001                    state                   forwarding
  designated root        0000.000480295a00       path cost                100
  designated bridge      001e.00048026b901       message age timer         17.84
  designated port        80c1                    forward delay timer        0.00
  designated cost           4                    hold timer                 0.00
  flags
 
 eth1 (2)
  port id                8002                    state                   disabled
  designated root        8000.00004c9f0bd2       path cost                100
  designated bridge      8000.00004c9f0bd2       message age timer          0.00
  designated port        8002                    forward delay timer        0.00
  designated cost           0                    hold timer                 0.00
  flags

STP tuning

There are a number of parameters related to the Spanning Tree Protocol that can be configured. The code autodetects the speed of the link and other parameters, so these usually don’t need to be changed.

Bridge priority

Each bridge has a relative priority and cost. Each interface is associated with a port (number) in the STP code. Each has a priority and a cost, that is used to decide which is the shortest path to forward a packet. The lowest cost path is always used unless the other path is down. If you have multiple bridges and interfaces then you may need to adjust the priorities to achieve optimium performance.

  # brctl setbridgeprio bridgename priority

The bridge with the lowest priority will be elected as the root bridge. The root bridge is the “central” bridge in the spanning tree.

Path priority and cost

Each interface in a bridge could have a different speed and this value is used when deciding which link to use. Faster interfaces should have lower costs.

 # brctl setpathcost bridge port cost

For multiple ports with the same cost there is also a priority

Forwarding delay

Forwarding delay time is the time spent in each of the Listening and Learning states before the Forwarding state is entered. This delay is so that when a new bridge comes onto a busy network it looks at some traffic before participating.

 #  brctl setfd bridgename time

Hello time

Periodically, a hello packet is sent out by the Root Bridge and the Designated Bridges. Hello packets are used to communicate information about the topology throughout the entire Bridged Local Area Network.

 # brctl sethello bridgename time

Max age

If a another bridge in the spanning tree does not send out a hello packet for a long period of time, it is assumed to be dead. This timeout is set with:

 # brctl maxage  bridgename time

Multicast (IGMP) snooping

IGMP snooping support is not yet included in bridge-utils or iproute2, but it can be easily controlled through sysfs interface. For brN, the settings can be found under /sys/devices/virtual/net/brN/bridge.

multicast_snooping

This option allows the user to disable IGMP snooping completely. It also allows the user to reenable snooping when it has been automatically disabled due to hash collisions. If the collisions have not been resolved however the system will refuse to reenable snooping.

multicast_router

This allows the user to forcibly enable/disable ports as having multicast routers attached. A port with a multicast router will receive all multicast traffic.

The value 0 disables it completely. The default is 1 which lets the system automatically detect the presence of routers (currently this is limited to picking up queries), and 2 means that the ports will always receive all multicast traffic.

Note: this setting can be enabled/disable on a per-port basis, also through sysfs interface (e.g. if eth0 is some bridge’s active port, then you can adjust /sys/…../eth0/brport/multicast_router)

hash_{max,elasticity}

These settings allow the user to control the hash elasticity/max parameters. The elasticity setting does not take effect until the next new multicast group is added. At which point it is checked and if after rehashing it still can’t be satisfied then snooping will be disabled.

The max setting on the other hand takes effect immediately. It must be a power of two and cannot be set to a value less than the current number of multicast group entries. This is the only way to shrink the multicast hash.

remaining multicast_* options

These allow the user to control various values related to IGMP snooping.

More details about the options, some discussions and rationale can be found inhttp://thread.gmane.org/gmane.linux.network/153338

Sample setup

The basic setup of a bridge is done like:

 # ifconfig eth0 0.0.0.0
 # ifconfig eth1 0.0.0.0
 # brctl addbr mybridge
 # brctl addif mybridge eth0
 # brctl addif mybridge eth1 
 # ifconfig mybridge up

This will set the host up as a pure bridge, it will not have an IP address for itself, so it can not be remotely accessed (or hacked) via TCP/IP.

Optionally you can configure the virtual interface mybridge to take part in your network. It behaves like one interface (like a normal network card). Exactly that way you configure it, replacing the previous command with something like:

 # ifconfig mybridge 192.168.100.5 netmask 255.255.255.0

If you want your bridge to automatically get its IP address from the ADSL modem via DHCP (or a similar configuration), do this:

 # ifconfig eth0 0.0.0.0
 # ifconfig eth1 0.0.0.0
 # brctl addbr mybridge
 # brctl addif mybridge eth0
 # brctl addif mybridge eth1 
 # dhclient mybridge

If you do this many times, you may end up with lots of dhclient processes. Either kill them impolitely or learn aboutomshell(1).

Configuration with /etc/net

In /etc/net we first configure two ethernet devices port0 and port1:

 # cat >> /etc/net/iftab
 port0 mac 00:13:46:66:01:5e
 port1 mac 00:13:46:66:01:5f
 ^D
 # mkdir /etc/net/ifaces/port0
 # cat > /etc/net/ifaces/port0/options
 TYPE=eth
 MODULE=via-rhine
 # mkdir /etc/net/ifaces/port1
 # cat > /etc/net/ifaces/port1/options
 TYPE=eth
 MODULE=via-rhine
 ^D

Then we describe the bridge:

 # mkdir /etc/net/ifaces/mybridge
 # cat > /etc/net/ifaces/mybridge/options
 TYPE=bri
 HOST='port0 port1'
 ^D
 # cat > /etc/net/ifaces/mybridge/brctl
 stp AUTO on
 ^D

Now we can use “ifup mybridge” to bring it up. port0 and port1 will be brought up automatically.

FAQ

What does a bridge do?

A bridge transparently relays traffic between multiple network interfaces. In plain English this means that a bridge connects two or more physical Ethernets together to form one bigger (logical) Ethernet.

Is it protocol independent?

Yes. The bridge knows nothing about protocols, it only sees Ethernet frames. As such, the bridging functionality is protocol independent, and there should be no trouble relaying IPX, NetBEUI, IP, IPv6, etc.

Why is this code better than a switch?

Please note that this code wasn’t written with the intent of having Linux boxes take over from dedicated networking hardware. Don’t see the Linux bridging code as a replacement for switches, but rather as an extension of the Linux networking capabilities. Just as there are situations where a Linux router is better than a dedicated router (and vice versa), there are situations where a Linux bridge is better than a dedicated bridge (and vice versa).

Most of the power of the Linux bridging code lies in its flexibility. There is a whole lot of bizarre stuff you can do with Linux already (read Linux Advanced Routing and Traffic Control document to see some of the possiblities), and the bridging code adds some more filter into the mix.

One of the most significant advantages of a Linux solution over a dedicated solution that come to mind is Linux’ extensive firewalling capabilities. It is possible to use the full functionality of netfilter (iptables) in combination with bridging, which provides way more functionality than most proprietary offerings do.

Why is this code worse than a switch?

In order to act a a bridge, the network device must be placed into promiscuous mode which means it receives all traffic on a network. On a really busy network, this can eat significant bandwidth out of the processor, memory slowing the system down. The answer is to setup either a separate dedicated Linux box as the bridge, or use a hardware switch.

What is the performance of the bridge?

The performance is limited by the network cards used and the processor. A research paper was done by James Yu at Depaul University comparing Linux bridging with a Catalyst switch Yu-Linux-TSM2004.pdf

My bridge does not show up in traceroute!

It’s not supposed to. The operation of a bridge is (supposed to be) fully transparent to the network, the networks that a bridge connects together are actually to be viewed as one big network. That’s why the bridge does not show up in traceroute; the packets do not feel like they are crossing a subnet boundary.

For more information on this, read a book about TCP/IP networking.

It doesn’t work!

It says: “br_add_bridge: bad address” when I try to add a bridge!

Either your kernel is old (2.2 or earlier), or you forgot to configure Ethernet bridging into your kernel.

No traffic gets trough (except ARP and STP)

Your kernel might have ethernet filtering (ebtables, bridge-nf, arptables) enabled, and traffic gets filtered. The easiest way to disable this is to go to /proc/sys/net/bridge. Check if the bridge-nf-* entries in there are set to 1; in that case, set them to zero and try again.

 # cd /proc/sys/net/bridge
 # ls
 bridge-nf-call-arptables  bridge-nf-call-iptables
 bridge-nf-call-ip6tables  bridge-nf-filter-vlan-tagged
 # for f in bridge-nf-*; do echo 0 > $f; done

Does bridging work on 2.2?

The base kernel for 2.2, did not support the current bridging code. The original development was on 2.2, and there used to be patches available for it. But these patches are no longer maintained.

Are there plans for RSTP (802.1w) support?

Yes, work is being done to integrate RSTP support in a future 2.6 release. The code was done for a version of 2.4 and needs to be cleaned up, tested and updated.

What can be bridged?

Linux bridging is very flexible; the LAN’s can be either traditional Ethernet device’s, or pseudo-devices such as PPP, VPN’s or VLAN’s. The only restrictions are that the devices:

  • All devices share the same maximum packet size (MTU). The bridge doesn’t fragment packets.
  • Devices must look like Ethernet. i.e have 6 byte source and destination address.
  • Support promiscuous operation. The bridge needs to be able to receive all network traffic, not just traffic destined for its own address.
  • Allow source address spoofing. The bridge must be able to send data over network as if it came from another host.

Can I do bridging in combination with netfilter/iptables?

Yes. The code for this is available in most kernels. See ebtables project.

Does it work with Token Ring , FDDI, or Firewire?

No, the addressing and frame sizes are different.

I keep getting the message retransmitting tcn bpdu!

It means that your Linux bridge is retransmitting a Topology Change Notification Bridge Protocol Data Unit (so now you know what the letters are for :-). Seriously, there is probably another switch (or Linux bridge) nearby that isn’t complying to the rules of the spanning tree protocol (which is what bridges speak).

In each bridged local area network, there is one ‘master bridge’, which is also called the root bridge. You can find out which bridge this is using brctl.

When the topology of a bridged local area network changes (f.e. somebody unplugs a cable between two bridges), the bridge which detects this sends a topology change notification to the root bridge. The root bridge will respond to this by setting a ‘topology changed’ bit in the hello packets it sends out for the next X seconds (X usually being 30). This way, all bridges will learn of the topology change, so that they can take measures like timing out learned MAC entries faster for example.

After having sent out a topology change notification, if a bridge does not find the ‘topology changed’ bit set in the hello packets received (which in essence serves as the ‘acknowledgment’ of the topology change notification), it concludes that the topology change notification was lost. So it will retransmit it. However, some bridges run lobotomized implementations of the Spanning Tree Protocol which causes them not to acknowledge topology change notifications. If you have one of those bridges as your root bridge, all of the other bridges will keep retransmitting their topology changed notifications. Which will lead to these kinds of syslog messages.

There are a number of things you can do:

  • Find out which bridge is the root bridge, find out where it is located, and what internetworking software it runs. Please report this info to the mailing list (or to me directly), so that I can keep a blacklist.
  • Force the linux bridge to be the root bridge. See what the priority of the current root bridge is, and use the brctl ‘setbridgeprio’ command to set the priority of the linux bridge to 1 lower. (The bridge with the lowest priority always becomes the root bridge.)
  • Disable the spanning tree protocol on your linux bridge altogether. In this case, watch out for bridging loops! If you have loops in your topology, and if no bridge in the loop is running the spanning tree protocol, mayhem will come your way, as packets will be forwarded forever. Don’t Do This(TM).

It doesn’t work with my regular Ethernet card!

Unfortunately, some network cards have buggy drivers that fail under load. The situation is improving, so having a current kernel and network driver can help. Also try swapping with another brand.

Please report all problems to the Bridge mailing list: bridge@osdl.org. If your network card doesn’t work (even without bridging) then try the Linux networking mailing list linux-net@vger.kernel.org

It doesn’t work with my Wireless card!

This is a known problem, and it is not caused by the bridge code. Many wireless cards don’t allow spoofing of the source address. It is a firmware restriction with some chipsets. You might find some information in the bridge mailing list archives to help. Has anyone found a way to get around Wavelan not allowing anything but its own MAC address? (answer by Michael Renzmann (mrenzmann at compulan.de))

Well, for 99% of computer users there will never be a way to get rid of this. For this function a special firmware is needed. This firmware can be loaded into the RAM of any WaveLAN card, so it could do its job with bridging. But there is no documentation on the interface available to the public. The only way to achieve this is to have a full version of the hcf library which controls every function of the card and also allows accessing the card’s RAM. To get this full version Lucent wants to know that it will be a financial win for them, also you have to sign an NDA. So be sure that you won’t most probably get access to this peace of software until Lucent does not change its mind in this (which I doubt never will happen).

If you urgently need to have a wireless LAN card which is able to bridge, you should use one of those having the prism chipset onboard (manufactured by Harris Intersil). There are drivers for those cards available at www.linux-wlan.com (which is the website from Absoval), and I found a mail that says that there is the necessary firmware and an upload tool available for Linux to the public. If you need additional features of an access point you should also talk to Absoval.

I still don’t understand!!

Doing full bridging of wireless (802.11) requires supporting WDS . The current implementation doesn’t do it.

It is possible to do limited wireless to Ethernet functionality with some wireless drivers. This requires the device to be able to support a different sender address and source address. That is what WDS provides.

There are ways to make it work, but it is not always straightforward and you probably won’t get it right without a pretty solid understanding of 802.11, it’s modes, and the frame header format.

I get the error ‘too much work in interrupt’

This is because the network card is getting lots of packets. There are a few things you can try. First, build the driver with NAPI support (if it isn’t on by default). NAPI means the driver will do the receive processing at soft IRQ, not at the low level interrupt.

If the driver doesn’t support NAPI, you can try to increase the amount of work a driver will attempt to do in an interrupt. For 3c59x this is done with the option max_interrupt_work (so add something like ‘options 3c59x max_interrupt_work=10000’ to your /etc/modules.conf file), other cards might have similar options.

Does DHCP work over/through a bridge?

The bridge will forward DHCP traffic (broadcasts) and responses. You can also use DHCP to set the local IP address of the bridge pseudo-interface.

One common mistake is that the default bridge forwarding delay setting is 30 seconds. This means that for the first 30 seconds after an interface joins a bridge, it won’t send anything. This is because if the bridge is being used in a complex topology, it needs to discover other bridges and not create loops. This problem was one of the reasons for the creation of Rapid Spanning Tree Protocol (RSTP).

If the bridge is being used standalone (no other bridges near by). Then it is safe to turn the forwarding delay off (set it to zero), before adding interface to a bridge. Then you can run DHCP client right away.

 # brctl setfd br0 0
 # brctl addif br0 eth0
 # dhclient eth0

Contact Info

The code is currently maintained by Stephen Hemminger <shemminger@osdl.org> for both 2.4 and 2.6 Linux. Bridge bugs and enhancements are discussed on the Bridge mailing list <bridge@osdl.org>. The list is open to anyone interested, use the web mailman interface http://lists.osdl.org/mailman/listinfo/bridge to subscribe.

External Links

Smooth-Sec – a fully-ready IDS/IPS (Intrusion Detection/Prevention System) Linux distribution


Smooth-Sec

Smooth-Sec is a fully-ready IDS/IPS (Intrusion Detection/Prevention System) Linux distribution based on Debian 7 (wheezy), available for 32 and 64 bit architecture. The distribution includes the latest version of Snorby, Snort, Suricata, PulledPork and Pigsty. An easy setup process allows to deploy a complete IDS/IPS System within minutes, even for security beginners with minimal Linux experience.

Source && Download

CF_skull

Installation

1) Booting Smoothsec.

Smooth-Sec

2) Language selection.

Alt attribute text Here

3) Select a location.

Alt attribute text Here

4) Keyboard setup.

Alt attribute text Here

5) Hostname.

Alt attribute text Here

6) Domain name.

Alt attribute text Here

7) Disk partitioning.

Alt attribute text Here

8) Confirm disk partitioning.

Alt attribute text Here

9) Mirror country setup.

Alt attribute text Here

10) Mirror location setup.

Alt attribute text Here

11) Apt proxy setup.

Alt attribute text Here

12) Grub installation.

Alt attribute text Here

13) End of the installation.

Alt attribute text Here

14) First boot login screen.

Alt attribute text Here

15) First setup.

Alt attribute text Here

How to Get Started With pfSense as a FreeBSD Router


pfSense


pfSense is a free, open source customized distribution of FreeBSD tailored for use as a firewall and router. In addition to being a powerful, flexible firewalling and routing platform, it includes a long list of related features and a package system allowing further expandability without adding bloat and potential security vulnerabilities to the base distribution. pfSense is a popular project with more than 1 million downloads since its inception, and proven in countless installations ranging from small home networks protecting a PC and an Xbox to large corporations, universities and other organizations protecting thousands of network devices.

This project started in 2004 as a fork of the m0n0wall project, but focused towards full PC installations rather than the embedded hardware focus of m0n0wall. System also offers an embedded image for Compact Flash based installations, however it is not our primary focus.

Click here for details

It is supported by the open source community under the General Public License (GPL) which makes it Free to all to use. As with many LINUX distribution, The minimum hardware requirements to use pfSense is a computer with the following:

  • CPU – 100 MHz Pentium
  • RAM – 128 MB
  • CD-ROM for initial installation
  • 1 GB hard drive
  • Two Network Interface Cards

Basic Install and Setup
Get p fSense
Download the latest version

Install

Boot your chosen PC with the CD. You will be present with the following “Welcome” screen.
For our basic install, you can press [Enter] for the default option.

pfsense1

PFsense2

If you can see the “Configure Console” screen, chances are there aren’t any changes you need to make to the console. Press the Down arrow on your keyboard to highlight the “<Accept these Setting>” option and press [Enter]

PFSense3

On the “Select Task” window, select the “<Quick/Easy Install>” and press [Enter].

PFSense4

At the “Are you SURE?” screen, confirm your decision to install by highlighting the “< OK >”  option and pressing [Enter].
Any data currently on the first hard drive of the system will be destroyed !

PFSense5

It can take up to 10 minutes for install to finish, depending on your hardware.
installer is formatting your drive and copying the software to your system.

PFSense6

At the “Install Kernel(s)” screen, ensure

“< Symmetric multiprocessing kernel (more than one processor) >” is highlighted and press [Enter].

PFsense7

At the “Reboot” screen, remove the CD and ensure that “< Reboot >” is highlighted and press [Enter].

PFSense8

After the system reboots, you will be presented with the initial “Welcome” menu.
Press [Enter] to select the default

PFSense9

During the boot phase, compatible network interface cards will be displayed.

PFSense10

Since this is a basic setup, we will not want to configure “VLAN”
Type “n” and press [Enter]

PFSense11

From the list of valid interfaces, type the name of the network interface card
that will be connected directly to the Internet (cable modem, dsl, etc)

PFSense12

From the list of valid interfaces, type the name of the network interface card that will be connected to your internal network. This will serve as your “LAN” interface. Repeat this step for each additional network interface card listed as a valid interface  Once you are finished, press the [Enter] to select nothing and move to the next step of the setup.

PFSense13

Confirm that you have selected the correct network interface cards for each interface on
your firewall and type “y” and press [Enter].

PFSense14

Once you are complete this initial setup, you will be presented with the console menu. Your firewall is now up and running. We have finished all configuration steps required to be done from the console. You can actually disconnect the monitor and keyboard from the system (as an added security precaution) for all other configuration will be done via the web console.

PFSense15

Open up the web browser and enter the default IP Address, 192.168.1.1,
Username: admin and Password: pfsense to get to the page as below

1st

After successfully login to your box, you will be presented with the Status Dashboard which provides you with a summary of your system information along with the status of your interfaces installed. The dashboard is configurable and can include additional information about other components of your firewall.

2nd

From the System menu select Setup Wizard

3rd

You should then be greeted with the setup wizard, click the Next button to continue.

4th

Complete the “General Information” section

gen

Change to your local time zone.

time

WAN Interface configuration.
You need to authenticate to your ISP provider in order to access the Internet,

wan

“Configure LAN Interface” screen

lan

After configuring a new password, system will require your login again with the new password.
Click the Reload button to refresh the screen and login with your new password.

reload

Now we have successfully configured the basic router setting

pfsense

Make Sure to check out awesome powerful package manager

package

and also Network monitoring

monitor

Next time we might do Snort IDS Setup

snort

Iptables Firewall Cheatsheet


How To: IPTables Firewall

Iptables is a standard firewall included in most Linux distributions by default. It is actually a front end to the kernel-level netfilter hooks that can manipulate the Linux network stack. It works by matching each packet that crosses the networking interface against a set of rules to decide what to do.

Basics

First, you should be aware that iptables commands must be run with root privileges. Let’s start head-first. This is an example output from the command sudo iptables -L -v:

Note that these are INPUT (in-bound traffic) examples.
target   prot   opt in  out source destination
ACCEPT   all    --  lo  any anywhere anywhere
ACCEPT   all    --  any any anywhere anywhere ctstate RELATED,ESTABLISHED
ACCEPT   tcp    --  any any anywhere anywhere tcp dpt:ssh
ACCEPT   tcp    --  any any anywhere anywhere tcp dpt:http
ACCEPT   tcp    --  any any anywhere anywhere tcp dpt:https
DROP     all    --  any any anywhere anywhere
iptables rules are followed in order. The first found to handle the traffic will determine what happens to the data being checked.

Let’s quickly go over this list of these rules so you can get the feel for it:

  1. Accept all traffic on “lo”, the “loopback” interface. This is essentially saying “Allow all internal traffic to pass through”
  2. Accept all traffic from currently established connections and related (Typically set so you don’t accidentaly block yourself from the server when editing firewall rules)
  3. Accept TCP traffic over port 22 (which iptables labels “ssh” by default).
  4. Accept TCP traffic over port 80 (which iptables labels “http” by default)
  5. Accept TCP traffic over port 443 (which iptables labels “https” by default)
  6. Drop anything and everything else

See how the last rule says to DROP all from/to anywhere? If a packet has passed all other rules without matching, it will reach this rule, which says to DROP the data. This means that we’ve only allowed current connections, SSH (tcp port 22), http (tcp port 80) and https (tcp port 443) traffic into our server! Everything else is blocked.

Again ( I can’t stress this enough since it is a source of so many problems ) The first rule that matches the traffic type (protocol, interface, source/destination and other types) will decide how to handle the traffic. Rules below a match are not applied. If more than one rule match the traffic type, then the 2nd rule will never be reached.

Now let’s go to the real world example On a fresh system ( Ubuntu in this case ) issuing iptables -L will produce the following output:

sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

As you can see, we have our three default chains (INPUT,OUTPUT, and FORWARD). We can see each chain’s default policy (each chain has ACCEPT as its default policy) and we can also see some column headers – but we don’t see any actual rules. This is because Ubuntu doesn’t ship with a default rule set.

We can see the output in a format that reflects the commands necessary to enable each rule and policy by instead using the -S flag:

sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT

You should ensure that the default policy on your INPUT and OUTPUT chains are set to ACCEPT.  You can do this by typing:

sudo iptables -P INPUT ACCEPT
sudo iptables -P OUTPUT ACCEPT
sudo iptables -F

If you have rules in place and wish to scrap them and start over, you can flush the current rules by typing:

sudo iptables -F

Make A Rule

We are going to start with the rule that explicitly accepts SSH connection.

sudo iptables -A INPUT -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT

This may look incredibly complicated, but most of it will make sense when we go over the components:

  • -A INPUT: The -A flag appends a rule to the end of a chain. This is the portion of the command that tells iptables that we wish to add a new rule, that we want that rule added to the end of the chain, and that the chain we want to operate on is the INPUT chain.
  • -m conntrack: iptables has a set of core functionality, but also has a set of extensions or modules that provide extra capabilities. In this portion of the command, we’re stating that we wish to have access to the functionality provided by the conntrack module. This module gives access to commands that can be used to make decisions based on the packet’s relationship to previous connections.
  • –ctstate: This is one of the commands made available by calling the conntrack module. This command allows us to match packets based on how they are related to packets we’ve seen before.
  • We pass it the value of ESTABLISHED to allow packets that are part of an existing connection. We pass it the value of RELATED to allow packets that are associated with an established connection. This is the portion of the rule that matches our current SSH session.
  • * -j ACCEPT: This specifies the target of matching packets. Here, we tell iptables that packets that match the preceding criteria should be accepted and allowed through.

We put this rule at the beginning because we want to make sure the connections we are already using are matched, accepted, and pulled out of the chain before reaching any DROP rules. We can see the changes if we list the rules:

sudo iptables -L
Chain INPUT (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination

Now that you know the general syntax, let’s continue by adding some more cases where we want to accept the connection.

We have told iptables to keep open any connections that are already open and to allow new connections related to those connections. Now we want to keep two specific ports open. We want to keep our SSH port and also our web server port (default 80) open.

The two lines we’re going to use to add these rules are:

sudo iptables -A INPUT -p tcp --dport 22 -j ACCEPT
sudo iptables -A INPUT -p tcp --dport 80 -j ACCEPT

As you can see, these are very similar to our first rule, but more simple. The new options are:

  • -p tcp: This option matches packets if the protocol being used is TCP.
  • –dport: This option is available if the -p tcp flag is given. It gives a further requirement of matching the destination port for the matching packet. The first rule matches for TCP packets destined for port 22, while the second rule matches TCP traffic pointed towards port 80.

There is one more accept rule that we need to ensure that our server can function correctly. Often, services on the computer communicate with each other by sending network packets to each other. They do this by utilizing a pseudo network interface called the loopback device, which directs traffic back to itself rather than to other computers.

The rule we need to add is this:

sudo iptables -I INPUT 1 -i lo -j ACCEPT

This looks a bit different than our other commands. Let’s go over what it is doing:

  • -I INPUT 1: The -I flag tells iptables to insert a rule. This is different than the -A flag which appends a rule to the end. The -I flag takes a chain and the rule position where you want to insert the new rule. In this case, we’re adding this rule as the very first rule of the INPUT chain. This will bump the rest of the rules down. We want this at the top because it is fundamental and should not be affected by subsequent rules.
  • * -i lo: This component of the rule matches if the interface that the packet is using is the “lo” interface. The “lo” interface is another name for the loopback device. This means that any packet using that interface to communicate (packets generated on our server, for our server) should be accepted.

To see our current rules, we should use the -S flag. This is because the -L flag doesn’t include some information, like the interface that a rule is tied to, which is an important part of the rule we just added:

sudo iptables -S
-P INPUT ACCEPT
-P FORWARD ACCEPT
-P OUTPUT ACCEPT
-A INPUT -i lo -j ACCEPT
-A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 22 -j ACCEPT
-A INPUT -p tcp -m tcp --dport 80 -j ACCEPT

Drop Rules

If a packet enters the INPUT chain and doesn’t match one of the four rules that we made, it is being passed to our default policy, which is to accept the packet anyways. We need to change this. There are two different ways that we can do this, with some pretty important differences. The first way we could do this is to modify the default policy of our INPUT chain. We can do this by typing:

sudo iptables -P INPUT DROP

This will catch any packets that fall through our INPUT chain, and drop them. This is what we call a default drop policy. One of the implications of this type of a design is that it falls back on dropping packets if the rules are flushed. This may be more secure, but also can have serious consequences if you don’t have another way of accessing your server. The alternative approach is to keep the default policy for the chain as accept and add a rule that drops every remaining packet to the bottom of the chain itself. If you changed the default policy for the INPUT chain above, you can set it back to follow along by typing:

sudo iptables -P INPUT ACCEPT

Now, you can add a rule to the bottom of the chain that will drop any remaining packets:

sudo iptables -A INPUT -j DROP

The result under normal operating conditions is exactly the same as a default drop policy. This rule works by matching every remaining packet that reaches it. This prevents a packet from ever dropping all of the way through the chain to reach the default policy. Of course, this also means that any additional rule that you wish to add to the end of the chain will have to be added before the drop rule. You can do this either by temporarily removing the drop rule:

sudo iptables -D INPUT -j DROP
sudo iptables -A INPUT new_rule
sudo iptables -A INPUT -j DROP

Or, you can insert rules that you need at the end of the chain (but prior to the drop) by specifying the line number. To insert a rule at line number 4, you could type:

sudo iptables -I INPUT 4 new_rule

If you are having trouble finding a line number, you can tell iptables to number the rules:

sudo iptables -L --line-numbers
Chain INPUT (policy DROP)
num  target     prot opt source               destination         
1    ACCEPT     all  --  anywhere             anywhere            
2    ACCEPT     all  --  anywhere             anywhere             ctstate RELATED,ESTABLISHED
3    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:ssh
4    ACCEPT     tcp  --  anywhere             anywhere             tcp dpt:http

Chain FORWARD (policy ACCEPT)
num  target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
num  target     prot opt source               destination

Deleting Rules

Let’s say we want to change our SSH port to a non-standard port.  We can delete the SSH rule in two ways:

# Delete at position 3
sudo iptables -D INPUT 3  # Or delete by the rule:
sudo iptables -D INPUT -p tcp --dport 22-j ACCEPT

Then we can insert our new SSH rule at port 1234:

sudo iptables -I INPUT 3-p tcp --dport 1234-j ACCEPT

Save iptables

By default, the rules that you add to iptables are ephemeral. This means that when you restart your server, your iptables rules will be gone. This is actually a feature. However, most users will want a way to automatically save the rules you have created and to load them when the server starts. There are a few ways to do this, but the easiest way is with the iptables-persistent package. You can download this from Ubuntu’s default repositories:

sudo apt-get update
sudo apt-get install iptables-persistent

During the installation, you will be asked if you would like to save your current rules to be automatically loaded. If you are happy with your current configuration you can select to save your current rules. It will also ask you if you want to save the IPv6 rules that you have configured. These are configured through a separate utility called ip6tables which controls the flow of IPv6 packets in almost the same way. Once the installation is complete, you will have a new service called iptables-persistent that is configured to run at boot. This service will load in your rules and apply them when the server is started.

Troubleshooting ?

This is an optional step but it can be very useful in detecting network traffic problems.

Create a new chain called LOG:

iptables -N LOG

Route INPUT/OUTPUT/FORWARD to LOG chain (substitute CHAIN with the chain you want to monitor, such as “INPUT”):

iptables -A INPUT -j LOG

Now log the packets with this command:

iptables -A LOG -m limit --limit 60/min -j LOG --log-prefix "IPTables DROP: " --log-level 7

Now you can monitor your system messages to see which packets are being dropped. In Ubuntu, the messages can be read in real-time with the following command:

sudo tail -f /var/log/syslog

In CentOS, the messages can be read in real-time with the following command:

sudo tail -f /var/log/messages

The logs will list the interface, source port, destination port, and some other information about each packet dropped. This should help you figure out any issues that you may have.

OWASP ModSecurity Core Rule Set (CRS)


OWASP ModSecurity Core Rule Set (CRS)

The OWASP ModSecurity CRS Project’s goal is to provide an easily “pluggable” set of generic attack detection rules that provide a base level of protection for any web application.

Introduction

The OWASP ModSecurity CRS is a set of web application defense rules for the open source, cross-platform ModSecurityWeb Application Firewall (WAF).

Description

The OWASP ModSecurity CRS provides protections if the following attack/threat categories:

  • HTTP Protection – detecting violations of the HTTP protocol and a locally defined usage policy.
  • Real-time Blacklist Lookups – utilizes 3rd Party IP Reputation
  • HTTP Denial of Service Protections – defense against HTTP Flooding and Slow HTTP DoS Attacks.
  • Common Web Attacks Protection – detecting common web application security attack.
  • Automation Detection – Detecting bots, crawlers, scanners and other surface malicious activity.
  • Integration with AV Scanning for File Uploads – detects malicious files uploaded through the web application.
  • Tracking Sensitive Data – Tracks Credit Card usage and blocks leakages.
  • Trojan Protection – Detecting access to Trojans horses.
  • Identification of Application Defects – alerts on application misconfigurations.
  • Error Detection and Hiding – Disguising error messages sent by the server.

Licensing

OWASP ModSecurity CRS is free to use. It is licensed under the Apache Software License version 2 (ASLv2), so you can copy, distribute and transmit the work, and you can adapt it, and use it commercially, but all provided that you attribute the work and if you alter, transform, or build upon this work, you may distribute the resulting work only under the same or similar license to this one.

Open HUB

https://www.openhub.net/p/owasp-modsecurity-crs

more info can be found at: https://github.com/SpiderLabs/owasp-modsecurity-crs and here: https://www.owasp.org/index.php/Category:OWASP_ModSecurity_Core_Rule_Set_Project

Highly-available Squid forward proxies


Having learnt the hard way over the years, I always make sure to implement a set of firewall rules not just inbound to my servers, but also outbound for traffic leaving them.

A common behaviour of malicious users who may compromise a web app running on your server, is to upload and then potentially execute a payload that, in turn, goes and downloads more malware onto your machine from remote locations. Or, it may attempt to report back to a ‘command and control’ server, or be used to perform DDOS attacks or send spam on to other hosts. In effect, your machine becomes a ‘stepping stone’ with which to pivot and attack further targets. Unless you are super important, you or your server (or your data) aren’t likely to be the end target.

Thus an outbound firewall is a good second line of defense to try and prevent unauthorised traffic from leaving your machine.

It is relatively easy to whitelist your server’s upstream DNS providers, NTP servers and so on, in your outbound firewall rules. The IP addresses of these services rarely change.

But this presents a problem. Many applications and systems are designed, these days, to fetch data from authorised remote servers over HTTP. A couple of examples of this are:

  • Fetching software and security updates from upstream repositories (e.g APT repositories)
  • Communicating with APIs

In one case, I’ve seen the Drupal application use the ‘Sexybookmarks’ module to fetch assets such as CSS or JS from a remote Shareaholic.com and use that for constructing elements of the page on the site.

These HTTP examples are problematic for outbound firewalls, because they are typically domain based, e.g ‘security.ubuntu.com’ or ‘shareaholic.com’. It is more frequent that IP addresses change for other web apps, either as a result of Geo-IP magic, or applications behind Amazon Elastic loadbalancers that dynamically change IP all the time.

Sometimes it is practical to stay up to date with whether a domain has changed IP (hint: have a look at DNS-RR-Monitor) and make the modification to your firewall to suit. Sometimes it’s not.

So, what to do? How to whitelist outbound HTTP traffic by domain? Well, one option is to run a Squid forward proxy on your network. Squid allows you to whitelist any number of network ranges or domains (including wildcards). Here’s a brief example of the relevant Squid config:

acl safesites dstdomain.google.com fonts.googleapis.com github.com.newrelic.com archive.ubuntu.com security.ubuntu.com repo.percona.com updates.drupal.org pear.php.net db.local.clamav.nethttp_access allow safesites

So far, so good. You can configure your Drupal application to send outbound HTTP traffic via the proxy by filling in these values in the settings.php:

$conf[‘proxy_server’] = ”;
$conf[‘proxy_port’] = 8080;
$conf[‘proxy_username’] = ”;
$conf[‘proxy_password’] = ”;
$conf[‘proxy_user_agent’] = ”;
$conf[‘proxy_exceptions’] = array(‘127.0.0.1’, ‘localhost’);

Nothing too complex here. However, adding of a Squid forward proxy suddenly creates a new Single Point of Failure in your infrastructure. If all your outbound HTTP traffic is configured to route through a proxy, and that proxy goes offline, your app or system may start malfunctioning. Depending on how ‘highly available’ your systems need to be, this may be a problem.

Therefore, it may make sense to build a small ‘cluster’ of proxies, and use a failover solution to ensure there is always an active proxy available to answer a request from your servers.

I recently was able to configure a Pacemaker/Corosync solution to create an active/passive pair of Squid forward proxies. The primary Squid proxy holds an additional ‘floating’ IP address, and it’s this IP address I configure on relevant systems to be the Proxy server to use.

Should the primary Squid server go offline or its network stop functioning, the ‘passive’ Proxy server suddenly starts its Squid service and takes the floating IP for itself, sending gratuitous ARP announcements on the private LAN to let other hosts know its MAC address is now associated with this IP.

Pacemaker is a rather complex beast to set up configuration for, so I thought I’d share my configs, written for the versions that come with Ubuntu 12.04 LTS. I won’t go into how to install Corosync and Pacemaker, there are plenty of guides already for that on the net.

/etc/corosync/corosync.conf

compatibility: whitetanktotem {
version: 2
secauth: on
threads: 0
rrp_mode: active
token: 10000
transport: udpu
interface {
ringnumber: 0
bindnetaddr: 192.168.1.0
mcastport: 5405
ttl: 1
member {
memberaddr: 192.168.1.10
}
member {
memberaddr: 192.168.1.11
}
}
}
logging {
fileline: off
to_stderr: no
to_logfile: no
to_syslog: yes
debug: off
logfile: /var/log/corosync/corosync.log
timestamp: on
logger_subsys {
subsys: AMF
debug: off
}
}

/etc/corosync/service.d/pacemaker

service {
name: pacemaker
ver: 1
}

Pacemaker config:

node proxy-01.example.com \
attributes standby=”off”
node proxy-02.example.com \
attributes standby=”off”
primitive FloatingIP ocf:heartbeat:IPaddr2 \
params ip=”192.168.1.253″ cidr_netmask=”24″ nic=”eth1″ \
op monitor interval=”30s”
primitive Proxy ocf:heartbeat:Squid \
params squid_exe=”/usr/sbin/squid3″ squid_conf=”/etc/squid3/squid.conf”squid_pidfile=”/run/squid3.pid” squid_port=”3128″ squid_stop_timeout=”30″ debug_mode=”v”debug_log=”/var/log/cluster.log” \
op start interval=”0″ timeout=”60s” \
op stop interval=”0″ timeout=”120s” \
op monitor interval=”20s” timeout=”30s”
primitive p_MailTo ocf:heartbeat:MailTo \
params email=”alerts AT example DOT com” \
op monitor interval=”10″ timeout=”10″ depth=”0″
group ProxyAndIP FloatingIP Proxy
property $id=”cib-bootstrap-options” \
dc-version=”1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c” \
cluster-infrastructure=”openais” \
expected-quorum-votes=”2″ \
no-quorum-policy=”ignore” \
stonith-enabled=”false”
rsc_defaults $id=”rsc-options” \
resource-stickiness=“200″

Here you can see the Proxy primitive and the relevant arguments that it expects in order to manage the Squid service. Kind of weird to write ‘squid_exe’ on a Linux box, almost looks Windows-ish :)

A couple other things to note in my configuration above:

  • You can see I have configured a MailTo primitive. This is used to alert me when a failover occurs.
  • Yes, yes, we are ignoring a lack of quorum and STONITH is disabled. I figured that a Squid service is effectively ‘stateless’ – it isn’t a database or filesystem that is holding crucial data, so I am less worried about Split Brain. My config isn’t going anywhere and I am not concerned about caching upstream HTTP results, I can just restart the VM if I need to get the cluster services back in order. Obviously if this was a DRBD cluster or similar, I would have a third node (either in standby mode for quorum-only, or otherwise), and also STONITH devices to shut the machines down (fencing) for me.
  • In my failover tests, I discovered that Pacemaker could not actually start or shut down the Squid service properly. The ‘Failed actions’ output of ‘crm_mon’ would show something like ‘Proxy_start_0 (node=proxy-01.example.com, call=3, rc=-2, status=Timed Out)’. It turns out that Pacemaker’s confused if Squid isn’t explicitly set to listen only on IPv4. By default, the Squid service would start up on something like :::3128. I found I had to explicitly put
    http_port 0.0.0.0:3128

    in the /etc/squid3/squid.conf to get it to work at all. So I guess it means it isn’t IPV6-friendly. Though looking at the thread linked to above, maybe this is fixed in newer versions.

Configuring Linux To Act As A Firewall With Iptables


What exactly is a firewall? As in the non-computer world, a firewall acts as a physical barrier to prevent fires from spreading. In the computer world too, the firewall acts in a similar manner, only the fires that they prevent from spreading are the attacks, which crackers generate when the computer is on the Internet. Therefore, a firewall can also be called a packet filter, which sits between the computer and the Internet, controlling and regulating the information flow.

Most of the firewalls in use today are the filtering firewalls. They sit between the computer and the Internet and limit access to only specific computers on the network. It can also be programmed to limit the type of communication, and selectively permit or deny several Internet services.

Organizations receive their routable IP addresses from their ISPs. However, the number of IP addresses given is limited. Therefore, alternate ways of sharing the Internet services have to be found without every node on the LAN getting a public IP address. This is done commonly by using private IP addresses, so that all nodes are able to access properly both external and internal network services.

Firewalls are used for receiving incoming transmissions from the Internet and routing the packets to the intended nodes on the LAN. Similarly, firewalls are also used for routing outgoing requests from a node on the LAN to the remote Internet service.

This method of forwarding the network traffic may prove to be dangerous, when modern cracking tools can spoof the internal IP addresses and allow the remote attacker to act as a node on the LAN. In order to prevent this, the iptables provide routing and forwarding policies, which can be implemented for preventing abnormal usage of networking resources. For example, the FORWARD chain lets the administrator control where the packets are routed within a LAN.

LAN nodes can communicate with each other, and they can accept the forwarded packets from the  firewall, with their internal IP addresses. However, this does not give them the facility to communicate to the external world and to the Internet.

For allowing the LAN nodes that have private IP addresses to communicate with the outside world, the firewall has to be configured for IP masquerading. The requests that LAN nodes make, are then masked with the IP addresses of the firewall’s external device, such as eth0.

HOW IPTABLES CAN BE USED TO CONFIGURE YOUR FIREWALL

Whenever a packet arrives at the firewall, it will be either processed or disregarded. The disregarded packets would normally be those, which are malformed in some way or are invalid in some technical way. Based on the packet activity of those that are processed, the packets are enqueued in one of the three builtin ‘tables.’ The first table is the mangle table. This alters the service bits in the TCP header. The second table is the filter queue, which takes care of the actual filtering of the packets. This consists of three chains, and you can place your firewall policy rules in these chains (shown in the diagram below):

Forward chain: It filters the packets to be forwarded to networks protected by the firewall.

Input chain: It filters the packets arriving at the firewall.

Output chain: It filters the packets leaving the firewall.

The third table is the NAT table. This is where the Network Address Translation or NAT is performed. There are two built-in chains in this:

Pre-routing chain: It NATs the packets whose destination address needs to be changed.

Post-routing chain: It NATs the packets whose source address needs to be changed.

Whenever a rule is set, the table it belongs has to be specified. The ‘Filter’ table is the only exception. This is because most of the ‘iptables’ rules are the filter rules. Therefore, the filter table is the default table.

The diagram below shows the flow of packets within the filter table. Packets entering the Linux system follow a specific logical path and decisions are made backed on their characteristics.  The path shown below is independent of the network interface they are entering or exiting:

The Filter Queue Table

linux-ip-filter-table

Each of the chains filters data packets based on:

  • Source and Destination IP Address
  • Source and Destination Port number
  • Network interface (eth0, eth1 etc)
  • State of the packet

Target for the rule: ACCEPT, DROP, REJECT, QUEUE, RETURN and LOG

As mentioned previously, the table of NAT rules consists mainly of two chains: each rule is examined in order until one matches. The two chains are called PREROUTING (for Destination NAT, as packets first come in), and POSTROUTING (for Source NAT, as packets leave).

The NAT Table

linux-nat-table

At each of the points above, when a packet passes we look up what connection it is associated with. If it’s a new connection, we look up the corresponding chain in the NAT table to see what to do with it. The answer it gives will apply to all future packets on that connection.

The most important option here is the table selection option, `-t’. For all NAT operations, you will want to use `-t nat‘ for the NAT table. The second most important option to use is `-A’ to append a new rule at the end of the chain (e.g. `-A POSTROUTING’), or `-I’ to insert one at the beginning (e.g. `-I PREROUTING’).

The following command enables NAT for all outgoing packets. Eth0 is our WAN interface:

# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

If you rather implement static NAT, mapping an internal host to a public IP, here’s what the command would look like:

# iptables -A POSTROUTING -t nat -s 192.168.0.3 -o eth0 -d 0/0 -j SNAT –to 203.18.45.12

With the above command, all outgoing packets sent from internal IP 192.168.0.3 are mapped to external IP 203.18.45.12.

Taking it the other way around, the command below is used to enable port forwarding from the WAN interface, to an internal host. Any incoming packets on our external interface (eth0) with a destination port (dport) of 80, are forwarded to an internal host (192.168.0.5), port 80:

# iptables -t nat -A PREROUTING -p tcp -i eth0 –dport 80 -j DNAT –to 192.168.0.5:80

HOW THE FORWARD CHAIN ALLOWS PACKET FORWARDING

Packet forwarding within a LAN is controlled by the FORWARD chain in the iptables firewall. If the firewall is assigned an internal IP address eth2 and an external IP address on eth0,  the rules to be used to allow the forwarding to be done for the entire LAN would be:

# iptables -A FORWARD -i eth2 -j ACCEPT
# iptables -A FORWARD -o eth0 -j ACCEPT

This way, Firewall gets access to the nodes of the LAN that have internal IP address. The packets enter through the eth2 device of the gateway. They are then routed from one LAN node to their intended destination nodes.

DYNAMIC FIREWALL

By default, the IPv4 policy in Fedora kernels disables support for IP forwarding. This prevents machines that run Fedora from functioning as a dedicated firewall. Furthermore, starting with Fedora 16, the default firewall solution is now provided by “firewalld”. Although it is claimed to be the default, Fedora 16 still ships with the traditional firewall iptables. To enable the dynamic firewall in Fedora, you will need to disable the traditional firewall and install the new dynamic firewalld. The main difference between the two is firewalld is smarter in the sense it does not have to be stopped and restarted each time a policy decision is changed, unlike the traditional firewall.

To disable the traditional firewall, there are two methods, graphical and command line. For the graphical method, the GUI for the System-Config- Firewall can be opened from the Applications menu > Other > Firewall. The firewall can now be disabled.

For the command line, following commands will be needed:

# systemctl stop iptables.service
# systemctl stop ip6tables.service

To remove iptables entirely from system:

# systemctl disable iptables.service
rm ‘/etc/systemd/system/basic.target.wants/iptables.service’

# systemctl disable ip6tables.service

rm ‘/etc/systemd/system/basic.target.wants/ip6tables.service’

For installing Firewalld, you can use Yum:

# yum install firewalld firewall-applet

To enable and then start Firewalld you will need the following commands:

# systemctl enable firewalld.service
# systemctl start firewalld.service

The firewall-applet can be started from Applications menu > Other > Firewall Applet

When you hover the mouse over the firewall applet on the top panel, you can see the ports, services, etc. that are enabled. By clicking on the applet, the different services can be started or stopped. However, if you change the status and the applet crashes in order to regain control, you will have to kill the applet by using the following commands:

# ps -A | grep firewall*

Which will tell you the PID of the running applet, and you can kill it with the following command:

# kill -9 <pid>

A restart of the applet can be done from the Applications menu, and now the service you had enabled will be visible.

To get around this, the command line option can be used:

Use firewall-cmd to enable, for example ssh: # firewall-cmd –enable –service=ssh
Enable samba for 10 seconds: Enable samba for 10 seconds: # firewall-cmd –enable –service=samba –timeout=10
Enable ipp-client: # firewall-cmd –enable –service=ipp-client
Disable ipp-client: # firewall-cmd –disable –service=ipp-client
To restore the static firewall with lokkit again simply use (after stopping and disabling Firewalld): # lokkit –enabled

Setup Squid HTTP Proxy and Configure it on a Ubuntu Server


1.Installing the proxy
http://en.kioskea.net/faq/804-installing-an-http-proxy-server-squid

To install Squid type the following command in a terminal:

sudo aptitude install squid

2.Configuring the proxy

Configuration of Squid is done by editing the following file: /etc/squid/squid.conf
To edit this file enter the following command:
vi /etc/squid3/squid.conf

2.1.Naming the proxy

Its important that Squid knows the name of the machine. To do this, locate the line visible_hostname.
For example, if the machine is called ubuntu insert:
visible_hostname ubuntu

2.2 Choosing the Port

By default, the proxy server will use port 3128. To choose another port, locate the line:
http_port 3128

and change the port number, for example:
http_port 3177

2.3.Choosing the interface

By default the proxy server will listen on all interfaces. For security reasons, its better to put it on your local network only. For example, if the network card connected to your LAN has IP 10.0.0.1, change the line:
http_port 10.0.0.1:3177

2.4. Allow the use non-standard ports

By default, Squid allows HTTP traffic only on specific ports (e.g. 80). This can cause problems on websites using other ports.

-For example, http://toto.com:81/images/titi.png will be blocked by Squid

To avoid this deadlock, find the line http_access deny! Safe_ports and the edit it to: # http_access deny! Safe_ports

2.5 Authentification

How to Setup Transparent Squid Proxy Server in Ubuntu

If you wish to use authentication with your proxy you will need to install apache2 utilities

sudo aptitude install squid squid-common apache2-utils

To add your first user you will need to specify -c

sudo htpasswd -c /etc/squid.passwd first_user

Thereafter you add new users with

sudo htpasswd /etc/squid.passwd another_user

Edit the squid config file

sudo vi /etc/squid/squid.conf

Set the the authentication parameters and the acl

auth_param basic program /usr/lib/squid3/ncsa_auth /etc/squid.passwd
auth_param basic children 5
auth_param basic realm NFYE Squid proxy-caching web server
auth_param basic credentialsttl 3 hours
auth_param basic casesensitive off

acl users proxy_auth REQUIRED

acl sectionx proxy_auth REQUIRED

http_access allow users

3.Starting the Proxy

Restart the proxy to apply the modifications you made. Type:
sudo /etc/init.d/squid restart

Miscellaneous
Server logs

The proxy logs are located in: /var/log/squid/access.log

Changing the size of the cache

-The Squid cache is enabled by default, which helps accelerate the loading of some pages.
-The default allocated size is 100 MB (found in /var/spool/squid)
-To change its size, edit the /etc/squid/squid.conf file.
-Find the line: # cache_dir ufs /var/spool/squid 100 16 256
-Edit it. You can change the value 100 to whatever you want (e.g. 200 for 200 MB):
cache_dir ufs /var/spool/squid 200 16 256

Howto fix SSH connection to the netscreen firewall does not work


Problem

SSH is enabled in the firewall and configured correctly, however SSH connection to the firewall does not work.

* SSH to the firewall stopped working

* get ssh shows “ SSH is enabled”, but “SSH is NOT ready for connections”

Firewall-> get ssh
SSH V2 is active
SSH is enabled
SSH is NOT ready for connections
Maximum sessions: 3
Active sessions: 0

Solution

# Confirm that the SSH host-key is generated correctly:

get ssh host-key

If no host-key is present, delete the ssh device and re-enable SSH to regenerate the host-key:

delete ssh device all

set ssh version

set ssh enable

# If the issue continues, verify the system clock is functioning correctly. To generate a SSH host-key for the device, the system clock needs to function correctly. This can be verified with the following command:

get clock (multiple times at interval of few seconds)

If the system clock is not working correctly, it may be a hardware clock issue in the device and may require a RMA.

PDF: OpenBSD Multipath NAT Routing


Dieses Howto beschreibt kurz: OpenBSD Multipath NAT Routing:
http://plitc.eu/docs/net/PLITC_howto_OBSD_multipath_nat_routing_v104.pdf

P2Partisan – Mass IP blocking – Peerblock/Peerguardian for Tomato firmware

Little Snitch: Alerts you about outgoing network connections on Mac OS X


Little Snitch gives you control over your private outgoing data.

Track background activity
As soon as your computer connects to the Internet, applications often have permission to send any information wherever they need to. Little Snitch takes note of this activity and allows you to decide for yourself what happens with this data.

Control your network
Choose to allow or deny connections, or define a rule how to handle similar, future connection attempts. Little Snitch runs inconspicuously in the background and it can even detect network-related activity of viruses, trojans, and other malware.

For more information or to download Little Snitch go to:
http://www.obdev.at/products/littlesnitch/index.html