Firewall and Gateway Design Traits

Firewall and Gateway Design Traits
Due to the shortage of IP addresses under the current IP allocation
scheme, companies are frequently only allocated a small number of
Internet routable numbers for use on an Internet gateway. Commonly,
this is around an 8 or 16 host subnet, which leaves a limited number of
hosts available for externally facing servers and services. Furthermore,
common security practice dictates that externally facing machines
should be shielded from the full wrath of the Internet by a multi-homed
bastion host, such as a Firewall.
Network Address Translation (NAT)
Many Internet installations make use of Network Address Translation
(NAT) to obscure the real IP’s of servers placed behind the Firewall and
available to the Internet. This may be because the real IP’s are RFC1918
illegal addresses, or simply to hide internal address ranges in use. The
way NAT is used varies depending on the deployment of the gateway,
and the type of firewall, although for ease of configuration, many
Firewall administrators will simply NAT any internal or DMZ hosts to
have the same IP as the Firewall itself.
IP Visibility
Typically, Application Proxy Firewalls are multi homed, with an
external IP for connectivity to the upstream/ISP routers. If a number of
external hosts, including a gateway (e.g. www.example.com,
mail.example.com and gateway.example.com) all have the same IP
address, then that IP is often of some kind of application proxy.
If the external services are spread across a number of IP’s then the
gateway host is most likely to be either a more carefully configured
application proxy, or a Stateful Inspection gateway such as Firewall-1.
In this case, the Firewall’s external IP is used only for connectivity
between the Firewall and Internet hosts, rather than being publicized as
the address on which Internet services are running. Use of phantom

proxy IP’s handled by the Firewall further obscures the true IP of both
the server and the Firewall, making host targeting harder for an
attacker.
Risk Level
This mapping technique uses information that has been previously
gained through passive methods. It is unlikely to alert system
administrators of a hacker’s presence when used so carries a low risk of
discovery.

Unobtrusive Network Mapping

• Web server(s).
• Mail server(s).
• DNS server(s).
• Sub-netting information - This is sometimes obscured.
A simple list of hostnames and IP's can be very revealing about the
topology of a network, and the devices one may expect to find.
Consider a typically secured Internet presence, consisting of:
• Secure gateways.
• Web services.
• FTP services.
• Mail services.
• Secondary security systems, such as IDS.
There are many design characteristics associated with different types of
technology, and by simply examining the host and network
information we have gathered without the targets knowledge, we can
start to speculate on the actual physical network topology involved.

Network Scanning

Network Scanning

Introduction

In this session we will examine the purpose of network scanning -

covering various network mapping tools and techniques, and how best

to employ them.

Stealth

In a real world situation, stealth is a vital element for two main reasons:

• Eliminating suspicion - An attacker does not want to arouse

suspicion for this could lead to a more vigilant inspection of the

network activity.

• Remaining unnoticed - An attacker does not wish to announce his

presence to the system administrators as this could result in a

tightening of network security.

A skilful cracker will therefore use the stealthiest tools and techniques

available to minimize the likelihood of discovery. There are a variety of

techniques that an attacker can deploy to increase their stealth,

including:

• Scanning over a long period of time.

• Avoiding programmed thresholds in security tools.

• Manual inspection of log files.

Different operating modes of tools also have different levels of stealth.

Each tool and technique discussed in this module has therefore been

rated on its level of risk of discovery.

• High Risk - A very visible technique.

• Medium Risk - A technique subject to discovery by a skilled

administrator or well configured security device.

• Low Risk - An almost undiscoverable attack.

Host

Host

Host is another tool from the BIND package that allows the querying of
a name server. It can perform the same queries as both NSLookup and
dig so will only be demonstrated here for the purpose of displaying the
mail servers in the target domain.
host target.com > tmp.txt
The only parameter is the name of the target domain. The output can be
piped into a file using the > tmp.txt as seen before. Figure 8 shows the
results from a host command.


iss.net has address 208.21.0.19
iss.net mail is handled (pri=10) by mutex.netrex.com
iss.net mail is handled (pri=15) by chcg-mx1.iss.net
iss.net mail is handled (pri=5) by atla-mx1.iss.net


