Firewall Implementations - USALearning_v401/course/... · Firewall Implementations ... Packet...

18
Firewall Implementations Table of Contents Wireless Access Points .................................................................................................................... 2 Firewalls .......................................................................................................................................... 6 Firewall Implementations ............................................................................................................... 8 Firewalls and the TCP/IP Model .................................................................................................... 10 Flood Guard................................................................................................................................... 13 Packet Filtering Firewalls .............................................................................................................. 14 Stateful Inspection Firewall .......................................................................................................... 17 Notices .......................................................................................................................................... 18 Page 1 of 18

Transcript of Firewall Implementations - USALearning_v401/course/... · Firewall Implementations ... Packet...

Firewall Implementations

Table of Contents

Wireless Access Points .................................................................................................................... 2

Firewalls .......................................................................................................................................... 6

Firewall Implementations ............................................................................................................... 8

Firewalls and the TCP/IP Model .................................................................................................... 10

Flood Guard................................................................................................................................... 13

Packet Filtering Firewalls .............................................................................................................. 14

Stateful Inspection Firewall .......................................................................................................... 17

Notices .......................................................................................................................................... 18

Page 1 of 18

Wireless Access Points

75

Wireless Access PointsConverts wireless signals to wired signals

Connect wireless devices to a wired network

Single Input – Single Output – one antenna / one frequency

Multiple Input – Multiple Output – many antennae & frequencies• Increased capacity over single input – single output mode

Function as bridges, switches, and/or routers based on configuration

Security measures• Change default SSID• Disable SSID broadcast• Enable MAC filtering• Enable WEP, WPA or WPA2 (preferred)• Limit power output – reduce range

Layer 2 & 3

**075 First, when you look at wireless access points-- they're not a security device. But what you have to do is you have to say: Okay since it is a security- since it is a device that needs securing, what kind of capabilities can we put in place? What kind of configurations can we put on it? And the short answer is you could control the signals that are coming from it. Now remember, on one side of this thing you've got a wired network. On the other side you've got a wireless network.

Page 2 of 18

Is this an approved device? See that's the first question that you could ask. And then are the wireless devices that are connecting to it, are they approved devices? Now for sure this is an approved device, in most cases; unless we get into a rogue access point. Somebody finds an open port on your switch. They go: Oh I'll plug in this wireless device so that everybody can use wireless in here and we don't have to configure the ports. If you had port security on, you'd knock that port down, you wouldn't allow it. But if you had port security turned off, you may do an examination against it and actually look at the MAC address on the wired side of that; and it would say: I am a Linksys device; I am a Cisco device: I am a Maru device. Whatever it is, it would announce the manufacturer from it and you could figure that out. So now on the wireless access point availability side of things, we've got single input, single output-- which we don't see these days. I mean, they just got washed away at this point; except for for really, really small devices out there. I would look at the alpha devices for this from a penetration testing standpoint. Single input and single output is kind of washed away.

Page 3 of 18

The other places you would see single input and single output is from an attacker's standpoint we now have software defined radios that will-- any of the wireless spectrum, including cellular data, they can actually capture it and abuse, if you will. Today what we have is multiple input, multiple output; and we shorten it up to MIMO. That's many- many antennas; many infrequencies. Now what's great about this is that we can divide up who's using what. So if I have two antennas here and a whole bunch of people are on this one and a whole bunch of people are on this one, I can say: Like-minded people over here with this frequency, like-minded people over here with this frequency; and then I can split up my bandwidth utilization more accurately. The security component of this is the SSID. Well that's not security. But if you change it from the default, at least people know that you've done some configuration to it. You could disable the SSID broadcasting. But that's not security either. Because as soon as one device that knows its name actually talks to it, it'll send a beacon; and then therefore the SSID has been broadcast at that point. You can enable MAC filtering. You could say: Only these wireless

Page 4 of 18

devices. And then you've degraded availability for the end-users who aren't on that MAC list; and your administration went through the roof. So so far we're 0 for 3 on security. Okay well what could we do for security? Well we could enable encryption. We could also change the signal by limiting the power output and reducing the range. But again, that reduces availability. So we're really only left with one security way in here.

Page 5 of 18

Firewalls

76

Firewalls

An access control point• Restricts or allows access to network resources via rule sets• Drops or allows packets according to its configuration

Packet and content filtering

Stateful inspection• Malware, SPAM, web, email, inbound and outbound traffic

Specialized firewalls• SYN proxy• Web / application proxy• Circuit proxy• Kernel proxy

**076 Let's talk about a true wired device that is a security device; and that's the firewalls. This is a filter at a chokepoint. What do I mean by chokepoint? Well you know all the traffic will pass through this point; whatever is passing through. You know it's passing through at that point. Put something in the way. None shall pass. That's what we say, right? Now how do we filter? Well we can filter at pretty much any one of the layers that's out there.

Page 6 of 18

