FireRack

14/03/05 1

FireRack

Technology Overview

© 2003 Netservers

14/03/05 2

Topics of Discussion

• Key features

• Firewall architecture

• Management architecture

• Add-on modules

14/03/05 3

Key features

• Compartmentalized security

• Centralized and remote administration

• Reliability

• Monitoring and auditing

• VPN support

• Advanced routing

14/03/05 4

Firewall architecture

• Stateful-packet inspection with connection tracking allows intuitive definition of firewall policies.

• ‘Security Zones’ provide compartmentalized security:• Every ‘connection’ checked twice; by ingress and

egress zones.• Restrictions in one zone’s policy cannot be

circumvented by a more permissive policy in another zone.

• Control of individual zones can safely be delegated.

14/03/05 5

Firewall architecture (2)

• Built on Linux 2.4 kernel with iptables and various open source utilities.

• FireRack adds many features, e.g.:• ‘Appliance’ – software runs read-only from flash

device (safe to reset most of the time, no hard disk to fail, etc).

• Complex, innovative iptables structure implements security zones and greatly simplifies policy definition for the user.

• High level of integration.• Resilient remote management architecture.

14/03/05 6

Firewall terminology:‘Ingress’ and ‘Egress’

• Ingress: entry of packets to firewall from the network• ‘Ingress Zone’: security zone in which a given

packet originated

• Egress: exit of packets from the firewall to the network• ‘Egress Zone’: security zone into which the

firewall will route the packets (if they are permitted)

14/03/05 7

Security Zones

• A group of IP addresses governed by single policy

• Normally corresponds to a single IP subnet• Advanced routing configurations can allow combining

multiple subnet ranges or individual IP addresses into one effective zone

• Can have multiple zones attached to same firewall interface

• A zone must be on a single interface

14/03/05 8

Security Zones (2)

• Automatic route-based ingress filtering• Packets are blocked if their source IP address does not

belong within a zone bound to the interface the packet was received via.

• Does not prevent IP spoofing within a zone (host registration, covered later, does do that)

• Does not prevent IP spoofing between zones on same interface: it’s therefore better to have zones on different interfaces, e.g. 802.1Q tagged virtual interfaces.

14/03/05 9

Interfaces

• Each zone bound to specific firewall ‘interface’.

• Physical interfaces:• Ethernet, WiFi.

• ISDN (virtualized)

• ADSL or Analog modem (virtualized)

• ‘Virtualized’ interfaces are interface configurations which are dynamically mapped onto physical devices.

14/03/05 10

Interfaces (2)

• Virtual interfaces:• 802.1Q tagged VLANs

• Ethernet bridges

• IPsec encapsulation device

• Load balancer / route distributor

• VPN clients (PPTP, VTUN)

• VPN servers (PPTP, VTUN, L2TP) – one virtual interface per user!

• PPPoE

14/03/05 11

Firewall phases

• Firewall policies are applied to connections in multiple phases:• Redirection (DNAT)

• Filtering

• Classification

• Masquerading (SNAT)

• Phases execute in order.

14/03/05 12

Firewall Phases

• Each phase checks 3 policies before moving on to next phase:1.Global policy

2.Ingress zone’s policy

3.Egress zone’s policy

14/03/05 13

Firewall terminology:‘Connection Tracking’

• Firewall maintains internal state of current IP ‘connections’ it has seen before, and how it decided to handle them.

• Each individual packet received by the firewall is analyzed to see if it belongs to a connection the firewall has seen before.

• Hence ‘stateful-packet inspection’.

14/03/05 14

Firewall terminology:‘Established Connection’

• When firewall sees a new IP ‘connection’, it checks the firewall policy to see if the connection should be permitted.

• If the firewall decides to permit a new connection, it will reflect this in the Connection Tracking internal state as ‘established’.

• Connection Tracking automatically takes care of ‘established’ connections

14/03/05 15

Filtering Phase

• Consists of two parts:• Connection Filtering (CF)

• Packet Filtering (PF)

• CF & PF treated as single policy for a zone, I.e. execution order for entire filtering phase is:1. Global CF & PF

2. Ingress CF & PF

3. Egress CF & PF

14/03/05 16

Connection Filtering

• This is the main part of the policy: all normal ‘firewalling’ work is done here.

• Rules describe policy of what connections should be permitted or denied through the zone

• Connections must be allowed by both the ingress and the egress zone to become established.

• Connection tracking automatically takes care of letting packets flow both ways if they are part of an established connection.

