pfSense is yet another opensource firewall which can turn your old PC into a fully functional Firewall. pfSense opensource firewall is based on the m0n0wall opensource embedded firewall with all the good features of m0n0wall and advanced addition features.

pfSense uses OpenBSD's ported packet filter, FreeBSD 6.1 ALTQ (HSFC) for excellent packet queueing and integrated package managegement system for extending with new features.

pfSense can be downloaded a Live CD which is also an installation CD or as an installation ISO for developer edition or an Embedded edition. For more info on the download packages, click here.

The software itself can be downloaded from here

A good set of install instructions are available here

More information on Hardware, minimum requirements and recommended vendor products, visit pfSense here

In additional to the existing features on m0n0wall firewall, pfSense has the special additional features. The following are some of the key additional features:

• Wireless a/b/g using wpa_supplicant with turbo, WEP, WPA-E/PSK and WPA2 (TKIP) support. Advanced support for wireless devices including HostAP-mode, hardware-encryption if supported by driver, mac-filtering, non-broadcasting SSID with FreeBSD6 supported wireless devices (atheros recommended for full functionality)
• Incoming/outgoing load balancing pools
• Multiple WAN Support
• PPPoE Server
• Setup wizard and package using xml -> web gui toolkit
• Realtime settings change to avoid reboots
• pf for openbsd's packet filter
• CARP – for failover and clustersyncing (rules, trafficshaper, nat, IPSEC SAs…)
• failovercapable DHCP-Server with advanced settings (specify gateway, DNS, WINS)
• Systemstatus with realtimegraphs including SWAP usage monitor
• ALTQ traffic shaping with integrated magic shaper wizard with Queuegraphs for Trafficshaper
• FTP-Proxy using Squid Transparent proxy
• proxy/masquerading for SIP-protocol using siproxd
• Anti-Spam-Proxy using assp
• Fake SMTP-Server as Spam-Tarpit using spamd
• Networkscanner for security auditing using nmap
• Enhanced traceroute using mtr
• enhanced configuration-system featuring a configuration history and partial config down-/uploads
• converting PF-status-massages to Cisco NetFlow-Datagrams using pfflowd
• PFStat Graphing
• Enhanced network history data using NTOP
• STunnel to wrap standard ports with SSL
• arpwatch to watch ethernet/ip-adress-pairings
• freeradius to Radiusserver
• iperf/netio for bandwidth-measuring

A Reader's Toolbox

After SY0-101, a small number of individuals are content with their N10-003 where as the rest go on to study 70-620. This group later covers 350-030 as well.

m0n0wall is a free opensource embedded firewall that runs on embedded PCs (recommended) and other generic standard PC workstations that can run FreeBSD or rather supported by FreeBSD. m0n0wall firewall provides most of the features provided by a commercial firewall.

Click here for a list of supported FreeBSD/i386 hardware.

For more information on the hardware details m0n0wall click here

M0n0wall is based on a bare-bones version of FreeBSD with mini-httpd webserver for web GUI and PHP (with CGI support) for boot time configuration. The complete configuration is stored in XML format. This is likely the only softwar where PHP does the boot time configuration instead of Shell scripts.

The image file for installation is of 6MB in size including the core freebsd and the required components and utilities that offers most if not all the features of a commercial firewall appliance. There are seperate image files for each of the different hardware platforms supported. For more information on downloads, click here

The whole software package can be run on a compact flash card (atleast 8M in size) or on a IDE hard disk. The recommended memory is atleast 64MB. The installation procedures are well documented.

For details on installation procedures click here

The Main features of m0n0wall firewall are,

• Stateful Packet Filtering
• Web Interface (SSL) and Serial Console for administration (mini-httpd)
• Wireless Support
• Captive Portal
• 802.1Q VLAN  support
• Stateful Packet Filtering using ipfilter
• NAT/PAT, Static Router, Host Aliases support
• DHCP client, PPPoE, PPTP and Telstra BigPond Cable support on the WAN interface
• IPsec IKE VPN using Racoon with support for hardware crypto cards, mobile clients and certificates
• PPTP VPN (with RADIUS server support)
• DHCP server and DHCP-Relay (ISC DHCP)
• Caching DNS forwarder using dnsmasq
• DynDNS client and RFC 2136 DNS updater using ez-ipupdate
• Traffic shaping
• SVG-based traffic grapher
• firmware upgrade through the web browser
• Wake on LAN
• Configuration backup/restore

