Your SlideShare is downloading. ×
0
FireRack <ul><ul><li>Technology Overview </li></ul></ul><ul><ul><li>© 2003 Netservers </li></ul></ul>
Topics of Discussion <ul><li>Key features </li></ul><ul><li>Firewall architecture </li></ul><ul><li>Management architectur...
Key features <ul><li>Compartmentalized security </li></ul><ul><li>Centralized and remote administration </li></ul><ul><li>...
Firewall architecture <ul><li>Stateful-packet inspection with connection tracking allows intuitive definition of firewall ...
Firewall architecture (2) <ul><li>Built on Linux 2.4 kernel with iptables and various open source utilities. </li></ul><ul...
Firewall terminology: ‘Ingress’ and ‘Egress’ <ul><li>Ingress: entry of packets to firewall from the network </li></ul><ul>...
Security Zones <ul><li>A group of IP addresses governed by single policy </li></ul><ul><li>Normally corresponds to a singl...
Security Zones (2) <ul><li>Automatic route-based ingress filtering </li></ul><ul><ul><li>Packets are blocked if their sour...
Interfaces <ul><li>Each zone bound to specific firewall ‘interface’. </li></ul><ul><li>Physical interfaces: </li></ul><ul>...
Interfaces (2) <ul><li>Virtual interfaces: </li></ul><ul><ul><li>802.1Q tagged VLANs </li></ul></ul><ul><ul><li>Ethernet b...
Firewall phases <ul><li>Firewall policies are applied to connections in multiple phases: </li></ul><ul><ul><li>Redirection...
Firewall Phases <ul><li>Each phase checks 3 policies before moving on to next phase: </li></ul><ul><ul><li>Global policy <...
Firewall terminology: ‘Connection Tracking’ <ul><li>Firewall maintains internal state of current IP ‘connections’ it has s...
Firewall terminology: ‘Established Connection’ <ul><li>When firewall sees a new IP ‘connection’, it checks the firewall po...
Filtering Phase <ul><li>Consists of two parts: </li></ul><ul><ul><li>Connection Filtering (CF) </li></ul></ul><ul><ul><li>...
Connection Filtering <ul><li>This is the main part of the policy: all normal ‘firewalling’ work is done here. </li></ul><u...
Packet Filtering <ul><li>Special case (rarely used) </li></ul><ul><ul><li>Default is to permit packets </li></ul></ul><ul>...
Classification Phase <ul><li>Advanced feature, available on some FireRack models. </li></ul><ul><li>Allows classification ...
Redirection Phase <ul><li>Performs Destination Network Address Translation (DNAT) </li></ul><ul><li>First phase in each zo...
Redirection Phase (2) <ul><li>Can only DNAT each connection once </li></ul><ul><ul><li>Only first matching rule takes effe...
Masquerading Phase <ul><li>Performs Source Network Address Translation (SNAT) </li></ul><ul><li>Last phase in each zone’s ...
Masquerading Phase (2) <ul><li>Can only SNAT each connection once </li></ul><ul><ul><li>Only first matching rule takes eff...
Services Phase <ul><li>Rules describe policy of what connections are allowed to be made to built-in services on the firewa...
Redirecting services <ul><li>Can use Redirection Phase to: </li></ul><ul><ul><li>DNAT arbitrary destinations into firewall...
Built-in services <ul><li>VPN services </li></ul><ul><ul><li>IPsec, PPTP, L2TP, VTUN </li></ul></ul><ul><li>Application le...
Host Registration <ul><li>IP and MAC addresses of individual hosts may be registered with firewall. </li></ul><ul><ul><li>...
Host Registration: spoofing protection <ul><li>Ingress protection blocks registered MAC addresses and IP addresses except ...
Host Registration: spoofing protection (2) <ul><li>Registered IP + wrong MAC : </li></ul><ul><ul><li>blocked completely </...
Host Registration Policy <ul><li>Zone option: defines how the ingress zone should handle  unregistered  hosts </li></ul><u...
Host Registration: DHCP <ul><li>DHCP administration </li></ul><ul><ul><li>Registered MAC addresses automatically added as ...
Host Registration: DNS <ul><li>Registered IP addresses with hostnames are automatically inserted in forward and reverse DN...
Host Registration: end-user self-registration <ul><li>Option to allow end users to register their own MAC addresses. </li>...
Host Registration: end-user self-registration (2) <ul><li>Rules for unregistered zone block all access except to firewall’...
Host registration: end-user self-registration (3) <ul><li>Registration web site detects MAC address via live lookup of cli...
Management Architecture <ul><li>Central management of multiple FireRack appliances from a single FireRack Management Serve...
Management Server (FMS) <ul><li>Debian GNU/Linux server with FMS software packages: </li></ul><ul><ul><li>Usually dedicate...
Management Server (2) <ul><li>Standard FMS software packages: </li></ul><ul><ul><li>Configuration database and DB setup to...
Management Server (3) <ul><li>Traffic accounting database and tools </li></ul><ul><ul><li>Proprietry database format </li>...
Traffic accounting <ul><li>Realm and Entity based accounting </li></ul><ul><ul><li>An  Accounting Entity  is a registered ...
Traffic accounting (2) <ul><li>Separate counters are kept for traffic received from and sent to each Realm by each Entity ...
Traffic accounting (3) <ul><li>FMS collects accounting data samples via firewall SOAP API every 5 minutes </li></ul><ul><u...
Traffic quota management <ul><li>Optional FMS feature </li></ul><ul><li>Supports multiple concurrent rolling quotas </li><...
Switch Management <ul><li>Optional FMS module </li></ul><ul><li>Uses SNMP to monitor and manage Ethernet switches </li></u...
Switch Management (2) <ul><li>VLAN configuration </li></ul><ul><ul><li>VLANs are first assigned to ports in database, then...
Management Console <ul><li>Runs on FMS (via Apache 2) </li></ul><ul><li>SSL encrypted </li></ul><ul><li>Requires Javascrip...
XML-RPC API <ul><li>XML-RPC standard has clients for many platforms and software languages. </li></ul><ul><li>Self-documen...
Configuration pack files <ul><li>Built by ‘genesis’ on FMS </li></ul><ul><li>Digitally signed & encrypted </li></ul><ul><l...
Firewall ‘Fail-over’ Pairings <ul><li>Firewalls may be paired together to share a common configuration in DB, to allow for...
Firewall Pairings (2) <ul><li>Same configuration is pushed to each firewall </li></ul><ul><ul><li>One at a time, only on r...
Firewall Pairings (3) <ul><li>Switching between MASTER and SLAVE modes: </li></ul><ul><ul><li>Toggles ownership setting fo...
Firewall Pairings (4) <ul><li>Switching between MASTER and SLAVE modes: </li></ul><ul><ul><li>Use LCD control panel, or </...
Built in HTTPS server <ul><li>Each firewall has its own HTTPS server. </li></ul><ul><li>Used for basic diagnostics </li></...
Command line interface <ul><li>Accessed over network via SSH (on non-standard port 48001) or serial console (38400 8N1) </...
Command line interface (2) <ul><li>Administrative commands: </li></ul><ul><ul><li>‘ failover slave’ / ‘failover master’ </...
Upcoming SlideShare
Loading in...5
×