14/03/05 17

Packet Filtering

• Special case (rarely used)• Default is to permit packets• Every packet, including those which are part of an

established connection, must be permitted here

• Applied to all packets permitted by CF.• Can be useful for manipulating or breaking

previously established connections• E.g. break a TCP connection after detecting a

signature for a banned protocol or exploit mid-stream.

14/03/05 18

Classification Phase

• Advanced feature, available on some FireRack models.

• Allows classification of packets and connections:• Packet and connection mark values can be

assigned to traffic and matched in other rules

• QoS and routing of packets can be manipulated.

• Peer2Peer classification is usually done here

14/03/05 19

Redirection Phase

• Performs Destination Network Address Translation (DNAT)

• First phase in each zone’s policy• May alter destination IP address and port of a new

connection during establishment.• Rules describe policy of which connections should

be DNAT’d and what their new destinations should be.

• Connection Tracking takes care of NAT’ing all packets in an established DNAT’d connection.

14/03/05 20

Redirection Phase (2)

• Can only DNAT each connection once• Only first matching rule takes effect• if DNAT occurs in ingress, will skip egress policy.

• Changing the destination IP may change the destination zone.• Subsequent phases will use the policy of the zone

containing the new destination address.

• If DNAT occurs, subsequent phases see the translated address.• Connection Filtering rules cannot match the connection

on the basis of where it was originally addressed to.

14/03/05 21

Masquerading Phase

• Performs Source Network Address Translation (SNAT)

• Last phase in each zone’s policy• May alter source IP address and/or port of a

new connection during establishment.• Rules describe policy of which connections

should be SNAT’d and what their translated source address should be.

14/03/05 22

Masquerading Phase (2)

• Can only SNAT each connection once• Only first matching rule takes effect

• If SNAT occurs in ingress zone, will skip egress zone Masquerading Phase.

• ‘Auto-masquerade’ will automatically pick an IP address belonging to the firewall from the egress zone.

14/03/05 23

Services Phase

• Rules describe policy of what connections are allowed to be made to built-in services on the firewall

• Connections addressed to firewall only pass through: • Redirection Phase• Services Phase

• Only ingress zone’s policy is checked: there is no egress zone.

14/03/05 24

Redirecting services

• Can use Redirection Phase to:• DNAT arbitrary destinations into firewall’s

own services by specify firewall as new destination.

• Forward arbitrary local ports on firewall to remote addresses

14/03/05 25

Built-in services

• VPN services• IPsec, PPTP, L2TP, VTUN

• Application level proxies• SOCKS 5, HTTP

• DNS• Primary & secondary hosting• Caching resolver

• Remote traffic flow monitoring• Argus (multiple ports)

• Management & diagnostic (covered later)

14/03/05 26

Host Registration

• IP and MAC addresses of individual hosts may be registered with firewall.• Spoofing protection helps prevent service and identity

theft.

• Static DHCP simplifies workstation configuration yet still provides each of them with a fixed IP identity.

• Automatic DNS insertion optionally provides complimentary zero-effort DNS mappings for the registered workstations.

14/03/05 27

Host Registration: spoofing protection

• Ingress protection blocks registered MAC addresses and IP addresses except when used in their approved pairings for the ingress zone.

• Static address resolution provides egress protection for registered IP addresses.

• An attacker would need to spoof both IP and MAC address• Harder than just spoofing IP• Can’t be done ‘by accident’• Secure switches can prevent MAC spoofing

14/03/05 28

Host Registration: spoofing protection (2)

• Registered IP + wrong MAC :• blocked completely

• Wrong IP + registered MAC :• blocked completely

• Unknown IP + unknown MAC :• Host is unregistered• Blocked or permitted depending on ingress zone’s host

registration policy• MAC considered unknown if not registered in same

security zone• can use same MAC, registered or otherwise, in other zones

14/03/05 29

Host Registration Policy

• Zone option: defines how the ingress zone should handle unregistered hosts• ‘Do not require’ (default). This is not secure: set this if

you are not using host registration or are still transitioning to it.

• ‘Drop’ or ‘Log & Drop’ or ‘Reject’• ‘Treat unregistered hosts as being in zone <X>’

• X must have a ‘Do not require’ policy• Redirection, Connection Filtering and Services policies of X

are used INSTEAD of ingress zone’s own policies• Packet Filtering and Masquerading policies of X are NOT

used: the ingress zone’s policies still apply here.

14/03/05 30

Host Registration: DHCP

