802.11 Security

[ Pobierz całość w formacie PDF ]

gateway.
Ensure that the subnet address and net mask of the first clause match that of
the interface connected to your upstream provider. The statement not
authoritative tells the DHCP daemon not to assign DHCP addresses
on that interface.
The other two clauses will be used to assign addresses to the clients on the
192.168.0.0 and 192.168.1.0 networks. The option routers
statement will tell the clients to use the IP address of the corresponding
gateway interface as a router for outbound traffic. The option domain-
name-servers statement tells the clients what DNS server to use. Change
this to be the DNS server provided by your ISP. If you want to run a caching
DNS server as described in the next section, change it to match the gateway
address in the option routers statement.
11.7 DNS
In the DHCP configuration outlined in the previous section, the clients are
sent the upstream providers DNS server IP addresses. This is the simplest
way to set things up, but you might want to go to a step further and run your
own DNS server.
There are two common reasons to run your own DNS server: caching DNS
lookups for performance reasons or hosting a domain. DNS caching can
improve performance by handling repeated DNS lookups locally. This
probably won't make a very big difference unless your upstream DNS server
has noticeable delays. The proper hosting of a domain is a more advanced
topic; if you wish to do this, you should consult the DNS server
documentation for information on configuration.
By running DNS as an additional service on the gateway, a new potential
point of vulnerability is introduced. BIND, the most widely used DNS
server, has a history of security issues. To help limit exposure, it should be
set up in a chroot environment. The latest version of BIND and
documentation can be found at http://www.isc.org/products/BIND/.
If you do decide to configure the gateway with a caching DNS server, make
sure you change the DHCP configuration file to give the proper gateway IP
addresses in option domain-name-server. The address will be
different for the wired and wireless segments as the gateway's two interfaces
for those segments have different IP addresses. The DNS server should also
have zone files to handle reverse lookups on your internal address space by
the clients.
11.8 Static ARP
ARP poisoning attacks, discussed in Chapter 2, are a real threat to all entities
on a wireless network, including the gateway. An ARP attack against the
gateway could cut off all network connectivity to the clients. The possibility
of a successful ARP attack can be reduced by setting up static ARP entries
for IP addresses that we know ahead of time.
In the case of the gateway, two particular IP addresses can benefit most from
static ARP: the IP of the access point, and the IP of the cable modem or
router.
Add two lines to the end of /etc/rc.local:
arp -s
arp -s
If there are any hosts on the wired network that are going to act as servers
and will not be using DHCP to get dynamic addresses, it wouldn't hurt to
create static ARP entries for them too.
11.9 Audit Logging
Proper auditing is even more important on the gateway than it is on the
client machines. The gateway is the contact point with the outside world,
and it will receive nonstop abuse from all over the Internet. Because of this,
it's vital to keep a good eye on the logs of this machine.
The services arpwatch, syslog, and swatch should all be installed and
configured in the same fashion as described for the Linux client machines in
Chapter 5.
Don't forget to periodically log in to the gateway and check the logs and root
user mail for evidence of a security breach. Even better, forward this
information to an email account you check often.
11.10 Wrapping Up
At this point, everything should be all set on the gateway. It's a good idea to
reboot and make sure all the services start up without any errors. Fire up a
wireless client, and check to make sure it gets an IP address and can access
the Internet.
Make sure that you keep an eye on the security of the gateway. Periodically
check for updated versions of the software running on the gateway, and
subscribe to any security announcement email lists related to the distribution
you are using. It's everyone's job to help keep the Internet secure; don't let
your brand-new gateway become a springboard for someone to hack other
computers.
Chapter 12. Building a FreeBSD Gateway
The previous chapter examined building a Linux based gateway. Building a
FreeBSD gateway for a wireless network is very similar. This chapter will
examine the steps to set up a FreeBSD gateway comparable in function and
behavior to the Linux gateway already described. The example network
architecture we will be using in this chapter is the same as in the previous
chapter.
Unlike with Linux, network interfaces have different names based on the
type of hardware. Throughout this chapter, we will use dc0, dc1, and dc2
as the network interfaces. These correspond to the common Netgear and
Linksys cards sold in most stores. Replace these with the names you have
created for the three interfaces.
12.1 Building the Gateway
The first step is to install the operating system and configure it to provide the
necessary services. The installation should be minimal as possible. Any
unnecessary services and programs that are installed only increase the risk
that one of the programs on the gateway may be vulnerable. Do not install
the X Windows System or any of the optional applications.
It is important to install the development tools and the system source code.
After installation, you will need to recompile the kernel and the new
versions of several services might need to be downloaded and compiled, so
the development tools will be necessary. The ports collection along with the
cvsup utility will be helpful in installing and updating services too, so it
might be a good idea to install those. Information on ports and cvsup can be
found at http://www.freebsd.org/doc/en_US.ISO8859-
1/books/handbook/ports-using.html.
Make the /var partition of decent size during the drive setup. A couple
hundred megabytes should be more than sufficient. A gateway can generate
many logs and this is where they will be stored.
12.1.1 FreeBSD Kernel Configuration
The kernel configuration should be reviewed to remove unneeded support.
Take out support for anything that won't be needed for the hardware
configuration of the gateway. The general process for doing this and the
details of options are described in Chapter 4 (see Section 4.1.1 and
especially Section 4.1.2). Enable the following options to add support for the
firewall, NAT translation, randomizing IP identifiers, and dropping TCP
SYN/FIN packets: [ Pobierz całość w formacie PDF ]

Podobne