Requerimientos de la aplicaci´on

I

N THIS CHAPTER

:

F

ROM

P

ACKET

F

ILTERS TO

S

TATEFUL

F

IREWALLS

D

ESIGN

E

LEMENTS

P

ROTECTING THE

S

ERVERS WITH

P

ACKET

F

ILTERS

P

ROTECTING

V

IRTUALIZED

S

ERVERS WITH

S

TATEFUL

F

IREWALLS

P

ER

-A

PPLICATION

F

IREWALLS

P

ACKET

F

ILTERS AT

WANE

DGE

D

ESIGN

O

PTIONS

ACME Inc. has a data center hosting several large-scale web applications. Their existing data center design uses traditional enterprise approach:

 Data center is segmented into several security zones (web servers, application servers, database servers, supporting infrastructure);

 Servers belonging to different applications reside within the same security zone, increasing the risk of lateral movements in case of web- or application server breach;

 Large layer-2 segments are connecting all servers in the same security zone, further increasing the risk of cross-protocol attack52_;

 All inter-zone traffic is controlled by a pair of central firewalls, which are becoming exceedingly impossible to manage;

 The central firewalls are also becoming a chokepoint, severely limiting the growth of ACME’s application infrastructure.

The networking engineers designing next-generation data center for ACME would like to replace the central firewalls with iptables deployed on application servers, but are reluctant to do so due to potential security implications.

FROM PACKET FILTERS TO STATEFUL FIREWALLS

The ACME engineers have to find the optimal mix of traffic filtering solutions that will:

 Satisfy the business-level security requirements of ACME Inc., including potential legal, regulatory and compliance requirements;

52 _{Compromised security zone = Game Over}

 Be easy to scale as the application traffic continues to grow;

 Not require large-scale upgrades when the application traffic reaches a certain limit (which is the case with existing firewalls).

Effectively, they’re looking for a scale-out solution, which will ensure approximately linear growth, with minimum amount of state to reduce the complexity and processing requirements.

While designing the overall application security architecture, they could use the following tools:

Packet filters (or access control lists – ACLs) are the bluntest of traffic filtering tools: they match

(and pass or drop) individual packets based on their source and destination network addresses and transport layer port numbers. They keep no state (making them extremely fast and implementable in simple hardware) and thus cannot check validity of transport layer sessions or fragmented packets.

Some packet filters give you the option of permitting or dropping fragments based on network layer information (source and destination addresses), others either pass or drop all fragments (and sometimes the behavior is not even configurable).

Packet filters are easy to use in server-only environments, but become harder to maintain when servers start establishing client sessions to other servers (example: application servers opening MySQL sessions to database servers).

They are not the right tool in environments where clients establish ad-hoc sessions to random destination addresses (example: servers opening random sessions to Internet-based web servers).

Packet filters with automatic reverse rules (example: XenServer vSwitch Controller) are a

permit inbound TCP traffic to port 80), the ACL configuration software adds a reverse rule in the other direction (permit outbound TCP traffic from port 80).

ACLs that allow matches on established TCP sessions (typically matching TCP traffic with ACK or RST bit set) make it easier to match outbound TCP sessions. In server-only environment you can use them to match inbound TCP traffic on specific port numbers and outbound traffic of established TCP sessions (to prevent simple attempts to establish outbound sessions from hijacked servers); in client-only environment you can use them to match return traffic.

Reflexive access lists (Cisco IOS terminology) are the simplest stateful tool in the filtering arsenal.

Whenever a TCP or UDP session is permitted by an ACL, the filtering device adds a 5-tuple matching the return traffic of that session to the reverse ACL.

Reflexive ACLs generate one filtering entry per transport layer session. Not surprisingly, you won’t find them in platforms that do packet forwarding and filtering in hardware – they would quickly overload the TCAM (or whatever forwarding/filtering hardware the device is using), cause packet punting to the main CPU53 _{and reduce the forwarding performance by orders of magnitude.}

Even though reflexive ACLs generate per-session entries (and thus block unwanted traffic that might have been permitted by other less-specific ACLs) they still work on individual packets and thus cannot reliably detect and drop malicious fragments or overlapping TCP segments.

Transport layer session inspection combines reflexive ACLs with fragment reassembly and

transport-layer validation. It should detect dirty tricks targeting bugs in host TCP/IP stacks like overlapping fragments or TCP segments.

53 _{Process, Fast and CEF Switching, and Packet Punting}

Application level gateways (ALG) add application awareness to reflexive ACLs. They’re usually

used to deal with applications that exchange transport session endpoints54 _{(IP addresses and port}

numbers) in application payload (FTP or SIP are the well-known examples). An ALG would detect the requests to open additional data sessions and create additional transport-level filtering entries.

Web Application Firewalls (WAF) have to go way beyond ALGs. ALGs try to help applications get

the desired connectivity and thus don’t focus on malicious obfuscations. WAFs have to stop the obfuscators; they have to parse application-layer requests like a real server would to detect injection attacks55_{. Needless to say, you won’t find full-blown WAF functionality in reasonably priced high-}

bandwidth firewalls.

DESIGN ELEMENTS

ACME designers can use numerous design elements to satisfy the security requirements, including:

 Traffic filtering device protecting every server;

 Stateful firewall protecting every server;

 Per-application firewalls;

 Packet filtering or stateful firewalling at WAN edge;

54 _{The FTP Butterfly Effect}

http://blog.ipspace.net/2010/03/ftp-butterfly-effect.html

55 _{Exploits of a Mom (aka Little Bobby Tables)}

In document ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA INGENIERÍA TÉCNICA EN INFORMÁTICA DE GESTIÓN PORTAL DE COLABORACIÓN CON CAPACIDADES SEMÁNTICAS (página 72-78)