• DHCP administration• Registered MAC addresses automatically added

as static entries to DHCP server for zone

• A separate zone sharing the same interface can be used to serve dynamic leases from a different subnet to unregistered MAC addresses

• Can have much tighter restrictions

• Used for online self-registration services

14/03/05 31

Host Registration: DNS

• Registered IP addresses with hostnames are automatically inserted in forward and reverse DNS.• Target DNS zones are configured per security zone.

• FireRack must be master DNS server for the DNS zone.

• Just an administrative convenience• Equivalent to adding an A record to the forward DNS

zone and a PTR record in the reverse zone for each host under DNS zone definitions.

14/03/05 32

Host Registration: end-user self-registration

• Option to allow end users to register their own MAC addresses.

• Extra ‘unregistered’ zone is created on same firewall interface as zone for registered hosts, and is given a private IP subnet range

• Unregistered zone is configured with dynamic DHCP lease range, other zones only offer static DHCP allocation to registered MAC addresses.

• Hosts with unregistered MAC addresses get given temporary IP lease in unregistered zone.

14/03/05 33

Host Registration: end-user self-registration (2)

• Rules for unregistered zone block all access except to firewall’s DNS server and registration web site (HTTPS).• Host Registration Policy for other zones can be ‘treat

unregistered hosts as being in unregistered zone’

• All HTTP and HTTP proxy connections are DNAT’d into FMS ‘httpblockd’ service • All requests are answered with a temporary HTTP

redirect to the registration web site.• When user attempts to access any web site they end up

on the registration web site.

14/03/05 34

Host registration: end-user self-registration (3)

• Registration web site detects MAC address via live lookup of client IP address in firewall ARP table.

• User authenticates themselves • User can assign detected MAC address to existing

IP address registration• FMS DB immediately updated• Optional auto-push of configuration

• User can apply for new IP address

14/03/05 35

Management Architecture

• Central management of multiple FireRack appliances from a single FireRack Management Server (FMS).

• Firewall configurations are created and stored in database on FMS.

• SSL encrypted web-based management console allows easy manipulation of firewall configurations.

• FMS builds encrypted and digitally signed ‘pack’ files, each containing configuration snap-shot.

14/03/05 36

Management Server (FMS)

• Debian GNU/Linux server with FMS software packages:• Usually dedicated server

• Can add to existing Debian server

• Also runs in chroot environment on most Linux distributions

• Dedicated servers have VGA port and X-Windows with Mozilla for emergency access to web based management console.

14/03/05 37

Management Server (2)

• Standard FMS software packages:• Configuration database and DB setup tools.

• Web based Management Console / XML-RPC API

• Management engine (‘Genesis’) for building and pushing pack files, and other interactions with firewalls.

14/03/05 38

Management Server (3)

• Traffic accounting database and tools• Proprietry database format

• Data accessible via console, API or command-line tool

• Argus audit logging• Traffic flows logged to daily or hourly binary log files

• Logs can be read with open-source argus tools

• Very disk intensive – every connection can be logged!

14/03/05 39

Traffic accounting

• Realm and Entity based accounting• An Accounting Entity is a registered host or local zone

which is deemed responsible for traffic• Local traffic may be between two entities and is

accounted to the entity that initiated the connection

• Internet traffic typically only involves one entity; that entity is always considered responsible

• An Accounting Realm is a network or set of networks for which separate accounting figures are required

• Realms are defined via the IP routing configuration

14/03/05 40

Traffic accounting (2)

• Separate counters are kept for traffic received from and sent to each Realm by each Entity• Bytes received & sent

• Packets in and out

• New connections in and out

• Management console and self-registration provide summaries and graphing

14/03/05 41

Traffic accounting (3)

• FMS collects accounting data samples via firewall SOAP API every 5 minutes• Timing not critical; samples will be interpolated into

exact 5 minute time slots

• When FMS offline or out of contact with firewall, the firewall will take hourly samples itself

• Samples use cummulative counters, so missing samples do not cause inaccurate accounting totals; only resolution is lost

14/03/05 42

Traffic quota management

• Optional FMS feature

• Supports multiple concurrent rolling quotas

• Each quota specifies a time-period and maximum traffic volume

• Default per-user or per-IP-address quotas can be set for each zone and overriden for specific users

• When a quota is exceeded it can e-mail the user and/or add their IP to a dynamic group (which can be used for throttling and/or filtering)

14/03/05 43

Switch Management

• Optional FMS module

• Uses SNMP to monitor and manage Ethernet switches

