FPGA Network Firewalling

Download Report

Transcript FPGA Network Firewalling

FPGA Network Firewalling
David Thomas
Outline
• The Diadem firewall project
• Role of FPGAs within Diadem
– The IBM FPGA Firewall
• Primary Goals
• Progress
The Diadem Project
• Funded by the EU (your tax Euros at work)
• Nine partners
– Four academic
– Three industrial
• Five countries
– France, Germany, Slovenia, UK, Poland
• Three year project, 6 months left
Diadem Goals
• Create a firewall that uses distributed
elements within networks to detect and
respond to attacks
– Monitoring elements detect attacks in progress
– Policy elements decide how to react to attacks
– Firewall elements put reaction policy into effect
• Target areas are large organisations or ISPs
with many peering points to foreign
networks
Example network architecture
Untrusted
Network
Protected
Servers
Untrusted
Network
Edge Router
Edge Router
Protected
Network
Firewall
Firewall
Diadem network architecture
Protected
Servers
Untrusted
Network
Untrusted
Network
Edge Router
Edge Router
Protected
Network
Firewall
Firewall
Secure
Operator Network
Monitoring
Element
Firewall
Element
Monitoring
Element
Policy
Manager
Firewall
Element
Example : SYN flood attack (1)
•
TCP uses three way handshaking:
1. client -> server : SYN
2. client <- server : SYN, ACK – alloc state
3. client -> server : ACK – established
•
•
•
Between steps 2 and 3 server must maintain
state, using system memory
Memory can only be released after a timeout.
After memory is used up no new connections
can be established
Example : SYN flood attack (2)
•
•
Attacker uses zombies to spoof source addresses
Zombies continually perform steps 1 but never
send packet 3
1.
2.
3.
4.
•
fake_ip1 -> server : SYN
fake_ip1 <- server : SYN,ACK – backlog=1
fake_ip2 -> server : SYN
fake_ip2 <- server : SYN,ACK – backlog=2
Server backlog keeps growing until no new
connections can be established
Example : SYN flood response
•
Use firewall between clients and server to screen
new connections
1.
2.
3.
4.
5.
6.
7.
client->fwall:SYN
client<-fwall:SYN,ACK (using cookie)
client->fwall:ACK (client added to whitelist)
client<-fwall:RST (connection dropped)
client->fwall->server:SYN (client now on whitelist)
client<-fwall<-server:SYN,ACK
client->fwall->server:ACK (connection established)
Diadem network architecture
Protected
Servers
Untrusted
Network
Untrusted
Network
Edge Router
Edge Router
Protected
Network
Firewall
Firewall
Secure
Operator Network
Monitoring
Element
Firewall
Element
Monitoring
Element
Policy
Manager
Firewall
Element
Accelerated network architecture
Protected
Servers
Untrusted
Network
Untrusted
Network
Edge Router
Edge Router
Protected
Network
Secure
Operator Network
Monitoring
Element
Firewall
Element
Monitoring
Element
Policy
Manager
Firewall
Element
The IBM FPGA Firewall (1)
• IBM (one of the partners) have created a hardware
accelerated firewall
• Uses a host PC and a PCI FPGA card
– Host PC reads packets from network and extracts
packet headers
• srcIp,dstIp,srcPort,dstPort,flags : ~ 100 bits
– FPGA does packet classification: looks at packet
headers supplied by host and determines correct action
(accept, reject, log etc.)
– Host PC applies appropriate action to packet and sends
it back to network
• The FPGA only does packet classification
The IBM FPGA Firewall (2)
• They’ve had some problems
– They use weird FPGA boards with no support
– They’re talking to the FPGA in kernel mode!
– The number of rules they can apply is limited by the
amount of TCAM they can instantiate
• TCAMs use SRL16s, not block RAMs
– No expertise in FPGAs
• There is a bottleneck on the PC side
– It is difficult to process gigabit streams in software,
even when packet classification is done in hardware
Enter Imperial…
• What IC brings to the table
– We have RC300s: full duplex Gb ethernet
– We know a lot about FPGAs
– We don’t take three hours for lunch
• Our goal: a standalone FPGA firewall
– Performs the functionality of IBM firewall
– Uses the same API as the IBM firewall
– Operates at high data and packet rates
Current Platform: RC300
• Virtex-II xc2v600 FPGA
– 6 M Gates (33K Slices)
– 2.6 MBits of embedded RAM
• Intel IXF1104 MAC
– Two full duplex 1Gb ethernet ports
– Exposed to FPGA as two 8-bit streams at 125MHz
• Samsung ZBT SRAM
– 4MB of 36 bit wide RAM @ 117MHz
– Four independent banks
– ZBT: can interleave reads and writes at full speed
Firewall Model
Rule changes sent to
firewall element
RC300
Router
Firewall Device
Router
Intranet
Internet
Table updates sent
over USB
Table updates sent
via network
System
Manager
Firewall
Element
Rule changes translated
into updates for firewall’s
internal tables
Assumptions
• The firewall does not need to be very clever
– Rules are translated into tables elsewhere
– Updates are sent to the firewall as binary patches to be
applied to internal tables (as UDP packets or over USB)
• The firewall does not need to maintain state
– No support for packet fragmentation/assembly
– No need to recognise packets as part of a stream
• The firewall is connected to a single endpoint at
each port
– Only needs to know two Ethernet MACs, no ARP
• The set of firewall responses is very simple
Classification
• Classifications is performed on a subset of packet
header info
– Source and destination IP address (2x32 bits)
– Source and destination ports (2x16 bits)
– Miscellaneous flags/protocol type (~12 bits)
• Rules specify list of rules in order or priority
– Dest=server:80, src=?:?, Protocol=TCP – Accept
– Dest=server:?, src=?:?, Protocol=? – Reject
• Classifier needs to find the first matching rule
within the list
Responses
• Basic
–
–
–
–
–
–
Accept, Reject
Redirect (patch IP dest for inward, source for outward)
Log (Envelope packet info and send to an IP)
Reply with error
Throttling (random drop)
Simple combinations of above
• Possible
– Throttling (limit to specified rate)
– SYN flood protection
– Statistics gathering
Firewall Architecture
RC300
Router
Classifier
Classifier Processor
Processor
Router
Port 1
Port 0
Processor
Classifier
Network comms
route to host
Crypto
support
MBlaze
USB
Classifier
Processor
BRAMs
BRAMs
BRAMs
ZBT
RAM
ZBT
ZBTRAM
RAM
DDR RAM
USB comms
route to host
Fast storage for table
overflow
Bulk storage for things like
half-open connections
Integration
• Acts as simple front-end firewall
– Acts as a high-speed barrier when under attack
– Will still require existing IBM firewall behind it to
apply more complex rules (e.g. content inspection)
• Can implement same API as existing IBM firewall
– API implemented on Linux host
– Host translates API calls into table updates and
forwards them to the RC300 over Ethernet or USB
– May only support a subset of functionality
Progress
• Basic firewall is working
– Support up to 1024 rules (IBM does 256)
– Support up to 17.5 Mpackets/s
– Up to 800 Gb/s
• Limited by the Celoxica PSL
• Currently working on integration with
Diadem API
Summary
• Diadem firewall project
– Distributed firewall to respond to distributed
attacks
• FPGAs used within the firewall for speed
• Initial implementation currently running on
the RC300