Network Security: Protocol Analysis, Firewalls

Tuomas Aura

Protocol analysis:Classic key-exchange protocols and flaws

3

Needham-Schroeder secret-key protocolThe first secret-key key-exchange protocol 1978Kerberos is based on this protocolTrusted server T shares a secret master key with everyone. Encrypts a ticket and session key with master keys:

1. A → T: A, B, NA1

2. T → A: ETA(NA1, B, Kses, ticketAB)3. A → B: ticketAB, Eses(NA2)

4. B → A: Eses(NA2-1, NB)5. A → B: Eses(NB-1)

KTA, KTB = A’s and B’s master keysKses = session key selected by TticketAB = EKTB(Kses,A)

Encryption mode assumed to protect integrity. Nowadays, we would use standard MACs but they did not exist in the 70s. For example:

EK(M) = AES-CBCK(M, HMAC-SHA-1K(M))

4

Needham-Schroeder analysisThe protocol again:

1. A → T: A, B, NA1

2. T → A: ETA(NA1, B, Kses, ticketAB) // ticketAB = ETB(Kses,A)3. A → B: ticketAB, EKses (NA2)

4. B → A: EKses (NA2-1, NB)5. A → B: EKses (NB-1)

T encrypts session key under A’s and B’s master keysAuthenticators for key confirmationNA1 guarantees freshness of ticket and session key to ANA2 and NB guarantee freshness of authenticators to A and BBut no freshness of the ticket to B…

5

Needham-Schroeder vulnerabilityThe protocol again:

1. A → T: A, B, NA0

2. T → A: ETA(NA0, B, Kses, ticketAB) // ticketAB = ETB(Kses,A)3. A → B: ticketAB, EKses (NA)

4. B → A: EKses (NA-1, NB)5. A → B: EKses (NB-1)

Vulnerability discovered by Denning and Sacco 1981Freshness of the ticket not guaranteed to BAssume attacker compromises an old session key and has sniffed the corresponding ticket, orAssume attacker compromises A’s master key KTA. A’s master key is replaced but, before that, the attacker manages to obtain a ticket for B

Replay attack by C who knows an old session key:3’. C(A) → B: ticketAB-old, EKAB-old(NA) // ticketAB-old = EKTB-old(KAB-old,A)

4’. B → C(A): EKAB-old(NA-1, NB)

5’. C(A) → B: EKAB-old(NB-1)

How to fix?

6

Denning-Sacco protocolPublic-key key exchange 1981; flaw found in 1994A obtains certificates from trusted server T for both A’s and B’s public keys

1. A → T: A, B2. T → A: CertA, CertB

3. A → B: EB(TA, Kses, SA(TA, Kses)), CertA, CertB

Kses = session key selected by ACertA = A, PKA, ST (A, PKA)

Analysis:Expiration time missing from certificates → need to be added!Public-key encryption for secrecy of KAB → okPublic-key signature for authenticity of KAB → but what exactly is authenticated?Time stamp for freshness of session key → what about quick replays?

7

Denning-Sacco vulnerabilityThe protocol again:

1. A → T: A, B2. T → A: CertA, CertB

3. A → B: EB(TA, Kses, SA(TA, Kses)), CertA, CertB

The signed message SA(TA, KAB) does not contain all possible information. Q: What is missing?A: The signed message is not bound to the identity of BQ: Does it matter when only B can decrypt the message? A: B could be bad!→ B can forward the last message to anyone else e.g. to C: 3’. B(A) → C: EC(TA, KAB, SA(TA, KAB)), CertA, CertC

C thinks it shares Kses with A but it is really shared with BLegitimate user B can impersonate legitimate users → insider attackHow to fix?

8

Needham-Schroeder public-key protocolThe first public-key key-exchange protocol 1978; flaw found in 1995 [Lowe95]A and B know each other’s public encryption keys or obtain certificates from a trusted server T as neededA and B exchange key material:

1. A → B: EB(NA, A)2. B → A: EA(NA, NB)3. A → B: EB(NB)

NA, NB = secret noncesKses = h(NA, NB)

Analysis:Session key secret and fresh, entity authentication okSession key not bound to A

9

Needham-Schroeder public-key vulnerablity

The protocol again:1. A → B: EB(NA, A)2. B → A: EA(NA, NB)3. A → B: EB(NB) Kses = h(NA, NB)

A authenticates to C. C can forward the authentication of A to B:1. A → C: EC(NA, A)1’. C(A) → B: EB(NA, A) // Re-encrypt for B2’./2. B → A: EA(NA, NB) // Allow through3. A → C: EC(NB) 3’. C(A) → C: EB(NB) // Re-encrypt for B

C thinks it shares Kses with A but also B knows it (for A, everything is ok… in a way)Insider attack: legitimate user B impersonates another user AHow to fix?

Hint: what could be added to each message? Does it help?

10

Wide-mouth-frog protocolToy protocol but interestingA and B share secret master keys with trusted server T. T delivers session keys:

1. A → T: A, EKTA(TA, B, Kses)

2. T → B: EKTB(TT, A, Kses)

KTA, KTB = A’s and B’s master keys shared with TTA, TT = time stampsKses = session key selected by A

Analysis:Encryption must protect integrity → implement with a MACOtherwise, looks pretty good… but there is a subtle issue with the time stamps

11

Wide-mouth-frog protocolThe protocol again:

1. A → T: A, ETA(TA, B, Kses)2. T → B: ETB(TT, A, Kses)

KTA, KTB = A’s and B’s master keys shared with TTA, TB = time stampsKses = session key selected by A

Attack:1. A → T: A, ETA(TA, B, Kses)2. T → B: ETB(TT, A, Kses)1. C(B) → T: B, ETB(TT, A, Kses)2. T → C(A): ETA(TT2, B, Kses)1. C(A) → T: A, ETA(TT2, B, Kses)2. T → C(B): ETB(TT3, A, Kses)1. C(A) → T: B, ETB(TT3, A, Kses)2. T → C(B): ETA(TT4, B, Kses)

… … …Attacker can keep the session key alive for everProblem: authenticated messages 1 and 2 can be confused with each otherHow to fix? Add type tags (e.g. “WMF Msg 1”, “WMF Msg 2”) to make the meaning of messages unambiguous

12

What is a protocol flaw?Researchers like to present spectacular attacks and flaws but the reality is often less black and whiteLimitation on the applicability of the protocol:

Do insider attacks matter?Multiple parallel executions by the same principal?Is the protocol used for its original purpose or for something different?

Requirements for implementations:Encryption mode in old protocols must protect integrity (include a MAC or use non-malleable encryption)Signed and MAC’d messages must include type tags and be parsed unambiguously

New requirements arise over time:Man-in-the-middle attacksDoS protections? Identity protection?Has the protocol become the weakest link after improvements to other parts of the system?

Advanced protocol properties

13

14

Station-to-station (STS) protocolVariation of the original STSSigned ephemeral Diffie-Hellman:1. A → B: g, p, gx 2. B → A: gy, EKses(g

y, g, p, gx, SB(gy, g, p, gx), CertB)

3. A → B: EKses(g, p, gx, gy, SA(g, p, gx, gy), CertA)

Kses = h(gxy)What could be wrong?What does the encryption EK(…) achieve?No known flaws (and STS has been well analyzed)Encryption with the DH session key → identity protection

Why does it need to be ephemeral DH?

15

Modified STSAdd a cookie exchange:1. A → B: NA

2. B → A: NA, NB

3. A → B: NA, NB, g, p, gx 4. B → A: gy, EK(gy, g, p, gx, SB(gy, g, p, gx)), CertB

5. A → B: EK(g, p, gx, gy, SA(g, p, gx, gy)), CertA