As we move up the stack in filtering, what happens is we go slower; because the content filtering level of this requires us to dig deep inside the packet, do de-encapsulation, inspect that and compare that to our data analysis engine that's local, or the database of list of evil stuff. And so we're doing this for many, many packets that are passing across there; and that could be really expensive. What we could do is we could do stateful inspection if we wanted to; where we could say: Where did this originate from; what kind of information is communicating; is it inbound or outbound traffic? So firewalls will allow us to do inspection based on kind of source and destination, if you will, and the state of that and who initiated the state. Now there are all sorts of specialized firewalls that are out there: SYN proxies, web/application proxies and circuit proxies and even kernels. And we're going to look at a few of those.

Page 7 of 18

Firewall Implementations

77

Firewall Implementations

Boundary – located between an internal trusted network and an external un-trusted network; may lack authentication and may have weak authentication

Dual-homed – one interface on internal network, another on external network

Screened-host – combination of packet filter with bastion host; host is an externally visible system that’s hardened against attacks; best for low risk, limited access from external systems

Screened-subnet – two filtering firewalls create a DMZ where bastion hosts reside; attackers must pass through both firewalls to access internal network

**077 So where do we put this stuff? How is it set up? In our normal implementations we do what are called boundary. That's at the edge of your network. We put the firewall right there where your router is. It's located between the internal trusted network and the external untrusted network. And if you have an extranet, then that kind of changes things; and we'll see that in a diagram. It probably doesn't have any authentication on it as far as authenticating inbound and outbound users. It may have some sort of weak

Page 8 of 18

authentication on it. But those boundary routers are there to funnel away most of the garbage, is what I call it. And we could have a dual-homed host. And that-- by the way, dual- homed also tends toward routing. And so in a dual-homed host we actually pass all the data up into the server itself or into that host, and we actually inspect for some reason or another; like a circuit level proxy or an application level proxy. We could have a screened-host. And this is a combination of doing packet filtering and what's called a bastion host; which is viewable by the outside world. So it is still a host; and that screened-host has been filtered. You'll see this in the DMZ for your Shared Services network. And that's one host. If we have a screened-subnet, this could be more than one host that is being filtered for. So we say: Okay there's a screened- subnet. The first one is our DMZ. The second screened-subnet is our local area network. Normally screened-subnets are created by creating two filtered firewalls to actually generate a DMZ. So there's a little place in the middle. In most screened-subnets-- not all-- we put those shared services between those two firewalls.

Page 9 of 18

Firewalls and the TCP/IP Model

78

Firewalls and the TCP/IP Model

Stateful firewall Layer 3, tracks conversations

Packet filtering firewall Layer 3, filters on addresses & ports

Application proxy Layer 5, examines packet content

Circuit proxy Layer 5, more broad protection than application proxy, but lacks specifics of control offered by application proxies

**078 Okay when we compare this and the examination of communications at that chokepoint, we start using the TCP/IP model, we talk about stateful packet application and circuit. Notice that they do different things at different layers. In a stateful firewall what we say is at Layer 3 who initiated this conversation? Did it come from my inside network here? Oh nobody said that; no you can't come in, go away, don't talk to me. But: Oh you want to go out there and talk to Google? Okay. And the corresponding response back from

Page 10 of 18

Google: Okay I'll allow that. And I'll map that back and forth. And that's what that stateful firewall does. We can, as we talked before, we can put this on the router itself. Packet filtering firewall is looking much more at the addressing: the source and destination IP address; maybe we put our Bogon filters here. Source and destination port. What is appropriate and inappropriate inbound traffic? If I'm sitting as a firewall at the edge of the network and I've got shared services of a mail server, a webserver and a DNS server. What ports will I allow inbound as a request? Well from a mail server: You can talk 25; that's it, we won't allow you to talk to anything; maybe we'll allow you to talk port 110. My web server: 80 and 443; that's it. DNS server. Well TCP and UDP port 53. Those are the only ports that I'm going to allow through to this shared service network. And that packet filtering firewall will look at that addressing and those ports and deal with it that way. Application layer proxy. Hum. It's got the word 'application layer' in it. So it probably looks at the Application.

Page 11 of 18

Now not- normally this is not for the internet coming to me. This is for these hosts back here. You're all in my local area network and you want to get to a server out on the internet; and that server is specifically configured for our use only. When you want to get that-- I'm your application proxy. So what I'm going to do is I'm going to fulfill those requests based upon- on your behalf. I'm not going to say: Hey he said. I'm going to say: I said I want to talk to you. And then when I turn back inside: She wants it and he wants it and they want it. Okay I'll allow them to go through me. But I create Application layer rules on who's going to be communicating. Finally, and separately-- but you could combine these together-- is the circuit level proxy. And this is a much more broad protection. It says: All of these hosts in this particular subnet, whatever your needs are, go through me; and then I'll send them out to the world. In a circuit level proxy there is only one path that has to go through me. Now today what happens by the way is application proxies and circuit proxies, they actually get melded together in most cases.