For more detailed feature list, click here

For more information on this FreeBSD based open source firewall, please click here

A Reader's Toobox

After 70-290, a small number of professionals who wants to study 70-296 move on to the next level i.e. 70-270, where as the rest go with the 642-901.

Quagga is a routing software suite, providing implementations of OSPFv2, OSPFv3, RIP v1 and v2, RIPng and BGP-4 and supports IPv4 and IPv6 on Unix platforms, particularly FreeBSD, Linux, Solaris and NetBSD. Quagga also supports special BGP Route Reflector and Route Server behavior.

Quagga is a fork of GNU Zebra which was developed by Kunihiro Ishiguro. The Quagga tree aims to build a more involved community around Quagga than the current centralised model of GNU Zebra.

A system with Quagga installed acts as a dedicated router. With Quagga, your machine exchanges routing information with other routers using routing protocols. Quagga uses this information to update the kernel routing table. You can dynamically change the configuration and you may view routing table information from the Quagga terminal interface.

Adding to routing protocol support, Quagga can setup interface's flags, interface's address, static routes and so on. If you have a small network, or a stub network, or xDSL connection, configuring the Quagga routing software is very easy. The only thing you have to do is to set up the interfaces and put a few commands about static routes and/or default routes. If the network is rather large, or if the network structure changes frequently, you will want to take advantage of Quagga's dynamic routing protocol support for protocols such as RIP, OSPF or BGP.

Currently, Quagga supports common unicast routing protocols. Multicast routing protocols such as BGMP, PIM-SM, PIM-DM may be supported in Quagga 2.0. MPLS support is going on. In the future, TCP/IP filtering control, QoS control, diffserv configuration will be added to Quagga. Quagga project's final goal is making a productive, quality, free TCP/IP routing software.

Quagga daemons are each configurable via a network accessible CLI (called a 'vty'). There is an additional tool included with Quagga called 'vtysh', which acts as a single cohesive front-end to all the daemons, allowing one to administer nearly all aspects of the various Quagga daemons in one place. Similar to commercial systems, there are two user modes in Quagga. One is normal mode, the other is enable mode. Normal mode user can only view system status, enable mode user can change system configuration.

The Quagga architecture consists of a core daemon:

zebra – acts as an abstraction layer to the underlying Unix kernel and presents the Zserv API over a Unix or TCP stream to Quagga clients. It is these Zserv clients which typically implement a routing protocol and communicate routing updates to the zebra daemon. Existing Zserv clients are:

ospfd – implementing OSPFv2

ripd  – implementing RIP v1 and V2

ospf6d – implementing OSPFv3 (IPv6)

ripngd  – implementing RIPng (IPv6)

bgpd  – implementing BGPv4+ (including address family support for multicast and IPv6)

Additionally, the Quagga architecture has a rich development library to facilitate the implementation of protocol/client daemons, coherent in configuration and administrative behaviour.

For more information and download, please click here

Quagga run a test route-server which can be accessed via telnet. More information here.

Perlbal is a Perl-based reverse proxy load balancer and a web server which can server millions of requests a day. Perlbal is a single-threaded event-based server supporting HTTP load balancing and web serving.

Perlbal provides a great performance "out-of-the-box" experience. One of the defining things about Perlbal is that almost everything can be configured or reconfigured on the fly without needing to restart the software. A basic configuration file containing a management port enables you to easily perform operations on a running instance of Perlbal. 

Perlbal enhances performance by

• Being a light weight application
• Event-based using epoll or kqueue to avoid the scalability problems of not-so-modern systems 
• HTTP Header processing (optionally) done in C with Perlbal::XS::HTTPHeaders for maximum performance
• 100% asynchronous in all the recommended use cases

Perlbal as a Web Server

• Listen on a port, share from a directory
• performa Directory indexing
• support Byte range support so clients can resume downloads
• Can have directory index requests fall back to index file list i.e., requests for /foo/ go to /foo/index.html
• Multiple index files supported, tries one at a time until it finds one
• Persistent client connections
• Almost all disk opertions are done asynchronously as to not stall the event loop
• Configurable support for storing files (PUT, DELETE support) When you enable PUT support, the close() operation is blocking. However, it's generally pretty fast. Also, directory indexing is a synchronous operation

Perlbal as a Reverse Proxy