K = h(gxy)What does this modification achieve?Responder B verifies A’s IP address before the DH computation → prevents CPU-exhaustion attacks with a spoofed attacker IP addressEven better: make B stateless between messages 2 and 3:NB = h(A,B,NA,NB-periodic) where NB-periodic changes every minute

What is the cost of this defence? Is it worth it?

Tools for protocol analysis

17

Dolev-Yao modelStandard model for protocol analysis:

Network is the attacker. Honest nodes send messages to the network and receive messages from the network

Honest nodes are simple reactive state machines:Honest nodes initiate protocol runs, respond to received messages, and move from state to stateHonest nodes can execute multiple protocol runs in parallel: unlimited parallel instances of the state machine Honest nodes do not reveal their secrets

Attacker plays a game:Attacker has some initial knowledge, such as public data, the secrets of several conspiring nodes, and old session keysAttacker can receive initial messages from honest participantsAttacker’s knowledge grows from each received messageAttacker can perform message decomposition, composition, and cryptographic operations — but only if it know the necessary keysAttacker can send messages to honest participants to trigger response and state change, and to increase its knowledge

Attacker tries to reach an unsafe state where some security goal is brokenUnsafe states defined based on attacker’s knowledge and honest nodes’ state, e.g. A thinks it shares Kses with B, and the attacker know Kses

Protocol analysis toolsExamples of tools for verification of cryptographic protocols:Proverif — Bruno Blanchet (ENS, Paris)

Horn clauses and Applied Pi calculus

Constraint Solver — John Millen (SRI) and Ricardo Corin (INRIA-MSR)

Prolog, CAPSL language for protocol specification

Isabelle theorem prover — Larry Paulson (Cambridge)Lambda calculus, high-order logic (HOL)

Murphi — Stanford/UtahPractically every formal analysis method has been tried

19

Proverif exampleDemo of protocol modelling with Proverif

Proverif models are usually written in Pi calculus, which is easier for a programmer We use Horn clauses — closer to the Dolev-Yao model

Recall the Needham-Schroeder public-key protocol:1. A → B: EB(NA, A)2. B → A: EA(NA, NB)3. A → B: EB(NB)

NA, NB = secret noncesKses = h(NA, NB)

Dolev-Yao model:Network = attackerHonest parties are simple reactive state machinesAttacker’s knowledge set grows over time

Security proof in Proverif is soundSound security proof = complete algorithm for finding all attacksApproximations → may sometimes find attacks that are not real

20

Function and symbol definitionsPublic-key encryption:fun encrypt/3. encrypt(tag, msg, pk) = Epk(msg)Nonces:fun Na/3. Na(x,y,s) = x's nonce for y in the role of Afun Nb/3. Nb(x,y,t) = y's nonce for x in the role of Bfun Nc/1. Nc(u) = Attacker's nonceType tags for messages (could also leave out and find more problems):fun Msg1/0.fun Msg2/0.fun Msg3/0.Host and their states:fun H/1. Honest host H(i)fun C/1. Corrupt host C(i)fun stateA/3. stateA(A,B,NA) = state in role A after sending Msg 1 fun stateB/4. stateB(A,B,NA,NB) = state in role B after sending Msg 2 fun acceptKeyA/4. acceptKeyA(A,B,NA,NB) = final state in role Afun acceptKeyB/4. acceptKeyB(A,B,NA,NB) = final state in role B

21

Attacker’s capabilitiesCreate principals, either honest or corrupt:c:H(i);c:C(i);Attacker knows the message tags:c:Msg1;c:Msg2;c:Msg3;Attacker may generate new nonces (not actually needed):c:Nc(u); Attacker's cryptographic computation:c:encrypt(tag, x, C(i)) -> c:x;c:tag & c:x & c:h -> c:encrypt(tag, x, h); c:tag & c:x & c:y & c:h -> c:encrypt(tag, (x,y), h);Note: “c:” is a predicate meaning “attacker knows”

22