Page 12 of 18

Flood Guard

79

Flood Guard

Used to prevent DOS / DDOS attacks

Typically implemented on a firewall

When threshold is met, starts dropping connections

**079 We could do a flood guard. We could, as the firewall, make some decisions; or we could relegate this to others. Let's say that I have our shared services network over here, a web mail and DNS. If I know the total throughput that's possible for those hosts is this quantity of traffic, what I can do with a flood guard is I can say: When the traffic raises to this level for those hosts over there, I will deny future inbound traffic until these other requests have been satisfied. So whatever that threshold is, I can start dropping connections and

Page 13 of 18

sending back reset communications to all of those TCP hosts on there. Now it may be that it's not a TCP conversation. Maybe it's a UDP conversation; and if it's a UDP conversation there aren't any resets, I just drop that traffic at this moment in time. You've got to be prepared for what are they trying to get to? What kind of protocols is it using? Are these connectionless or connection full? And then I'll make my decisions here on the flood guard.

Packet Filtering Firewalls

80

Packet Filtering Firewalls

Operate at layers 3 and 4 of the OSI model

‘Stateless’ inspectors

Good first line of defense but less secure than stateful inspection filters

**080 Let's dig a little deeper into packet filtering firewalls.

Page 14 of 18

So they are Layer 4 and Layer 3; IP and TCP. When they look at this data that's flowing across here-- they're really good for first-line of defense. We don't want to make them do everything. So we just say: These are the decisions we're going to make here. I've talked about the Bogon List before. I think that that's reasonable. Now let's talk about the ports themselves that I should allow to pass through. Before we said UDP and TCP 53; we said 80 and 443 and 25 and 110, we'll allow those to go through. So those are allowed to go through at the port. What about all the other ports? What is appropriate for all of your other communications? Now here's one that people don't think about. Suppose out there in the internet we have extranet clients that want to come inbound, and we want to pass them over to a remote access server; we want to actually pass them through. Sometimes we'd separate this out as a separate box. But sometimes it is this box actually doing this authentication or passing this through. Now we've got to allow other ports; whatever protocols and ports that you are using on those particular clients to access this particular

Page 15 of 18

remote access, we have to enable that. We're going to look at that later on and look for those ports and kind of mark them down on your list: Okay these are the things that I have to make sure that in my packet filtering firewall that I allow those through. The one that I see happening a lot for really small end-users-- you know, as technologists we end up being the support personnel for our families. My next-door neighbor said: I can't get- I can't connect to my corporate LAN actually creating a tunnel to communicate back and forth to it. And what we had to do is we had to enable IPSec and turn on one particular port.

Page 16 of 18

Stateful Inspection Firewall

81

Stateful Inspection Firewall

Maintains information about the “state” of a connection • More control and better information to make filtering decisions

Can time out a connection if delays exceed set limits

Filters based on header only

Cons: Can negatively impact performance

Pros: Greater access control, can analyze packet headers and take action, helps manage stateless protocols

**081 Okay when we talk about stateful inspection. It's great for maintaining the state of connections. I think it's wonderful for that. And what can happen is is we can get delays; we can inject delays and those delays could boot us off the system that we're trying to connect to. Now it's only going to filter based on header information at the TCP or the IP level. It's not going to look higher or lower. Now this could negatively impact performance.

Page 17 of 18

Notices

2

Notices© 2015 Carnegie Mellon University

This material is distributed by the Software Engineering Institute (SEI) only to course attendees for their own individual study.

Except for the U.S. government purposes described below, this material SHALL NOT be reproduced or used in any other manner without requesting formal permission from the Software Engineering Institute at [email protected].

This material was created in the performance of Federal Government Contract Number FA8721-05-C-0003 with Carnegie Mellon University for the operation of the Software Engineering Institute, a federally funded research and development center. The U.S. government's rights to use, modify, reproduce, release, perform, display, or disclose this material are restricted by the Rights in Technical Data-Noncommercial Items clauses (DFAR 252-227.7013 and DFAR 252-227.7013 Alternate I) contained in the above identified contract. Any reproduction of this material or portions thereof marked with this legend must also reproduce the disclaimers contained on this slide.

Although the rights granted by contract do not require course attendance to use this material for U.S. government purposes, the SEI recommends attendance to ensure proper understanding.

THE MATERIAL IS PROVIDED ON AN “AS IS” BASIS, AND CARNEGIE MELLON DISCLAIMS ANY AND ALL WARRANTIES, IMPLIED OR OTHERWISE (INCLUDING, BUT NOT LIMITED TO, WARRANTY OF FITNESS FOR A PARTICULAR PURPOSE, RESULTS OBTAINED FROM USE OF THE MATERIAL, MERCHANTABILITY, AND/OR NON-INFRINGEMENT).

CERT ® is a registered mark owned by Carnegie Mellon University.

Page 18 of 18