• Maintains pool of connected backend connections to reduce turnover
• Gets list of nodes either from asynchronously monitored node file, or from in-server pool objects which you can add/remove nodes from using the management interface.
• Intelligent load balancing based on what backend connections are free for a new request. No unreliable "weighting" numbers required.
• Can verify (using a quick OPTIONS request) that a backend connection is talking to a webserver and not just the kernel's listen queue before sending client requests at it. Lower latency for the client.
• Has a high priority queue for sending requests through to backends quickly
• Uses cookies to determine if a request should go to fast queue
• Highpri (high priority) plugin supports making requests high priority by URI or Host
• Can specify a relief level to let low priority requests through to prevent starvation
• Can allow X-Forwarded-For (and similar) headers from client based on client IP
• Configurable header management before sending request to backend
• Internal redirection to file or URL(s):

        A backend server can instruct Perlbal to fetch the user's data from a completely separate server and port and URL, 100% transparent to the user

        Can actually give Perlbal a list of URLs to try. Perlbal will find one that's alive. Again, the end user sees no redirects happening.

        Can also redirect to a file, which Perlbal will serve non-blocking

• Persistent client connections 
• Persistent backend connections (shared by multiple clients; no "backend waste")

MANAGEMENT

The management interface provides extremely detailed and powerful statistics in addition to runtime configuration like

• CPU usage (user, system)
• Total requests served across all services
• Requests service by individual backends
• Perlbal uptime
• All connected sockets (and tons of info about each)
• Outstanding connections to backends
• Backends that have recently failed verification
• Pending backend connections by service
• Total of all socket states by socket type Size (in seconds and number of connections) of all queues
• State of reproxy engine (queued requests, outstanding requests, backends)
• Loaded plugins per service (All statistics are in machine readable form, easy to parse and write scripts that check on the status of Perlbal!)

Plugins (Extensibility)

Perlbal supports the concept of having per-service (and global) plugins that can override many parts of request handling and behavior. We have written custom plugins that send new headers to the backends, promote requests to the fast queue, maintain more detailed statistics, do image header manipulation, and more…

Downloads at:

http://search.cpan.org/dist/Perlbal/

You'll also need the following Perl modules:

Danga::Socket

Sys::Syscall

Pound is a reverse proxy, load balancer and HTTPS front-end for Web server(s). Pound was developed to enable distributing the load among several Web-servers and to allow for a convenient SSL wrapper for those Web servers that do not offer it natively. Pound is distributed under the GPL license.

Pound is a very small program, easily audited for security problems. It can run as setuid/setgid and/or in a chroot jail. Pound does not access the hard-disk at all (except for reading the certificate file on start, if required) and should thus pose no security threat to any machine.

Pound is set to have performed well in large volums of upto 30M connections per day with over 600 requests/second at peak.

Pound functions as a ,

Reverse-Proxy: Passes requests from client browsers to one or more back-end servers. 
Load Balancer: Distribute the requests from the client browsers among several back-end servers, while keeping session information.
SSL wrapper: Decrypt HTTPS requests from client browsers and pass them as plain HTTP to the back-end servers.
HTTP/HTTPS sanitizer: Verify requests for correctness and accept only well-formed ones.
a fail over-server: should a back-end server fail, Pound will take note of the fact and stop passing requests to it until it recovers.
Request Redirector: requests may be distributed among servers according to the requested URL.

Pound can also support Virtualhosts. Pound however is not a Webserver or a Web-accelerator or a proxy server.

Pound work with a variety of Web servers, including Apache, IIS, Zope, WebLogic, Jakarta/Tomcat, iPlanet, etc. In general Pound passes requests and responses back and forth unchanged, so we have no reason to think that any web server would be incompatible.

Client browsers that were tested:

IE 5.0/5.5 (Windows) HTTP/HTTPS
Netscape 4.7 (Windows/Linux) HTTP/HTTPS
Mozilla (Windows/Linux) HTTP/HTTPS
Konqueror (Linux) HTTP/HTTPS
Galleon (Linux) HTTP/HTTPS
Opera (Linux/Windows) HTTP/HTTPS
Lynx (Linux) HTTP

For more information, download, installation procedures and samples of different configurations can be found here

Use the hostname command in Windows and in most Unix and Linux versions to get the actual hostname of the system. In Windows, from the command prompt simply type,

c:\>hostname MYCOMPUTER

In Linux or unix, from the terminal window type hostname,

mycomputer$ hostname

This should show the computer name.