Honest principals’ behaviorRole A:

c:H(i) → c:(stateA(H(i),b,Na(H(i),b,s)), encrypt(Msg1, (Na(H(i),b,s),H(i)), b));

c:stateA(H(i),b,na) & c:encrypt(Msg2, (na,nb), H(i))→ c:(acceptKeyA(H(i),b,na,nb), encrypt(Msg3, nb, b));

Role B:

c:encrypt(Msg1, (na,a), H(j))→ c:(stateB(a,H(j),na,Nb(a,H(j),t)), encrypt(Msg2, (na, Nb(a,H(j),t)), a));

c:stateB(a,H(j),na,nb) & c:encrypt(Msg3, nb, H(j)) → c:acceptKeyB(a,H(j),na,nb);

Modelling state as attacker’s knowledge → attacker can go back to old states of the honest participants. Why is this a sound approximation?

1. A → B: EB(NA, A)2. B → A: EA(NA, NB)3. A → B: EB(NB) Kses = h(NA, NB)

23

Defining attackAttacker knows the session key between honest principals:

c:acceptKeyA(H(i),H(j),na,nb) & c:na & c:nb -> c:attack;c:acceptKeyB(H(i),H(j),na,nb) & c:na & c:nb -> c:attack.

If the attacker knows only one of the nonces, is that an attack?

24

ResultsProverif can prove c:attack → protocol is not secureManually beautified Proverif counterexample:

encrypt(Msg3,NB,B)encrypt(Msg3,NB,C))encrypt(Msg2,(NA,NB),A)encrypt(Msg1,(NA,A),B)encrypt(Msg1,(NA,A),C)

Selected messages only; renamed principals and nonces read from bottom upFixed protocol — add B’s name to Msg 2:

2. B → A: EA(NA, NB, B)

Proverif output:RESULT goal unreachable: c:attack()

25

ExercisesHow to attack the Needham-Schroeder secret-key protocol if the encryption is no integrity-protecting, e.g. EK(M) = AES-ECBK(M) ?Read about the Yahalom and Otway-Rees protocols. Can you find any flaws by yourself?Model the Needham-Schroeder shared-key protocol in ProverifHow would you model identity or DoS protections with a tool like Proverif? (This is a difficult question.)

Firewalls:Stateless packet filter

26

Intranet 1.2.3.0/24

27

FirewallPerimeter defence:

Divide the world into the good/safe inside (intranet) and bad/dangerous outside (Internet)Prevent anything bad from entering the inside

Block communication that is evil, risky or just unnecessary

Internet

28

IPv4 and TCP headers

Which field should a firewall use for filtering?

0 1 2 30 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1

IPv4 Header

TCP Header

Urgent Pointer

Data

Source Port Destination Port 20 bytes

Sequence NumberAcknowledgment Number

Reserved Flags WindowChecksum

Header ChecksumSource Address

Destination Address

Version IHL Type of Service Total Length 20 bytes

Identification Flags Fragment OffsetTime to Live Protocol

(TCP flags: CWR ECE URG ACK PSH RST SYN)

29

Stateless packet filterAllow or block IP packets based on their IP header fields and TCP/UDP port numbers

Fields with static locations in most IP packets: protocol (TCP/UDP/ICMP), source and destination IP address, source and destination port, TCP flags, ICMP type and code

Packet filter is defined as a rule tableLinear list of rulesEach rule consist of conditions and an actionFor each packet, the first matching rule is foundTwo possible actions:allow (=accept, permit, bypass) or block (=drop, deny, discard),maybe also allow and log or block and log

30

Packet filter example (1)Example rule table: inbound email to our SMTP server 1.2.3.10

Protocol Src IP Src port Dst IP Dst port Action Comment

TCP 4.5.6.7 * 1.2.3.10 25 Block Stop this spammer

TCP * * 1.2.3.10 25 Allow Inbound SMTP

TCP 1.2.3.10 25 * * Allow SMTP responses