• MAC address tracking• All switches are continuously polled and the locations of

all MAC addresses are logged

• Historic data can be viewed for port or MAC address

• Works in combination with Host Address Registration to allow hosts to be identified

14/03/05 44

Switch Management (2)

• VLAN configuration• VLANs are first assigned to ports in database, then the

configuration is 'pushed' to the switches

• Administrator defines interconnection of switches and FireRacks and system thus provides automatic configuration of 802.1Q tagged trunks

• Locations and Location Groups can be used to perform bulk updates of VLAN assignments on groups of ports

14/03/05 45

Management Console

• Runs on FMS (via Apache 2)• SSL encrypted• Requires Javascript:

• Uses RPC for real-time manipulation of FMS database• Supported browsers: IE 5.5, Mozilla 1.0, NS6 and later

versions.

• Integrated XML-RPC compliant management API allows customers to easily automate tasks and interface their own systems to FireRack.

14/03/05 46

XML-RPC API

• XML-RPC standard has clients for many platforms and software languages.

• Self-documenting API exposes an object abstraction of FMS database

• Simple methods ‘add’, ‘listobjid’, ‘load’, ‘setval’ allow safe manipulation of objects.

• Various other specialized methods:• Push configuration• Pass-through to SOAP API in firewall.

14/03/05 47

Configuration pack files

• Built by ‘genesis’ on FMS• Digitally signed & encrypted• Pushed to firewall via SOAP• Firewall archives previous pack files

• Can roll-back firewall configuration to an earlier pack file in an emergency

• Very useful if new configuration breaks connectivity between firewall and FMS!

• ‘factory’ pack contains initial configuration (from time of install or latest upgrade)

• Pack selection available from firewall HTTPS, SSH, serial console and LCD control panel.

14/03/05 48

Firewall ‘Fail-over’ Pairings

• Firewalls may be paired together to share a common configuration in DB, to allow for a ‘hot-spare’.

• DB defines a physical ‘identity’ for each firewall and also a virtual ‘master’ identity.

• Each security zone is bound to a specific identity.• Most zones will be bound to the ‘master’ identity.• Individual zones with unique IP addresses must be

bound to each physical identity to allow each firewall to be managed.

14/03/05 49

Firewall Pairings (2)

• Same configuration is pushed to each firewall• One at a time, only on request

• Each firewall knows its own identity• It also maintains internal state to remember if it is

‘MASTER’ (it also holds the master identity) or ‘SLAVE’ (does not hold master identify)

• When a pack file is activated, firewall only activates the zones bound to the identities it holds.

14/03/05 50

Firewall Pairings (3)

• Switching between MASTER and SLAVE modes:• Toggles ownership setting for ‘master’ identity and re-

activates current configuration pack

• Changes to IP address bindings during pack activation triggers Gratuitous ARP messages (GARP) from firewall for each IP address bound to it.

• GARPs should cause local workstations and routers to update their ARP tables and send all further traffic to newly activated MASTER.

• GARPs are also sent periodically by all firewalls to improve reliablity and provide ARP spoofing antidote.

14/03/05 51

Firewall Pairings (4)

• Switching between MASTER and SLAVE modes:• Use LCD control panel, or• Use ‘failover master’ or ‘failover slave’

commands from SSH session or serial console.• Each firewall has no idea what mode the other

is in• When switching one firewall to MASTER, ensure

other is set to SLAVE or take it completely offline.

14/03/05 52

Built in HTTPS server

• Each firewall has its own HTTPS server.• Used for basic diagnostics

• Run ping, traceroute, etc.• View log output, interface status, etc.

• Used for emergency reconfiguration• Activate a different pack file• Very basic IP address, routing and rule manipulation

(changes are not persistent)

• VPN and interface management:• Activate and deactivate VPN client connections and

other interfaces.

14/03/05 53

Command line interface

• Accessed over network via SSH (on non-standard port 48001) or serial console (38400 8N1)

• Has a variety of UNIX/Linux command line tools to aid in diagnostics• Network monitoring tools: ifconfig, bwm, iptraf,

tcpdump, qosstats, arp, etc.

• ping, traceroute, etc.

• logtail – shows firewall logs

14/03/05 54

Command line interface (2)

• Administrative commands:• ‘failover slave’ / ‘failover master’

• ‘ls /etc/genesis/packs’ lists available pack files

• ‘geninstall install <pack file name>’ activates a pack file

• ‘ifup’ / ‘ifdown’ activate or deactivate an interface or VPN client