Sam Spade
Sam Spade is a Microsoft Windows application providing a variety of
functions not normally available from a Windows command prompt. It
was briefly mentioned in Module 5 as a tool to perform a Whois query,
but can also be used to perform dig and NSLookup queries, as well as
full zone transfers.

Zone Transfer Query Refusal
Zone transfers were conceived as a method for DNS servers to
propagate zone information throughout the zone, thus maintaining a
current zone file on each one. Originally, security was not a primary
concern so any computer could pose as a name server and send a query
for a full zone transfer, gaining valuable information about the hosts on
the targeted domain. Recent implementations of DNS server software
allow a security policy to be configured such that only specified
computers will be able to successfully query the DNS server. Where
such a policy has been configured, results from the above tools will
merely show a message stating that the query has been refused.

successful full zone transfer

successful full zone transfer PROGRAM


; <<>> DiG 8.2 <<>> @suna9.central.susx.ac.uk sussex.ac.uk
axfr
; (1 server found)
$ORIGIN sussex.ac.uk.
@1D IN SOAsunx2.central.susx.ac.uk.
hostmaster.central.susx.ac.uk. (
2000071300; serial
8H; refresh
2H; retry
1W; expiry
1D ); minimum
1D IN NSsunx2.central.susx.ac.uk.
1D IN NSrinka.central.susx.ac.uk.
www.atc1D IN CNAMEatc-server.central.susx.ac.uk.
www21D IN CNAMEinfb.central.susx.ac.uk.
.
.
.
uscs1D IN NSsunx2.central.susx.ac.uk.
1D IN NSrinka.central.susx.ac.uk.
ftp1D IN CNAMEames.central.susx.ac.uk.
@1D IN SOAsunx2.central.susx.ac.uk.
hostmaster.central.susx.ac.uk. (
2000071300; serial
8H; refresh
2H; retry
1W; expiry
1D ); minimum
;; Received 117 answers (117 records).
;; FROM: server to SERVER: 139.184.32.27
;; WHEN: Fri Jul 14 09:52:14 2000

DIG

DIG

; <<>> DiG 8.2 <<>> iss.net

;; res options: init recurs defnam dnsrch

;; got answer:

;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4

;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 9,

ADDITIONAL: 9

;; QUERY SECTION:

;;iss.net, type = A, class = IN

;; ANSWER SECTION:

iss.net.57m50s IN A208.21.0.19

;; AUTHORITY SECTION:

iss.net.56S IN NSehecatl.iss.net.

iss.net.56S IN NSsfld-ns1.netrex.com.

iss.net.56S IN NSchcg-ns1.netrex.com.

iss.net.56S IN NSdnvr-ns1.netrex.com.

iss.net.56S IN NSns1-auth.sprintlink.net.

iss.net.56S IN NSns2-auth.sprintlink.net.

iss.net.56S IN NSns3-auth.sprintlink.net.

iss.net.56S IN NSphoenix.iss.net.

iss.net.56S IN NSns.commandcorp.com.

;; ADDITIONAL SECTION:

ehecatl.iss.net.10h46m41s IN A208.21.0.7

sfld-ns1.netrex.com.1d51m59s IN A206.253.239.135

chcg-ns1.netrex.com.1d51m59s IN A216.89.220.19

dnvr-ns1.netrex.com.26m40s IN A206.253.249.130

ns1-auth.sprintlink.net. 2h20m39s IN A 206.228.179.10

ns2-auth.sprintlink.net. 23h57m52s IN A 144.228.254.10

ns3-auth.sprintlink.net. 23h55m30s IN A 144.228.255.10

phoenix.iss.net.57S IN A208.21.0.13

ns.commandcorp.com.1d1h16m53s IN A 130.205.70.10

;; Total query time: 309 msec

;; FROM: server to SERVER: default -- 193.118.6.35

;; WHEN: Fri Jul 14 08:54:07 2000

;; MSG SIZE sent: 25 rcvd: 420

Performing a Zone Transfer

As with NSLookup, DIG can also be used to request a full zone transfer

once an authoritative name server for the target domain has been

identified.

dig @dns0.target.com target.com axfr > tmp.txt

The parameters provided for the command above are -

Command/Parameter Action

@dns0.target.com Type the name of an authoritative

name server for the target domain,

preceding is with a ’@’.

target.com This is the name of the target domain.