* * * * * Block Default rule

31

Packet filter example (2)Allow web access from our subnet… not quite right!

Protocol Src IP Src port Dst IP Dst port Action Comment

TCP 1.2.3.0/24 * * 80 Allow Outbound HTTP requests

TCP * 80 1.2.3.0/24 * Allow HTTP responses

* * * * * Block Default rule

Allow only outbound connections:

Protocol Src IP Src port Dst IP Dst port Flags Action Comment

TCP 1.2.3.0/24 * * 80 Allow Outbound HTTP requests

TCP * 80 1.2.3.0/24 * ACK Allow HTTP responses

* * * * * Block Default rule

(TCP packets, except the first SYN, have ACK flag set)

32

Packet filter example (3)University lab network 1.2.3.0/24 (address 1.2.3.0, netmask 255.255.255.0)HTTP/Mail/DNS server 1.2.3.10

Protocol Src IP Src port Dst IP Dst port Flags Action Comment

UDP * * * 53 Allow DNS queries in and outUDP * 53 * * Allow DNS responsesTCP 5.4.3.2 * 1.2.3.10 53 Allow DNS zone transferTCP * * 1.2.3.10 25 Allow Inbound SMTPTCP * * 1.2.3.10 80 Allow Inbound HTTPTCP 1.2.3.121 * * * Block Bob’s test machineTCP * * 1.2.3.121 * Block Bob’s test machineTCP * * 1.2.3.0/24 22 Allow Inbound SSHTCP 1.2.3.0/24 * * * Allow All outbound TCPTCP * * 1.2.3.4/24 * ACK Allow All TCP responses

* * * * * Block Default rule

Is this correct? Could we limit inbound DNS queries to the server?

33

Router as packet filterFirewall rule table is similar to a routing table, with the option of dropping some packetsMost routers can be used as a packet filter

Choice of filters may affect router throughput

Intranet 1.2.3.0/24

33

Internet1.2.3.1 5.6.7.8

interface1 interface2

34

Ingress and egress filteringFilter packets with topologically incorrect (probably spoofed) source IP addresses Ingress filtering for local network:

At the gateway router of a local network, drop inbound packets with source addresses that belong to the local network

Egress filtering for local network:At the gateway router of a local network, drop outbound packets with non-local source addresses

Ingress filtering for ISP:At the gateway router towards a customer, drop packets from the customer if the source address does not belong to the customer

Egress filtering for ISP (less common):At the gateway router towards a customer, drop packets to the customer if the source address belongs to the customer

35

Anti-spoofing filter exampleFilter based on input interface (part of the policy shown only):

35

Intranet 1.2.3.0/24

35

Internet1.2.3.1 5.6.7.8

interface1 interface2

Input interface Protocol Src IP Port Dst IP Port Flags Action Comment

2 * 1.2.3.0/24 * * * Block Ingress filter

2 * 5.6.7.8 * * * Block Router address

1 * 1.2.3.1 * * * Block Router address

1 * 1.2.3.0/24 * * * Allow Egress filter

1 * * * * * Block Default rule (If1)

… …

Dynamic packet filter

37

Dynamic firewallStateful filter: change filtering rules based on previously seen packetsOutbound TCP or UDP packet creates a pinhole for inbound packets of the same connection

Unlike stateless packet filter, can support UDP connectionsTCP pinhole closed with connection, UDP after eg. 30 min

May also allow inbound ICMP messages that match outbound trafficSupport for special protocols:

FTP: firewall may sniff PORT command in FTP to open port for the inbound connectionsX Windows

38

Typical network topology (1)Services accessible from the Internet are isolated to a demilitarized zone (DMZ), i.e. somewhere between the intranet and Internet

383838

Internet

1.2.3.1 5.6.7.8interface1 interface2

Intranet 1.2.3.0/24

Public server(web, email, DNS)

1.2.4.1interface3

1.2.4.10

39

Input Prot Src IP Port Dst IP Port Other Action Comment