FireRack

466

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
466
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "FireRack"

  1. 1. FireRack <ul><ul><li>Technology Overview </li></ul></ul><ul><ul><li>© 2003 Netservers </li></ul></ul>
  2. 2. Topics of Discussion <ul><li>Key features </li></ul><ul><li>Firewall architecture </li></ul><ul><li>Management architecture </li></ul><ul><li>Add-on modules </li></ul>
  3. 3. Key features <ul><li>Compartmentalized security </li></ul><ul><li>Centralized and remote administration </li></ul><ul><li>Reliability </li></ul><ul><li>Monitoring and auditing </li></ul><ul><li>VPN support </li></ul><ul><li>Advanced routing </li></ul>
  4. 4. Firewall architecture <ul><li>Stateful-packet inspection with connection tracking allows intuitive definition of firewall policies. </li></ul><ul><li>‘ Security Zones’ provide compartmentalized security: </li></ul><ul><ul><li>Every ‘connection’ checked twice; by ingress and egress zones. </li></ul></ul><ul><ul><li>Restrictions in one zone’s policy cannot be circumvented by a more permissive policy in another zone. </li></ul></ul><ul><ul><li>Control of individual zones can safely be delegated. </li></ul></ul>
  5. 5. Firewall architecture (2) <ul><li>Built on Linux 2.4 kernel with iptables and various open source utilities. </li></ul><ul><li>FireRack adds many features, e.g.: </li></ul><ul><ul><li>‘ Appliance’ – software runs read-only from flash device (safe to reset most of the time, no hard disk to fail, etc). </li></ul></ul><ul><ul><li>Complex, innovative iptables structure implements security zones and greatly simplifies policy definition for the user. </li></ul></ul><ul><ul><li>High level of integration. </li></ul></ul><ul><ul><li>Resilient remote management architecture. </li></ul></ul>
  6. 6. Firewall terminology: ‘Ingress’ and ‘Egress’ <ul><li>Ingress: entry of packets to firewall from the network </li></ul><ul><ul><li>‘ Ingress Zone’: security zone in which a given packet originated </li></ul></ul><ul><li>Egress: exit of packets from the firewall to the network </li></ul><ul><ul><li>‘ Egress Zone’: security zone into which the firewall will route the packets (if they are permitted) </li></ul></ul>
  7. 7. Security Zones <ul><li>A group of IP addresses governed by single policy </li></ul><ul><li>Normally corresponds to a single IP subnet </li></ul><ul><ul><li>Advanced routing configurations can allow combining multiple subnet ranges or individual IP addresses into one effective zone </li></ul></ul><ul><li>Can have multiple zones attached to same firewall interface </li></ul><ul><li>A zone must be on a single interface </li></ul>
  8. 8. Security Zones (2) <ul><li>Automatic route-based ingress filtering </li></ul><ul><ul><li>Packets are blocked if their source IP address does not belong within a zone bound to the interface the packet was received via. </li></ul></ul><ul><ul><li>Does not prevent IP spoofing within a zone (host registration, covered later, does do that) </li></ul></ul><ul><ul><li>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. </li></ul></ul>
  9. 9. Interfaces <ul><li>Each zone bound to specific firewall ‘interface’. </li></ul><ul><li>Physical interfaces: </li></ul><ul><ul><li>Ethernet, WiFi. </li></ul></ul><ul><ul><li>ISDN (virtualized) </li></ul></ul><ul><ul><li>ADSL or Analog modem (virtualized) </li></ul></ul><ul><li>‘ Virtualized’ interfaces are interface configurations which are dynamically mapped onto physical devices. </li></ul>
  10. 10. Interfaces (2) <ul><li>Virtual interfaces: </li></ul><ul><ul><li>802.1Q tagged VLANs </li></ul></ul><ul><ul><li>Ethernet bridges </li></ul></ul><ul><ul><li>IPsec encapsulation device </li></ul></ul><ul><ul><li>Load balancer / route distributor </li></ul></ul><ul><ul><li>VPN clients (PPTP, VTUN) </li></ul></ul><ul><ul><li>VPN servers (PPTP, VTUN, L2TP) – one virtual interface per user! </li></ul></ul><ul><ul><li>PPPoE </li></ul></ul>
  11. 11. Firewall phases <ul><li>Firewall policies are applied to connections in multiple phases: </li></ul><ul><ul><li>Redirection (DNAT) </li></ul></ul><ul><ul><li>Filtering </li></ul></ul><ul><ul><li>Classification </li></ul></ul><ul><ul><li>Masquerading (SNAT) </li></ul></ul><ul><li>Phases execute in order. </li></ul>
  12. 12. Firewall Phases <ul><li>Each phase checks 3 policies before moving on to next phase: </li></ul><ul><ul><li>Global policy </li></ul></ul><ul><ul><li>Ingress zone’s policy </li></ul></ul><ul><ul><li>Egress zone’s policy </li></ul></ul>
  13. 13. Firewall terminology: ‘Connection Tracking’ <ul><li>Firewall maintains internal state of current IP ‘connections’ it has seen before, and how it decided to handle them. </li></ul><ul><li>Each individual packet received by the firewall is analyzed to see if it belongs to a connection the firewall has seen before. </li></ul><ul><li>Hence ‘stateful-packet inspection’. </li></ul>
  14. 14. Firewall terminology: ‘Established Connection’ <ul><li>When firewall sees a new IP ‘connection’, it checks the firewall policy to see if the connection should be permitted. </li></ul><ul><li>If the firewall decides to permit a new connection, it will reflect this in the Connection Tracking internal state as ‘established’. </li></ul><ul><li>Connection Tracking automatically takes care of ‘established’ connections </li></ul>
  15. 15. Filtering Phase <ul><li>Consists of two parts: </li></ul><ul><ul><li>Connection Filtering (CF) </li></ul></ul><ul><ul><li>Packet Filtering (PF) </li></ul></ul><ul><li>CF & PF treated as single policy for a zone, I.e. execution order for entire filtering phase is: </li></ul><ul><ul><li>Global CF & PF </li></ul></ul><ul><ul><li>Ingress CF & PF </li></ul></ul><ul><ul><li>Egress CF & PF </li></ul></ul>
  16. 16. Connection Filtering <ul><li>This is the main part of the policy: all normal ‘firewalling’ work is done here. </li></ul><ul><li>Rules describe policy of what connections should be permitted or denied through the zone </li></ul><ul><li>Connections must be allowed by both the ingress and the egress zone to become established. </li></ul><ul><li>Connection tracking automatically takes care of letting packets flow both ways if they are part of an established connection. </li></ul>
  17. 17. Packet Filtering <ul><li>Special case (rarely used) </li></ul><ul><ul><li>Default is to permit packets </li></ul></ul><ul><ul><li>Every packet, including those which are part of an established connection, must be permitted here </li></ul></ul><ul><li>Applied to all packets permitted by CF. </li></ul><ul><li>Can be useful for manipulating or breaking previously established connections </li></ul><ul><li>E.g. break a TCP connection after detecting a signature for a banned protocol or exploit mid-stream. </li></ul>
  18. 18. Classification Phase <ul><li>Advanced feature, available on some FireRack models. </li></ul><ul><li>Allows classification of packets and connections: </li></ul><ul><ul><li>Packet and connection mark values can be assigned to traffic and matched in other rules </li></ul></ul><ul><ul><li>QoS and routing of packets can be manipulated. </li></ul></ul><ul><ul><li>Peer2Peer classification is usually done here </li></ul></ul>
  19. 19. Redirection Phase <ul><li>Performs Destination Network Address Translation (DNAT) </li></ul><ul><li>First phase in each zone’s policy </li></ul><ul><li>May alter destination IP address and port of a new connection during establishment. </li></ul><ul><li>Rules describe policy of which connections should be DNAT’d and what their new destinations should be. </li></ul><ul><li>Connection Tracking takes care of NAT’ing all packets in an established DNAT’d connection. </li></ul>
  20. 20. Redirection Phase (2) <ul><li>Can only DNAT each connection once </li></ul><ul><ul><li>Only first matching rule takes effect </li></ul></ul><ul><ul><li>if DNAT occurs in ingress, will skip egress policy. </li></ul></ul><ul><li>Changing the destination IP may change the destination zone. </li></ul><ul><ul><li>Subsequent phases will use the policy of the zone containing the new destination address. </li></ul></ul><ul><li>If DNAT occurs, subsequent phases see the translated address. </li></ul><ul><ul><li>Connection Filtering rules cannot match the connection on the basis of where it was originally addressed to. </li></ul></ul>
  21. 21. Masquerading Phase <ul><li>Performs Source Network Address Translation (SNAT) </li></ul><ul><li>Last phase in each zone’s policy </li></ul><ul><li>May alter source IP address and/or port of a new connection during establishment. </li></ul><ul><li>Rules describe policy of which connections should be SNAT’d and what their translated source address should be. </li></ul>
  22. 22. Masquerading Phase (2) <ul><li>Can only SNAT each connection once </li></ul><ul><ul><li>Only first matching rule takes effect </li></ul></ul><ul><ul><li>If SNAT occurs in ingress zone, will skip egress zone Masquerading Phase. </li></ul></ul><ul><li>‘ Auto-masquerade’ will automatically pick an IP address belonging to the firewall from the egress zone. </li></ul>
  23. 23. Services Phase <ul><li>Rules describe policy of what connections are allowed to be made to built-in services on the firewall </li></ul><ul><li>Connections addressed to firewall only pass through: </li></ul><ul><ul><li>Redirection Phase </li></ul></ul><ul><ul><li>Services Phase </li></ul></ul><ul><li>Only ingress zone’s policy is checked: there is no egress zone. </li></ul>
  24. 24. Redirecting services <ul><li>Can use Redirection Phase to: </li></ul><ul><ul><li>DNAT arbitrary destinations into firewall’s own services by specify firewall as new destination. </li></ul></ul><ul><ul><li>Forward arbitrary local ports on firewall to remote addresses </li></ul></ul>
  25. 25. Built-in services <ul><li>VPN services </li></ul><ul><ul><li>IPsec, PPTP, L2TP, VTUN </li></ul></ul><ul><li>Application level proxies </li></ul><ul><ul><li>SOCKS 5, HTTP </li></ul></ul><ul><li>DNS </li></ul><ul><ul><li>Primary & secondary hosting </li></ul></ul><ul><ul><li>Caching resolver </li></ul></ul><ul><li>Remote traffic flow monitoring </li></ul><ul><ul><li>Argus (multiple ports) </li></ul></ul><ul><li>Management & diagnostic (covered later) </li></ul>
  26. 26. Host Registration <ul><li>IP and MAC addresses of individual hosts may be registered with firewall. </li></ul><ul><ul><li>Spoofing protection helps prevent service and identity theft. </li></ul></ul><ul><ul><li>Static DHCP simplifies workstation configuration yet still provides each of them with a fixed IP identity. </li></ul></ul><ul><ul><li>Automatic DNS insertion optionally provides complimentary zero-effort DNS mappings for the registered workstations. </li></ul></ul>
  27. 27. Host Registration: spoofing protection <ul><li>Ingress protection blocks registered MAC addresses and IP addresses except when used in their approved pairings for the ingress zone. </li></ul><ul><li>Static address resolution provides egress protection for registered IP addresses. </li></ul><ul><li>An attacker would need to spoof both IP and MAC address </li></ul><ul><ul><li>Harder than just spoofing IP </li></ul></ul><ul><ul><li>Can’t be done ‘by accident’ </li></ul></ul><ul><ul><li>Secure switches can prevent MAC spoofing </li></ul></ul>
  28. 28. Host Registration: spoofing protection (2) <ul><li>Registered IP + wrong MAC : </li></ul><ul><ul><li>blocked completely </li></ul></ul><ul><li>Wrong IP + registered MAC : </li></ul><ul><ul><li>blocked completely </li></ul></ul><ul><li>Unknown IP + unknown MAC : </li></ul><ul><ul><li>Host is unregistered </li></ul></ul><ul><ul><li>Blocked or permitted depending on ingress zone’s host registration policy </li></ul></ul><ul><ul><li>MAC considered unknown if not registered in same security zone </li></ul></ul><ul><ul><ul><li>can use same MAC, registered or otherwise, in other zones </li></ul></ul></ul>
  29. 29. Host Registration Policy <ul><li>Zone option: defines how the ingress zone should handle unregistered hosts </li></ul><ul><ul><li>‘ Do not require’ (default). This is not secure: set this if you are not using host registration or are still transitioning to it. </li></ul></ul><ul><ul><li>‘ Drop’ or ‘Log & Drop’ or ‘Reject’ </li></ul></ul><ul><ul><li>‘ Treat unregistered hosts as being in zone <X>’ </li></ul></ul><ul><ul><ul><li>X must have a ‘Do not require’ policy </li></ul></ul></ul><ul><ul><ul><li>Redirection, Connection Filtering and Services policies of X are used INSTEAD of ingress zone’s own policies </li></ul></ul></ul><ul><ul><ul><li>Packet Filtering and Masquerading policies of X are NOT used: the ingress zone’s policies still apply here. </li></ul></ul></ul>
  30. 30. Host Registration: DHCP <ul><li>DHCP administration </li></ul><ul><ul><li>Registered MAC addresses automatically added as static entries to DHCP server for zone </li></ul></ul><ul><ul><li>A separate zone sharing the same interface can be used to serve dynamic leases from a different subnet to unregistered MAC addresses </li></ul></ul><ul><ul><ul><li>Can have much tighter restrictions </li></ul></ul></ul><ul><ul><ul><li>Used for online self-registration services </li></ul></ul></ul>
  31. 31. Host Registration: DNS <ul><li>Registered IP addresses with hostnames are automatically inserted in forward and reverse DNS. </li></ul><ul><ul><li>Target DNS zones are configured per security zone. </li></ul></ul><ul><ul><li>FireRack must be master DNS server for the DNS zone. </li></ul></ul><ul><li>Just an administrative convenience </li></ul><ul><ul><li>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. </li></ul></ul>
  32. 32. Host Registration: end-user self-registration <ul><li>Option to allow end users to register their own MAC addresses. </li></ul><ul><li>Extra ‘unregistered’ zone is created on same firewall interface as zone for registered hosts, and is given a private IP subnet range </li></ul><ul><li>Unregistered zone is configured with dynamic DHCP lease range, other zones only offer static DHCP allocation to registered MAC addresses. </li></ul><ul><li>Hosts with unregistered MAC addresses get given temporary IP lease in unregistered zone. </li></ul>
  33. 33. Host Registration: end-user self-registration (2) <ul><li>Rules for unregistered zone block all access except to firewall’s DNS server and registration web site (HTTPS). </li></ul><ul><ul><li>Host Registration Policy for other zones can be ‘treat unregistered hosts as being in unregistered zone’ </li></ul></ul><ul><li>All HTTP and HTTP proxy connections are DNAT’d into FMS ‘httpblockd’ service </li></ul><ul><ul><li>All requests are answered with a temporary HTTP redirect to the registration web site. </li></ul></ul><ul><ul><li>When user attempts to access any web site they end up on the registration web site. </li></ul></ul>
  34. 34. Host registration: end-user self-registration (3) <ul><li>Registration web site detects MAC address via live lookup of client IP address in firewall ARP table. </li></ul><ul><li>User authenticates themselves </li></ul><ul><li>User can assign detected MAC address to existing IP address registration </li></ul><ul><ul><li>FMS DB immediately updated </li></ul></ul><ul><ul><li>Optional auto-push of configuration </li></ul></ul><ul><li>User can apply for new IP address </li></ul>
  35. 35. Management Architecture <ul><li>Central management of multiple FireRack appliances from a single FireRack Management Server (FMS). </li></ul><ul><li>Firewall configurations are created and stored in database on FMS. </li></ul><ul><li>SSL encrypted web-based management console allows easy manipulation of firewall configurations. </li></ul><ul><li>FMS builds encrypted and digitally signed ‘pack’ files, each containing configuration snap-shot. </li></ul>
  36. 36. Management Server (FMS) <ul><li>Debian GNU/Linux server with FMS software packages: </li></ul><ul><ul><li>Usually dedicated server </li></ul></ul><ul><ul><li>Can add to existing Debian server </li></ul></ul><ul><ul><li>Also runs in chroot environment on most Linux distributions </li></ul></ul><ul><li>Dedicated servers have VGA port and X-Windows with Mozilla for emergency access to web based management console. </li></ul>
  37. 37. Management Server (2) <ul><li>Standard FMS software packages: </li></ul><ul><ul><li>Configuration database and DB setup tools. </li></ul></ul><ul><ul><li>Web based Management Console / XML-RPC API </li></ul></ul><ul><ul><li>Management engine (‘Genesis’) for building and pushing pack files, and other interactions with firewalls. </li></ul></ul>
  38. 38. Management Server (3) <ul><li>Traffic accounting database and tools </li></ul><ul><ul><li>Proprietry database format </li></ul></ul><ul><ul><li>Data accessible via console, API or command-line tool </li></ul></ul><ul><li>Argus audit logging </li></ul><ul><ul><li>Traffic flows logged to daily or hourly binary log files </li></ul></ul><ul><ul><li>Logs can be read with open-source argus tools </li></ul></ul><ul><ul><li>Very disk intensive – every connection can be logged! </li></ul></ul>
  39. 39. Traffic accounting <ul><li>Realm and Entity based accounting </li></ul><ul><ul><li>An Accounting Entity is a registered host or local zone which is deemed responsible for traffic </li></ul></ul><ul><ul><ul><li>Local traffic may be between two entities and is accounted to the entity that initiated the connection </li></ul></ul></ul><ul><ul><ul><li>Internet traffic typically only involves one entity; that entity is always considered responsible </li></ul></ul></ul><ul><ul><li>An Accounting Realm is a network or set of networks for which separate accounting figures are required </li></ul></ul><ul><ul><ul><li>Realms are defined via the IP routing configuration </li></ul></ul></ul>
  40. 40. Traffic accounting (2) <ul><li>Separate counters are kept for traffic received from and sent to each Realm by each Entity </li></ul><ul><ul><li>Bytes received & sent </li></ul></ul><ul><ul><li>Packets in and out </li></ul></ul><ul><ul><li>New connections in and out </li></ul></ul><ul><li>Management console and self-registration provide summaries and graphing </li></ul>
  41. 41. Traffic accounting (3) <ul><li>FMS collects accounting data samples via firewall SOAP API every 5 minutes </li></ul><ul><ul><li>Timing not critical; samples will be interpolated into exact 5 minute time slots </li></ul></ul><ul><ul><li>When FMS offline or out of contact with firewall, the firewall will take hourly samples itself </li></ul></ul><ul><ul><li>Samples use cummulative counters, so missing samples do not cause inaccurate accounting totals; only resolution is lost </li></ul></ul>
  42. 42. Traffic quota management <ul><li>Optional FMS feature </li></ul><ul><li>Supports multiple concurrent rolling quotas </li></ul><ul><li>Each quota specifies a time-period and maximum traffic volume </li></ul><ul><li>Default per-user or per-IP-address quotas can be set for each zone and overriden for specific users </li></ul><ul><li>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) </li></ul>
  43. 43. Switch Management <ul><li>Optional FMS module </li></ul><ul><li>Uses SNMP to monitor and manage Ethernet switches </li></ul><ul><li>MAC address tracking </li></ul><ul><ul><li>All switches are continuously polled and the locations of all MAC addresses are logged </li></ul></ul><ul><ul><li>Historic data can be viewed for port or MAC address </li></ul></ul><ul><ul><li>Works in combination with Host Address Registration to allow hosts to be identified </li></ul></ul>
  44. 44. Switch Management (2) <ul><li>VLAN configuration </li></ul><ul><ul><li>VLANs are first assigned to ports in database, then the configuration is 'pushed' to the switches </li></ul></ul><ul><ul><li>Administrator defines interconnection of switches and FireRacks and system thus provides automatic configuration of 802.1Q tagged trunks </li></ul></ul><ul><ul><li>Locations and Location Groups can be used to perform bulk updates of VLAN assignments on groups of ports </li></ul></ul>
  45. 45. Management Console <ul><li>Runs on FMS (via Apache 2) </li></ul><ul><li>SSL encrypted </li></ul><ul><li>Requires Javascript: </li></ul><ul><ul><li>Uses RPC for real-time manipulation of FMS database </li></ul></ul><ul><ul><li>Supported browsers: IE 5.5, Mozilla 1.0, NS6 and later versions. </li></ul></ul><ul><li>Integrated XML-RPC compliant management API allows customers to easily automate tasks and interface their own systems to FireRack. </li></ul>
  46. 46. XML-RPC API <ul><li>XML-RPC standard has clients for many platforms and software languages. </li></ul><ul><li>Self-documenting API exposes an object abstraction of FMS database </li></ul><ul><li>Simple methods ‘add’, ‘listobjid’, ‘load’, ‘setval’ allow safe manipulation of objects. </li></ul><ul><li>Various other specialized methods: </li></ul><ul><ul><li>Push configuration </li></ul></ul><ul><ul><li>Pass-through to SOAP API in firewall. </li></ul></ul>
  47. 47. Configuration pack files <ul><li>Built by ‘genesis’ on FMS </li></ul><ul><li>Digitally signed & encrypted </li></ul><ul><li>Pushed to firewall via SOAP </li></ul><ul><li>Firewall archives previous pack files </li></ul><ul><ul><li>Can roll-back firewall configuration to an earlier pack file in an emergency </li></ul></ul><ul><ul><ul><li>Very useful if new configuration breaks connectivity between firewall and FMS! </li></ul></ul></ul><ul><ul><ul><li>‘ factory’ pack contains initial configuration (from time of install or latest upgrade) </li></ul></ul></ul><ul><ul><ul><li>Pack selection available from firewall HTTPS, SSH, serial console and LCD control panel. </li></ul></ul></ul>
  48. 48. Firewall ‘Fail-over’ Pairings <ul><li>Firewalls may be paired together to share a common configuration in DB, to allow for a ‘hot-spare’. </li></ul><ul><li>DB defines a physical ‘identity’ for each firewall and also a virtual ‘master’ identity. </li></ul><ul><li>Each security zone is bound to a specific identity. </li></ul><ul><ul><li>Most zones will be bound to the ‘master’ identity. </li></ul></ul><ul><ul><li>Individual zones with unique IP addresses must be bound to each physical identity to allow each firewall to be managed. </li></ul></ul>
  49. 49. Firewall Pairings (2) <ul><li>Same configuration is pushed to each firewall </li></ul><ul><ul><li>One at a time, only on request </li></ul></ul><ul><li>Each firewall knows its own identity </li></ul><ul><ul><li>It also maintains internal state to remember if it is ‘MASTER’ (it also holds the master identity) or ‘SLAVE’ (does not hold master identify) </li></ul></ul><ul><ul><li>When a pack file is activated, firewall only activates the zones bound to the identities it holds. </li></ul></ul>
  50. 50. Firewall Pairings (3) <ul><li>Switching between MASTER and SLAVE modes: </li></ul><ul><ul><li>Toggles ownership setting for ‘master’ identity and re-activates current configuration pack </li></ul></ul><ul><ul><li>Changes to IP address bindings during pack activation triggers Gratuitous ARP messages (GARP) from firewall for each IP address bound to it. </li></ul></ul><ul><ul><ul><li>GARPs should cause local workstations and routers to update their ARP tables and send all further traffic to newly activated MASTER. </li></ul></ul></ul><ul><ul><ul><li>GARPs are also sent periodically by all firewalls to improve reliablity and provide ARP spoofing antidote. </li></ul></ul></ul>
  51. 51. Firewall Pairings (4) <ul><li>Switching between MASTER and SLAVE modes: </li></ul><ul><ul><li>Use LCD control panel, or </li></ul></ul><ul><ul><li>Use ‘failover master’ or ‘failover slave’ commands from SSH session or serial console. </li></ul></ul><ul><ul><li>Each firewall has no idea what mode the other is in </li></ul></ul><ul><ul><ul><li>When switching one firewall to MASTER, ensure other is set to SLAVE or take it completely offline. </li></ul></ul></ul>
  52. 52. Built in HTTPS server <ul><li>Each firewall has its own HTTPS server. </li></ul><ul><li>Used for basic diagnostics </li></ul><ul><ul><li>Run ping, traceroute, etc. </li></ul></ul><ul><ul><li>View log output, interface status, etc. </li></ul></ul><ul><li>Used for emergency reconfiguration </li></ul><ul><ul><li>Activate a different pack file </li></ul></ul><ul><ul><li>Very basic IP address, routing and rule manipulation (changes are not persistent) </li></ul></ul><ul><li>VPN and interface management: </li></ul><ul><ul><li>Activate and deactivate VPN client connections and other interfaces. </li></ul></ul>
  53. 53. Command line interface <ul><li>Accessed over network via SSH (on non-standard port 48001) or serial console (38400 8N1) </li></ul><ul><li>Has a variety of UNIX/Linux command line tools to aid in diagnostics </li></ul><ul><ul><li>Network monitoring tools: ifconfig, bwm, iptraf, tcpdump, qosstats, arp, etc. </li></ul></ul><ul><ul><li>ping, traceroute, etc. </li></ul></ul><ul><ul><li>logtail – shows firewall logs </li></ul></ul>
  54. 54. Command line interface (2) <ul><li>Administrative commands: </li></ul><ul><ul><li>‘ failover slave’ / ‘failover master’ </li></ul></ul><ul><ul><li>‘ ls /etc/genesis/packs’ lists available pack files </li></ul></ul><ul><ul><li>‘ geninstall install <pack file name>’ activates a pack file </li></ul></ul><ul><ul><li>‘ ifup’ / ‘ifdown’ activate or deactivate an interface or VPN client </li></ul></ul>
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×