axfr Specifies that a full zone transfer will

be requested.

>tmp.txt The results will be output to a file

called tmp.txt.

DIG HACK

DIG

DIG, standing for Domain Information Groper, is a command line tool
that offers very similar functionality to NSLookup. DIG has two modes:
simple interactive mode that will be shown below, and batch mode
allowing multiple queries to be run sequentially.
Finding the Name Servers for a Domain
To use dig for finding the name servers for a domain is much easier
than using NSLookup, however, it is important to note that this can
generate traceable network traffic. To solve this issue, the file spoon.c
(celerity.bartoli.org) can be used to proxy all dig queries, making them
appear to come from another IP address.
dig target.com ns
When typed at a UNIX or Linux based command prompt, this
command will return the name servers and their IP addresses as shown
in Figure 6. There are two parameters used here:
• target.com - This parameter specifies the target domain for the
query.
• ns - This parameter specifies that name server RR's are requested

Tools Used to Query Name Servers

Tools Used to Query Name Servers

Introduction
It is possible to manually query a DNS server in the same way that a
host on the network would query it, although this is often performed
by an application and the results are not explicitly displayed to the user.
The most common tools and utilities used for manually querying a
DNS server, are:
• NSLookup.
• DiG.
• Host.
• Sam Spade.
NSLookup
This command line utility can be found on UNIX and Windows based
operating systems. Its sole purpose is to query DNS servers, primarily
for troubleshooting, but can also be used to gain valuable information
about the target domain.

Address Record (A)

Address Record (A)

This record is one of the simplest RR’s and perhaps the most common.
Its purpose is to match a host name to an IP address. The Pointer record
(PTR) does the opposite, mapping an IP address to a host name. An
example of an A record in given below:
dns0 IN A 172.30.21.45
Mail Exchange Record (MX)
The MX record specifies a mail exchange server for a DNS domain. The
fields are similar to that of the NS record except there is an extra
numerical value, the mail server priority value. This indicates which
mail server should be attempted first in the situation where more than
one exists for a domain. The server with the lowest priority should be
attempted first. In the following example, showing the MX records for
the development domain, mailserver1 should be tried first, then
mailserver2 and finally mailserver3.
development.example.com IN MX 0 mailserver1.development.example.com
development.example.com IN MX 10 mailserver1.development.example.com
development.example.com IN MX 17 mailserver1.development.example.com
Further Information
For more information on the topics covered so far in this module,
consult RFC 1034, downloadable from the Internet Engineering Task
Force homepage (www.ietf.org).

Significant Resource Records (RR’s)

Significant Resource Records (RR’s)

The zone file that is consulted for each query received by a name server
and propagated throughout the zone on request, is compiled from a
variety of individual records known as Resource Records (RR’s). There
are many different types of RR’s each one performing a different
function and containing different information. The most significant of
these are listed and explained below.
Start Of Authority Record (SOA)
This is the first record in a zone. It is used to determine the version of
the zone file for the name server where it is kept. Each time a change
occurs within the zone file, e.g. a new host is added, the primary server
increments the serial number within this record. Other name servers for
the zone can then request the SOA and compare it to there own to
determine whether they require an updated zone file.
For the purposes of information gathering, this file also contains the email
address of the person responsible for administrating the zone.
Name Server Record (NS)
This record indicates the name servers authoritative for the zone. There
will be NS records for the primary and secondary name servers as well
as NS records for name servers authoritative for other zones so they can
be queried appropriately. Here is a NS record that would be found on
dns2, the primary name server for the sales zone (it is the sales zone as
this is the node closest to the root node, example):
sales.advertising.example.com IN NS dns3.advertising.example.com
The first field states which host or DNS domain this record belongs to.
The IN indicates that the default class, Internet, is used. NS defines this
record to be a name server record and the data field provides the name
of a name server.

Zone Transfers

Zone Transfers

There is one primary name server for each zone, and typically at least
one other secondary name server. The secondary name servers within a
zone need to have a current version of the zone file, the file containing
the host to IP mappings for every host within the zone. Certain
conditions exist where a secondary name server will request a zone
transfer:
• The secondary name server has just been placed on the network or
the DNS service has just been restarted.
• The time specified by the Refresh field on the secondary name
server has elapsed.