2 * 1.2.3.0/24 * * * Block Anti-spoofing

3 * 1.2.3.0/24 * * * Block Anti-spoofing

2 * 1.2.4.0/24 * * * Block Anti-spoofing

1 * 1.2.4.0/24 * * * Block Anti-spoofing

* * {1.2.3.1,1.2.4.1,5.6.7.8} * * * Block Anti-spoofing (router addr)

2 TCP * * 1.2.4.10 80 Allow Access to server (HTTP)

2 TCP * * 1.2.4.10 443 Allow Access to server (HTTPS)

2 TCP * * 1.2.4.10 25 Allow Access to server (SMTP)

2 UDP * * 1.2.4.10 53 Allow DNS query in and out

3 UDP 1.2.4.10 * * 53 Allow DNS query in and out

1 TCP 1.2.3.0/24 * 1.2.4.10 * Allow,create state Access to server from intranet

3 TCP 1.2.4.10 * 1.2.3.0/24 * State Allow Responses

1 UDP 1.2.3.0/24 * 1.2.4.10 53 Allow, create state DNS query

3 UDP 1.2.4.10 53 1.2.3.0/24 * State Allow DNS response

1 * 1.2.3.0/24 * 1.2.4.0/24 * Block Unnecessary

3 * 1.2.4.0/24 * 1.2.3.0/24 * Block Unnecessary

1 * 1.2.3.0/24 * * * Allow, create state Outbound connections

2 * * * * * State Allow Responses

1 TCP 1.2.3.0/24 * {1.2.3.1,1.2.4.1,5.6.7.8} 80 Allow,

create state Router management

- TCP {1.2.3.1,1.2.4.1,5.6.7.8} 80 1.2.3.0/24 * State Allow Router management

* * * * * * Block Default rule

40

Typical network topology (2)Two-firewall configuration for isolating publicly-accessible services from the InternetAll inbound connections use ssh and go through a hardened bastion host in the DMZ

404040

InternetIntranet 1.2.3.0/24

Public server(web, email, DNS)

1.2.4.1interface2

1.2.4.10

1.2.4.11

1.2.3.1interface1

5.6.7.8interface2

FW router A FW router B

1.2.4.2interface1

Bastion host

41

Gateway Router /

NAT

NATIPv4 addresses are in short supplyNative address translator (NAT) is a mechanisms for sharing one IPv4 address between multiple hostsHosts behind NAT can only act as TCP or UDP clients

Internet

192.168.1.103

192.168.1.101

192.168.1.102

157.58.56.78

Internal IP addresses Internet addresses

src=192.168.1.101src port = 3344...

src=157.58.56.78src port = 4567...

192.168.1.1

Internal addr Port External addr Port192.168.1.101 3344 157.58.56.78 4567… … 157.58.56.78 …

42

NATIPv4 addresses are in short supplyNative address translator (NAT) is a mechanisms for sharing one IPv4 address between multiple hostsHosts behind NAT can only act as TCP or UDP clients

Gateway Router /

NAT

Internet

192.168.1.103

192.168.1.101

192.168.1.102

157.58.56.78

Internal IP addresses Internet addresses

192.168.1.1

Internal addr Port External addr Port192.168.1.101 3344 157.58.56.78 4567… … 157.58.56.78 …

dest=192.168.1.101dest port = 3344...

dest=157.58.56.78dest port = 4567...

43

NAT as a firewallNAT maps internal <private IP addr, port> pairs to external <public IP addr, port> pairs and backNAT creates the mapping after seeing an outbound packet → a node on the intranet must initiate the connection→ NAT acts as a dynamic firewallNAT reference types:

Full cone NAT: NAT doesn’t remember peer addressesPort-restricted cone NAT: NAT remembers peer IP address and port and filters inbound packetsSymmetric NAT: different external port (and even address) depending the peer address and port

Port-restricted and symmetric NATs function as firewallsReal NATs rarely implement exactly one of the one of the reference types, and often have additional firewall functionality

44

iptablesFirewall implementation for Unix/LinuxComplex policies can be defined as multiple chains of rules:

Action can be a reference to another chainProvides modularity (“subroutines”) for firewall policies

Example:http://www.fwbuilder.org/archives/cat_examples_of_complete_policies.html

Transport and application-layer firewalls

46

Circuit-level proxyTransport-layer proxy as a firewall

When an intranet client needs to connect to a server outside, it connects to the proxy insteadProxy terminates TCP and UDP connections. Creates a second connection to the server on the InternetProxy is simpler than a host, easier to harden against attacksProxy can filter and normalizes connections

SOCKS management protocol between client and firewallClient requests new connections from firewallAuthentication and authorization of client requests, e.g. GSSAPIError messages to client Supported by most web browsers

Firewall router can be set up to forward only some connections to the proxy for closer inspection

47

Application-level firewallApplication-level firewall filters application data

E.g. email gateway, intercepting web proxyNeed to implement the entire application protocol

Telephone call blocking and barring vs. wiretappingEncrypted data cannot be filtered → what do you do?Are latest applications and features supported?

Firewall issues

48

49

Why filter outbound connectionsSecurity:

Prevent people from accessing untrusted services or dangerous contentPrevent compromised machines from spreading viruses to the Internet, phishing etc.

Cost: Businesses and other organizations are charged by megabyte → block access to P2P, VoIP

Productivity: How do employees spend their time?

Liability: Does free Internet access by employees or visitors expose the company to legal risks?

50

Firewall traversalNetwork admins prefer to block traffic by default→ New applications and protocols will not workNew applications will not gain popularity if an administrative decision is needed at each site → application developers (and users) do their best to circumvent firewalls

Web services over port 80, everything over port 443Skype, Bittorrent etc.

Question: Should all new network applications be standardized and get a port number from IANA, so that they can be filtered by the firewall?

51

Debugging firewall rulesFirewall rules are difficult to configure

Order of rules matters → fragile configurationsConfiguration language and its exact semantics and expressiveness vary between implementationsStateless packet filters have limited expressive power

Performance depends on hardwareRouter may become slower when filtering is enabled, or when specific filters are deployed. What is processed in hardware?

Redundancy may be a clue to errors, but not always:Rule is shadowed if another rule above it prevents it from ever being triggered. Is this intentional?Overlapping rules match some of the same packets. Do they specify the same action or different ones?In a network with multiple firewalls, do you want to block packets that are already blocked by another firewall?

52

Firewall limitationsMay prevent people from doing their work

Try to convince a network admin to open a pinhole for your server

Network admins are often reluctant to change firewall policies in case something breaksMakes network diagnostics harderFirewall configuration errors are commonCoarse-grained filtering for efficient routing and administrationPerimeter defence is ineffective in large networks

There are always some compromised nodes inside

Potential unfiltered ingress routes that circumvent firewalls:Dial-up modem connections in and outUnauthorized access points

Laptops move in and out of the intranetSecurity of home gateways and other network devices is questionableMost applications now use TCP port 80 or 443, or use other clever tricks to traverse firewalls

53

ExercisesWhy cannot ingress filtering ever stop all IP spoofing attacks?Do you find any mistakes or shortcomings in the firewall policy examples of this lecture?Find out what kind of firewall capabilities your home gateway router/NAT has.Find the firewall configuration of a small network. Try to understand each line of the policy. Have compromises on security been made to achieve better performance, to make management easier, or because of limitations in the router?Write firewall policies for the Network topology example (2) in an earlier slide. What compromises will you have to make if the firewalls are stateless packet filters and do not support filtering based on the input interface.Stateless firewall typically allows all inbound TCP packets with the ACK flag set. On a 1 GB/s network, how difficult is it for external attackers to spoof some TCP packets that match the sequence numbers of an intranet TCP connection?