Senin, 31 Maret 2008

Securing Small Networks with OpenBSD (Bagian Pertama dari Bagian Satu)

by Jacek Artymiak
02/28/2002

Like almost all things in life, good security costs good money. It has to be that way, because there are simply not enough skilled security specialists to look after all of the networks that need their attention. An unfortunate result of low supply and high demand is the migration of highly skilled personnel to clients who can meet their salary requirements. This leaves a lot of small and underfunded networks in the hands of less experienced administrators, who might not know how to design, configure, and monitor these networks' safety mechanisms, leaving them vulnerable to attacks from unscrupulous people looking for inside information, free warez storage, zombie hosts for DDoS attacks, or systems they can simply destroy for fun of doing it.

Fortunately, many good security products are available for free and can be implemented using commodity hardware components and free or open source software. This article describes the design and implementation of a small network with a split private/DMZ design that allows a high level of protection for its users while making some services available to the outside world. The design is easy to implement and administer, even for beginners, and can serve as a foundation for custom security installations.
Design Time

Our goal is to achieve maximum protection from attacks originating from outside of our network (insider attacks are a separate subject that I may get to in a separate article). At the same time, we do not want to spend a lot of money, which limits our options to open source or free software. This is not as bad as it sounds, because all major free operating systems contain high-quality network security software that can meet requirements of an enterprise client, let alone those of a small business or school network. Also, many of these free solutions are often incorporated into commercial products.

To keep things simple, I will assume that the network we are building will have just one connection to the Internet and that it will only have about a dozen or so internal users. Of course, you can always scale it up or down as you please, keeping in mind that you may need to use faster hardware, split the network into many smaller subnets to avoid bottlenecks, or even add more connection points to the outside world.

The design that seems to be the simplest to build and maintain uses a firewall that protects an internal private network, to which no outside connections can be made, and a so-called "demilitarized zone" (DMZ), in the form of a separate network with some services open to the outside world, also protected by the same firewall. These services might be DNS, WWW, mail, FTP, or news, but you are free to limit or expand that list as needed. The DMZ can consist of a single machine or a number of machines; it all depends on how complex you want it to be.

All traffic coming into our network will be checked and filtered by the firewall, running on a separate machine with three network interfaces:

* Interface A connects the firewall to the Internet. The IP address of the interface is assigned by the ISP (in this article I'll use x.x.x.x).
* Interface B connects the firewall to the internal private network. The IP address of this interface, in this article, will be 192.168.1.1.
* Interface C connects the firewall to the DMZ network. The IP address of this interface, in this article, will be 192.168.2.1.

The general outline of our network will look like Figure 1.
Diagram.
The firewall will use the following rules to manage traffic:

1. All packets sent from the internal private network to all legal addresses should pass through the firewall without any restrictions. (This rule could be more restrictive, if necessary.)
2. All packets sent from the Internet to the private network should be filtered, and only those that are valid responses to the queries originally sent from the internal private network should be allowed into the private network.
3. All packets sent from the Internet to the DMZ should be filtered, and only those that are destined to the services that are being made available on the Internet may pass through the firewall. Also, all valid responses to the queries originally sent from the DMZ should be allowed into the DMZ as well. (This rule could be more restrictive, if necessary.)
4. All packets sent from the DMZ that are valid responses to the queries originally sent from the internal private network should be allowed into the private network.
5. All packets sent from the DMZ to the Internet, but not the private network, should pass through the firewall without any restrictions. (This rule could be more restrictive, if necessary.)
6. All other traffic is discarded.

Apart from the packet filtering rules listed above, we also need a way to make services running on machines in the DMZ available to the outside world. It is perfectly possible to run all services opened to the public on the firewall machine, but by doing so we are asking for trouble, because the more services we actually run on the firewall, the "weaker" it becomes. By redirecting traffic to the DMZ, we are moving the target of a potential attack from the firewall to the DMZ and should the intruders break into these machines, they will still have to break into the firewall and the rest of the network, which considerably slows their efforts down and makes the whole network more secure. (This packet redirection mechanism is sometimes called "port forwarding.")

Related Reading
The Networking CD Bookshelf

The Networking CD Bookshelf
By O'Reilly Media, Inc.

Because small networks will usually have a single IP address assigned by their ISP, the firewall will also need to run some sort of "masquerading" software, which makes all traffic from the internal network and the DMZ appear as if it originated from a single machine. This is an additional security measure that makes our network harder to compromise, because the IP addresses of the machines behind the firewall are never revealed to the outside world.

Free firewall products that can filter packets, redirect traffic to other hosts and perform IP address masquerading are ipfilter, ipfw, ipchains, and iptables. The first two packages are used in the BSD family of operating systems, while the last two packages are popular on the Linux platform.
Choosing Software and Hardware

The firewall software I choose to describe in this article is Daren Reed's ipfilter, running on OpenBSD 2.8. ipfilter is also available for NetBSD, Solaris, SunOS, BSD/OS, IRIX, HP-UX, and QNX. If you use other firewall software, you must remember to translate the rules presented later in this article into the syntax of that particular software package. (The general design principles will be identical in all cases.) I chose ipfilter, because a) I know it well, b) it's been thoroughly tested, c) it's the default firewall on OpenBSD, and d) I like its simple syntax. ipfilter performs stateful packet filtering; that is, it can recognize incoming packets that are replies to the queries sent by users located inside of the protected network, and lets them through without the need to write complex firewall rules. It also includes a straightforward packet redirection and masquerading module, ipnat.

As for the hardware, the machine running the ipfilter firewall software can be any computer supported by OpenBSD or another operating system for which ipfilter is available (either commercial or free), such as NetBSD, as long as it can accommodate at least three network interfaces (one to connect to the Internet, one to connect to the internal private network, and one to connect to the DMZ). My choice was a generic desktop PC with a low-end Pentium processor, equipped with a serial port and three free expansion slots on the motherboard, but it could just as well be an Alpha, Sun, VAX, or any other machine that meets the requirements listed above. In any case, the hard disk that the firewall machine will use should have a capacity of at least 540MB. It is fine to use an IDE drive instead of a SCSI device, as the disk system will not be stressed too much, as long as the machine has at least 24MB of RAM.

Other important components are the network interface cards. For connecting the internal network and the DMZ to the firewall I recommend 10/100Mb/s cards with 10BASE-T sockets for twisted-pair cables with RJ-45 plugs, as they are inexpensive new or secondhand. The rest of the equipment necessary to make everything work together includes twisted-pair cables and 10/100Mb/s hubs with 10BASE-T sockets (or one hub for the private network and one crossover twisted-pair cable, if the whole DMZ sits on a single machine).

I recommend that you use twisted-pair cables (and cards and hubs with RJ-45 sockets) instead of coaxial 10BASE2 cable, because twisted-pair installations are much more reliable, even though they require a hub. (A single failure in a coaxial installation leaves all computers connected to the same cable without access to the network, while a failure of a single twisted-pair cable disconnects only one machine.) That's it -- that's all the hardware you need, besides a Phillips screwdriver.

Now, before you raid second-hand equipment shops in your area or log on to eBay, I suggest that you carefully check the supported hardware lists posted on the OpenBSD Web site, as well as the INSTALL documents found in the top directory for the hardware platform you want to use (i386 for Intel x86 and Pentium processors). This will save you a lot of trouble during installation.

You should also download all available configuration utilities for your computer, disks, controller cards, network interface cards, and the actual chips that these cards use. I recently found a strange Ethernet card that could not be configured using the card manufacturer's own utilities. I used the card chip's manufacturer's utility instead, and it did work as expected. (Thank you, Nick!)

If you are having trouble with a hard disk, try downloading a configuration/setup utility from the disk manufacturer's Web site. If that does not help, go to the computer manufacturer's Web site and download appropriate utilities. These might only be available from the major computer manufacturer's sites; that is why it pays to buy used hardware made by companies that are still around, like IBM, Compaq, Dell, or Gateway.

The last important software tool is a bootable DOS disk or a Windows 95/98 rescue disk from which you will need to boot your computer before you can use the configuration utilities. Since I am not too sure what Microsoft thinks of using DOS or Windows boot disks to configure computers in order to install other operating systems, I suggest that you either obtain a legitimate copy of DOS or MS Windows that you will use for that purpose, buy a copy of DOS from IBM, or better still, download FreeDOS, a free DOS clone. Once you have DOS in one form or another, make a boot disk, remove all unnecessary files from it, and copy the necessary utilities onto it.

(Note that you do not need a copy of DOS or Windows to install OpenBSD itself; bootable disk images are a part of the system's distribution.)

Jumat, 21 Maret 2008

Basic-Routing-HOWTO

V.0.3

If there are any questions or comments, please direct them to
walt@erudition.net. The newest copy of this How-To can always be retrieved
from www.erudition.net/freebsd/. All rights for the reproduction of this
document are reserved.


1. Background.

1.1. What is Network Routing?
1.2. A Simple Example
1.2.1. Introduction to Routers and Gateways
1.2.2 Introduction to Routing Tables
1.2.3 Introduction to IP
1.2.4 MAC (Medium Access Control) Addresses
1.2.4.1 What is a MAC Address?
1.2.4.2 MAC Address Resolution
1.2.5 Point to Point Protocols
1.2.6 Multihoming
1.2.7 Router Information Protocol

1.3 IP Addressing
1.3.1 IP Assignment, TCP, and UDP
1.3.2 Networks, Subnets, and Hosts
1.3.3 Netmasks
1.3.4 Subnets and Network & Broadcast Addresses

2. Application

2.1. NETSTAT(1) and the Routing Table
2.2. IFCONFIG(8), Network Devices, and Assigning IP
Addresses
2.3. IFCONFIG(8) in more Detail
2.4 ARP, IFCONFIG(8) and Network Devices
2.5. ARP(8) and Routing
2.6. ROUTE(8) instead of ARP(8)
2.6.1. Adding routes with ROUTE(8)
2.6.2. ROUTE(8) Flags
2.6.3. ROUTE(8) and the Default Route
2.6.4 Network Routes & Host Routes
2.6.5 Changing Routes with ROUTE(8)

3. PING(8)

4. Basic Host and Network Naming


-----------------------------------------------------------------------------------


1. Background.

1.1. What is Network Routing?

The basic goal behind routing is to find a path from one node to
another by which information can travel, ideally the shortest/most
efficient path. On the Internet and many LANs, this is often accomplished
through the use of RIP (Routing Information Protocol), Router Discovery
Protocol, ARP (Address Resolution Protocol) and RARP (Reverse Resolution
Address Protocol). RIP and Router Discovery Protocol is the domain of the
routed(8) daemon. ARP can be manipulated through the arp(8) program. This
HowTo deals specifically with IPv4.

1.2. A Simple Example

Let us take the example of a very basic network and see how basic
routing concepts can apply to it:


F
|
A --- B --- D --- G
| |
C --- E


Each letter corresponds to a node on the network, which can be a
computer, CISCO router, or any physical medium that can forward data
packets from one point to another, or accept them. If A is a computer
trying to communicate with G, which is also a computer, it must get its
data packets there somehow. Because it is directly connected to only one
other node, B, it can only send its data packets in that direction. Once
these data packets reach B, they have two directions in which they might
be able to go.

1.2.1. Introduction to Routers and Gateways

Let us assume that node B is a router designed to pass on data
packets. Router B knows that it is directly connected to two other places,
but that is all. As B receives data packets from Computer A it looks at
the address to which the data packets are trying to go and realizes that
the packets wish to reach E, to which it is not directly connected.
Because router B does not know anything else about the network other than
the nodes to which it is directly connected, it has a default direction
that it sends data packets which it can not send directly to their
destination. In this network, it was designed by the administrators that
any data packets that router B can not directly send to their destination
it will send to node D, which is gateway. The gateway, like the router, is
designed to forward packets from one place to another, depending on where
the packets want to go, the only difference being that the gateway is more
intelligent, often times a computer.

Gateway D in this example is connected to four different nodes: B,
E, F, G. When it receives data packets from router B it must next decide
in which direction to send them such that they might (eventually) arrive
at their destination. Gateway D realizes that the data packets are trying
to get to node E, to which it is directly connected. As such, it forwards
the packets to node E (which is a computer, but the gateway doesn't know
this) and they are then processed and used in whatever way computer E was
programmed to.

1.2.2 Introduction to Routing Tables

Nodes B and D each knew what nodes they were directly connected
to, and treated one of those nodes as a default direction in which to send
data packets that were not intended for any of the other nodes. This table
of directly connected nodes is called a "Routing Table". Each direction in
which B and D were able to send data packets is called a "Route", one of
which is treated as the "Default Route." For router B, the Default Route
was gateway D.

1.2.3 Introduction to IP

On the Internet, data packets are routed according to a special
addressing scheme which part of the TCP/IP Protocol Suite: IPv4. It uses a
32 bit addressing scheme broken into 4 8-bit parts separated by a period.
An example of an IP address would be: 192.168.100.5 . This is a logical
address assigned to every computer node connected on the Internel and in
most LANs and WANs. Multiple addresses can be assigned to each
computer/router. Let us redraw our simple network to now reflect some of
these new concepts:

(192.168.200.10)
PC #3
|
|
(192.168.100.2) (192.168.200.65)
(192.168.100.5) (192.168.200.1) (192.168.0.1) (192.168.0.7)
PC #1 --------- R #1 ----------- G ------------ PC #2

1.2.4 MAC (Medium Access Control) Addresses

1.2.4.1 What is a MAC Address?

Each "PC" is a Personal Computer. Each "R" is a router, and "G" is
the gateway. Above each PC, router, and gateway we see an IP address(es). IP
addresses are logical addresses because they can be changed on a computer.
This allows for a powerful means of addressing a large network of
computers, however, because it exists on the network layer of the TCP/IP
Protocol, IP addressing is not understood by actual network interfaces,
such as Ethernet cards. In other words, another addressing scheme is also
used to identify individual computers on the "physical" network. Here we
are referring to the MAC (Medium Access Control) address. Each Network
Adapter, such as an Ethernet or Token Ring I/O card has a unique MAC
address. MAC addresses are 48 bit addresses are written in 6 8-bit parts
separated by colons; for instance: 00:0b:27:5c:d3:89 . By convention, each
of the 6 8-bit MAC address parts is written in hexadecimal whereas each of
the 4 8-bit IP address parts is written in decimal.

1.2.4.2 MAC Address Resolution

When data packets are sent from PC #1 in hopes of reaching PC #2,
they first come to Router #1. Router #1 has a routing table based on both
IP and MAC addresses. It checks to see if any entry in its routing table
has the IP address for which the packets are destined: 192.168.0.7. It
realizes that there is no entry in its routing table that has this
particular IP address, so it forwards the packet to via default route,
which is gateway G. Gateway G checks its own routing table to see if it
has an entry with the IP address that the data packets are destined for.
It does, so it next looks up the MAC address associated with that IP
address. If it successfully acquires the MAC address, it forwards the data
packets to the Network Interface that has that MAC address. In this case,
it is an Ethernet Card in PC #2's chasis. MAC address resolution (mapping
IP address -> MAC addresses is handled by the ARP Protocol which was
mentioned in the beginning).

1.2.5 Point to Point Protocols

MAC addresses are used to uniquely identify a multitude of Network
Interfaces on a network, however, in some cases, a much simpler network
connexion is had where a particular computer will not need to worry about
directly talking to many computers (such as gateway G does) so it will not
need to worry about uniquely identify many computers (such as gateway G
does through maintaing a routing table with the IPs and their
corresponding MAC addresses of various nodes). In such cases, where the
computer at hand will be talking directly ("directly" is the key word,
because it may still be able to talk to other computers "through" the one
it is "directly" connecting to) to only one other computer, a simpler
Protocol than ARP can be used. Such one-to-one protocols are called
point-to-point protocols. A popular one is very appropriately called PPP
(Point to Point Protocol); another is SLIP (Serial Line Internet
Protocol), which is relatively outdated.

PPP connexions are most often seen in Internet dialup accounts.
When a user dials up their ISP, they connect directly to only one other
node, a gateway, using PPP. The gateway recognizes the connected PC
directly as ppp0, ppp1, or ppp2, etc, and not by a MAC address, such as
00:0b:27:5c:d3:89 . Let us once again redraw our example network making
use of these new concepts:


(192.168.100.5) (192.168.200.10)
ppp0 sl0
PC #1 PC #3
| |
| |
| |
| |
(192.168.100.6) (192.168.200.2)
(00:0b:28:6c:d4:99) (00:0c:ax:6a:c1:10)
(192.168.200.1) (192.168.0.1) (192.168.0.7)
(00:0b:27:5c:d3:89) (00:0c:ac:7d:c2:98) (10:0c:27:7c:c2:45)
R #1 ------------------ G ------------------- PC #2
|
|
|
(192.168.100.2)
(00:0a:11:45:14:70)
PC #4


1.2.6 Multihoming

As you will notice, some nodes on this network have multiple
network interfaces. An example of such a node is gateway G. Nodes on a
network that have more than more network interface to a particular network
are termed "multihomed."

1.2.7 Router Information Protocol

In large networks (of which our example is clearly NOT) there may
be many possible paths to a particular node from another node. In such
cases, making sure that a particular route is usable and/or efficient as
compared to another can become an arduous for a network administrator. As
such, a network daemon called routed(8)(or 'gated') can be run. routed(8)
maintains a gateway's routing table to keep it clean of dead routes, keeps
routers/gateways directly connected to it informed of any changes to the
routing table (through RIP), locates routers/gateways (through Internet
Router Discovery Protocol) and responds to requests to the gateway's (on
which it is running) routing table. Because routed(8) and 'gated' are
beyond the scope of "basic network routing" they will not be discussed at
any greater length.

1.3 IP Addressing

1.3.1 IP Assignment, TCP, and UDP

When IP addresses are assigned a network, they are conventionally
done so in ranges, and not random patterns. A network in a particular
university department may, for instance, be assigned all of the IP
addresses between 192.168.200.0 and 192.168.200.255 . This does not mean
that each of these addresses must be given a computer, but that when data
packets are set with a destination of any address within that range, they
will enter that particular dept. network. Depending on the protocol by
which these data packets are transmitted, whether a computer with the
actual destination address exists may or may not preclude the sending of
the data packets in the first place. For example, if PC #1 attemps to make
a TCP (Transmission Control Protocol) connexion with a PC #5 which does
not exist on our network, the connexion will fail, and no data packets
will be sent. This is because the TCP protocol is a connexion oriented
protocol and attempts to determine and set a path to the destination
(create a connexion) before sending any data, while on the other hand, if
the data packets were sent using UDP (User Datagram Protocol) packets,
which are connexionless in nature, the data packets would be sent out
blindly and from the sender's perspective would fall into oblivion.

1.3.2 Networks, Subnets, and Hosts

The important point here is the distinction between "network,"
"subnet" and "host." In general, a network is an arbitrary designaion
given to some 2 or more nodes (of something) which communicate. The
individual nodes are called hosts, and groups of hosts within the network
can be logically lumped together and called subnets. Traditionally, in the
Internet, networks were assigned in multiples of 255 hosts. In the
previous example of the departmental network the range 192.168.200.0 to
192.168.200.255 would be such an Internet network. Such Internet networks
that are comprised of 256 addresses are termed class C networks; those
comprised of 256^2 addresses are termed class B networks, and those
comprised of 256^3 addresses are termed class A networks. However, because
LANs often do not require use of this many addresses, Internet networks
are traditionally broken down further by ISPs and/or local network
administrators into subnets, which are smaller yet address ranges.

1.3.3 Netmasks

Returning back to our network example, if we examine the IP
addresses of gateway G and PC #4 we notice that they both share the class
C network of 192.168.0.0 -> 192.168.100.255 while all of the other PCs are
on the class C 192.168.100.0 -> 192.168.100.255 . They can, therefore, be
logically lumped as distinct subnets within the entire network. Ranges
such as this can be denoted by a simpler notation: 192.168.100.0/24 where
the "24" following the forward slash denotes how many bits in the address
should remain the same; everything else can change and, therefore, is part
of the subnet. Here, the first three 8-bit parts (192.168.100) of the
address can not change while the remaining can. All changable addresses
are considered part of this net. If an IP address falls outside the range
of changable addresses, it is considered to be in another subnet and the
data packets are forwarded accordingly. The "24" is called the "netmask"
and is often written in dot notation just as IP addresses are; for
instance, the netmask for the above class C would be 255.255.255.0. This
may seem peculiar at first, but on closer examination we see that
"255.255.255.0" means exactly the same thing as "24" bits. In
255.255.255.0, 24 of the bits are set high (each 8-bit section in the
first three sections being set high and therefore "255" as 2^8 = 255), and
the remaining octet set low, which results in a "0".

1.3.4 Subnets and Network & Broadcast Addresses

Each subnet must reserve two addresses, one for the network
address and one for the broadcast address, with the exception of subnets
of size 1, where the host address is also the network and broadcast
address, which makes sense if there is only one node in the subnet. The
network and broadcast addresses are the first and last addresses within
the range, respectively, which clearly lessens the amount of addresses
addressable to hosts within a subnet by 2. So, in the above example,
192.168.100.0 would be the network address and 192.168.100.255 would be
the broadcast address, both of which will be described later. The
following table illustrates the subnet sizes as relative to the assigned
netmasks:

Netmask # Bits Set High Size of Subnet
--------------------------------------------------------------

255.255.255.255 32 1
255.255.255.254 31 ???
255.255.255.252 30 2
255.255.255.248 29 6
255.255.255.240 28 14
255.255.255.224 27 30
255.255.255.192 26 62
255.255.255.128 25 126
255.255.255.0 24 254


With the existence of distinct subnets within a larger network, we
now have the option of not only routing data packets based on whether they
match a directly connected host or not (in which case they are sent via
the default route) but also based on what subnet they fall in. This
concept becomes especially powerful where gateways connect several large
subnets or networks.

As we saw above each subnet sets aside two addresses for a
"network address" and "broadcast address" which can not be assigned to
hosts within the subnet. The network address plays the important role of
identidying the subnet itself, so essentially, the subnet has an address
too. In our dept. network that we mentioned earlier, where the address
range was 192.168.0.0/24 the network address would be 192.168.0.0 which
could be written as 192.169 for short notation. This identifies the subnet
itself. The broadcast address allows any host on the subnet to send (or
"broadcast") a message to all other hosts on the subnet at the same time
and not simply to a single other host one at a time. Pinging the broadcast
address on a network will, likewise, result in a responce from all of the
hosts thereon (unless they're behind a proxy server or firewalled), and
allow an effective way to help map out the network topology of a network
you're not completely familiar.

In large distributed networks, such as television or radio
networks this concept of simultaneously broadcasting signals to multiple
nodes in the network is of vital importance. When data packets are
simultaneously sent to a select number of multiple nodes and not simply to
every node across a network, we come to the idea of "multicasting."
Muticasting is handled by the 'mrouted' daemon. Because multicasting is
beyond the scope of basic network routing, it will not be mentioned in any
further detail.

2. Application

Firstly, it must be made clear that routing tables can not be
changed by anyone but root. Also, for a box acting as a router/gateway (as
in the case of gateway G in our example nework) to be able to forward
packets to another box it has to have packet forwarding enabled. To
immediately effect this, setting the following sysctl variable thusly is
sufficient:

sysctl -w net.inet.ip.forwarding=1

Then, to have packet forwarding enabled automatically during every
reboot, setting the following option in /etc/rc.conf will be sufficient:

gateway_enable=YES

2.1. NETSTAT(1) and the Routing Table

FreeBSD, being a powerful network-ready OS, is capable of any
routing operation that may be needed. Routing tables being the core
decision making points in a network, we should be able to view the routing
table of any FreeBSD box. This is accomplished by 'netstat -r'

(root@box)~># netstat -r
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
localhost localhost UH 0 2 lo0
(root@box)~>#

A fresh system without any network configuration will have a
routing table very similar to this. There would only be one route, that
for the localhost. The localhost is the generic loopback device for
TCP/IP. Any packets sent to it loop back to the host itself. If you, for
instance, telnet to localhost, you will telnet back into the box you're
on. If you're on a shell account and telnet to the localhost, you will
telnet back into the box that you have your shell account on. This device
must be on for any network oriented operations to work and is enabled by
default in the kernel.

The first column in the routing table is, at it is clearly
identified, the "destination" for the route. In the case of localhost, to
the route to localhost must have "localhost" in the destination column.
The second column, the "gateway" column, is the next hop the route must
take to get closer to the destination. In the case of the localhost, the
only "hop" that must be taken is back to itself, therefore "localhost" is
seen in both columns. The third column lists any flags for the route that
give additional information. The 'U' means that the route is usable, and
the 'H' means that the route is to a host computer and not a
subnet/network. Some common additional flags that may be seen are:

b The route represents a broadcast address
C Generate new routes on use
c Protocol-specified generate new routes on use
G Destination requires forwarding by intermediary
H Host entry (net otherwise)
L Valid protocol to link address translation
S Manually added
U Route usable
W Route was generated as a result of cloning

The next column is "Refs" and indicates how many active connexions
there are using that network device. After that, we have the "Use" column
which indicates how many data packets have been moved through that network
device. Following that, we have the "Netif" column listing the device
names, and finally the "Expire" column indicating the expire times for
various connexions.

The localhost, like many destination and gateway addresses within
the routing table has an IP address representation, which is 127.0.0.1 .
In fact, the name localhost is simply a convention and the loopback
device's address of 127.0.0.1 may be named something else just as easily.
The name is defined in the /etc/hosts file.

The localhost is clearly not capable of facilitating network
communication as it 1) does not uniquely identify a computer, and 2) loops
back to the host itself, which by its very nature denies network
communication. It is, on the other hand, simply a method for identifying
the *local* host.

2.2. IFCONFIG(8), Network Devices, and Assigning IP Addresses

Assuming that a host is connected to a network by some type of
network interface, the host must be given a unique IP address so that
other hosts can communicate to it via the TCP/IP protocol. Let us go back
and look at our original network example and assume that our host is PC #2
equipped with a 3Com 3C509 NIC (Network Interface Card). An IP address
must be assigned to the network device (the 3Com NIC) by which the host
will be communicating with the network. This is accomplished by the
ifconfig(8) command. In our example the IP we gave to PC #2 was
192.168.0.7 . To assign 192.168.0.7 to PC #2's network device, we
would do the following:

ifconfig ep0 inet 192.168.0.7 netmask 255.255.0.0 up

The first parameter given ifconfig(8) is the device name that we
are activating. A list of supported network devices can be acquired from
the online FreeBSD Handbook (http://www.freebsd.org/handbook/). To acquire
the device name (in this case 'ep0') of your NIC you can issue the
following command:

ifconfig -l

This will list all available network devices on your system. Ones
such as ppp0, lp0, sl0, tun0, and lo0 can be ruled out, they being the
network devices: Kernel PPP, PLIP, SLIP, User PPP, and localhost
respectively.


(root@box)~># ifconfig -l
ep0 lp0 tun0 sl0 ppp0 lo0 gif0 gif1 gif2 gif3 stf0 faith0
(root@box)~>#

The "gif0 gif1 gif2 gif3 stf0 faith0" network devices are for IPv6
and can be safely ignored for our purposes.

The second parameter is the address family that is being used. By
default it is 'inet' or the internet address family. Other supported
address families are 'ipx' and 'atalk.' In most cases, inet is the address
family you will be dealing with if your network is connected to the
Internet and/or uses standard TCP/IP to communicate, and as such, the
address family parameter can be left out.

The third parameter is the actual IP address being assigned.

The fourth parameter here is 'netmask' followed by the netmask
that routing at this node will obide by. In this case, 255.255.0.0 was
given as the netmask because our example network has a class B network
address range to assign addresses from.

The last parameter tells the network device to become active with
the previously outlined configuration. Be default, the network device will
be activated with the configuration passed in through ifconfig(8) making
'up' superfluous. As such, 'up' is rarely passed in unless the device was
marked 'down' previously.

2.3. IFCONFIG(8) in more Detail

We can now examine the details of network device setup to
determine whether it is 'up' simply by issuing 'ifconfig ep0' :

(root@box)~># ifconfig ep0
ep0: flags=8843 mtu 1500
inet 192.168.0.7 netmask 0xffff0000 broadcast 192.168.255.255
ether 10:0c:27:7c:c2:45
media: 10baseT/UTP (10baseT/UTP )
supported media: 10baseT/UTP 10baseT/UTP 10baseT/UTP
(root@box)~>#

We can see that, for one, 'UP' is shown for ep0 and that secondly,
on the line below it, the IP address we assigned it is listed. We also
notice the broadcast address which reflects the netmask (also listed, but
in hex as 0xffff0000 - the '0x' initiates every hex netmask and the first
four fs indicate that the first 16 bits are set high, while the last 16
are set low, resulting in 255.255.0.0) we specified: our netmask of
255.255.0.0 indicated that starting on the 16th bit (at the third octet)
our local network began, and therefore, the broadcast address should be
the top most address within that address range. Our network's address
range is 192.168.0.0/16, therefore, our broadcast address is
192.168.255.255 .

We also can see the MAC address of the ep0 network device (the
same one we assigned this host's NIC in our original network example) on
the third line. The current media type and a list of supported media types
can be seen on the fourth and fifth lines respectively.

2.4. ARP, IFCONFIG(8) and Network Devices

If we list our routing table now we will not see any changes, but
once we ping the new IP address:

(root@box)~># ping -c 1 192.168.0.7
PING 192.168.0.7 (192.168.0.7): 56 data bytes
64 bytes from 192.168.0.7: icmp_seq=0 ttl=255 time=0.158 ms

--- 192.168.0.7 ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max/stddev = 0.158/0.158/0.158/0.000 ms
(root@box)~>#

we will see that a new route has been added:

(root@box)~># netstat -r
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
localhost localhost UH 0 2 lo0
192.168 link#1 UC 0 0
192.168.0.7 10:0c:27:7c:c2:45 UHLW 0 20 lo0
(root@box)~>#

Why did the route suddenly appear, and how could we ping the
address if there was no route originally to it? Because ARP is by default
active for all network devices and we had already assigned an IP address
to the ep0 network device, the system was able to through ARP resolve the
192.168.0.7 IP address to the 10:0c:27:7c:c2:45 MAC address. Once this
was done, a route was automatically added to facilitate the path of the
ping. Once the route was added, the ping could proceed successfully. ARP
may be disabled for a network device; if we wanted to make things more
difficult we could disable ARP for our ep0 network device by issuing the
following command:

ifconfig ep0 192.168.0.7 -arp

However, we will not do this as it would be counter-productive to
our successful management of this network.

You will also notice a third entry in the routing table has
appeared. That is a special route to the first address within our network
(192.168.0.0). When we added our IP address we did so with a netmask of
255.255.0.0 which makes the third and fourth octets of our IP address part
of our network - that is, they are address ranges from which addresses can
be assigned to hosts on our network. The first and second octets identify
the network, as those values do not change, that is, all addresses within
our network begin with '192.168' which is a shorthand for 192.168.0.0 . If
you recall our earlier discussion on netmasks, we learned that the network
address of a network or subnet is the first address within its address
range. In our 192.168 class B network, the first address 192.168.0.0 .

the Special link#<0,1,2> type routes are also used to denote other
conditions. For instance, when a route is set to a host and the gateway is
not known/found (because the gateway went down, the host went down or
neither gateway nor host ever existed) it will be shown as a link#1 route.

2.5. ARP(8) and Routing

A very convenient command is called arp(8) which can be used to
return the MAC address mapped to a particular IP address or to return the
entire IP -> MAC table. Issuing the command 'arp -a' does exactly does.
Issuing 'arp 192.168.0.7' would return the MAC address for the IP
address 192.168.0.7 ; for instance:

(root@box)~># arp 192.168.0.7
192.168.0.7 (192.168.0.7) at 10:0c:27:7c:c2:45 permanent
(root@box)~>#

The identifier "permanent" follows the address results indicating
that this particular MAC address entry can not be changed, meaning that it
is the MAC address of some locally installed network device. The entries
in this table for network devices on other nodes on the network can
change. Such changes can take place when hardware is replaced or a node
moves.

arp(8) can also be used to set MAC entries in its table for
particular IP addresses. In our earlier example, where the entry in the
routing table was added automatically when we pinged the IP address of
ep0, we could have manually added the route in the routing table by
issuing the following arp(8) command:

arp -s 192.168.0.7 10:0c:27:7c:c2:45

Because this route would have been manually set, the 'S' flag
would appear for this route in the routing table instead of the 'W' flag:

(root@box)~># netstat -r
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
localhost localhost UH 0 2 lo0
192.168 link#1 UC 0 0
192.168.0.7 10:0c:27:7c:c2:45 UHLS 0 0 lo0
(root@box)~>#

The 'L' flag indicates that this is a link level route, which, in
short, means that it is a route dealing with MAC addresses. Referring back
to our original example network, let us assume we wanted to next set a
route to PC #4 so that PC #2 (our current one) and PC #4 could
communicate. This could be accomplished with the following command:

arp -s 192.168.100.2 00:0a:11:45:14:70

and our routing table would reflect this accordingly:

(root@box)~># netstat -r
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
localhost localhost UH 0 2 lo0
192.168 link#1 UC 0 0
192.168.100.2 00:0a:11:45:14:70 UHLS 1 5 ep0 50
192.168.0.7 10:0c:27:7c:c2:45 UHLS 0 0 lo0
(root@box)~>#

Now PC #4 and PC #2 could communicate using the TCP/IP protocol
suite. Normally, each host will automatically find any directly connected
hosts and add a route in the routing table for them, so manually adding
such routes through arp(8) is usually unnecessary.

2.6. ROUTE(8) instead of ARP(8)

2.6.1. Adding routes with ROUTE(8)

Using arp(8) manually and/or waiting for the system to use ARP to
translate IP addresses to their corresponding MACs and then including that
entry within the routing table is not the only way to set network routes;
in many cases it is impossible or impracticle to determine the MAC address
of a particular host. On a small LAN this would never be a problem,
however, in WANs the case is different. As such, there is a another, more
powerful, command used for setting routes, based on IP addresses as well
as MAC addresses. It is appropriately named route(8) and is a more
conventional method for setting link level routes instead of arp(8).

Strictly IP address routes with route(8) can be set with the
following syntax:

route add

To set link level route as we did earlier with arp(8) the
following syntax can be used:

route add -link

So, the route we set with arp(8) could have been set with route(8)
thusly:

route add 192.168.100.2 -link 00:0a:11:45:14:70

Let is say we wished to now set a route from PC #2 to PC #3.
Clearly as PC #3 is connected to the network via a SLIP connexion we can
not use a link level connexion as we did to PC #4 with arp(8). Examining
the network layout we see that gateway G is the intermediary between PC #4
and PC #2. When setting routes to hosts that are not directly connected,
hop counts are utilized so the system can maintain a measure of the
expense of a particular route. For instance, a route whose destination is
3 hops away is more costly than one that is 1 hop away. Hop counts are
passed to the route(8) command using the -hopcount modifier. As such, we
can set a route thusly:

route add 192.168.200.10 192.168.0.1 -hopcount 1

2.6.2. ROUTE(8) Flags

There are a number of additional flags and modifiers available for
route(8), some of which are listed here:

Modifiers:

-mtu - maximum transmission unit allowed

Flags:

-cloning - generates a new route on use
-iface - destination is directly reachable
-static - manually added route
-nostatic - pretend route added by kernel or daemon
-reject - emit an ICMP unreachable when matched
-blackhole - silently discard packets (during updates)

Viewing our routing table we see the new route:

(root@box)~># netstat -r
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
localhost localhost UH 0 2 lo0
192.168 link#1 UC 0 0
192.168.0.1 00:0c:ac:7d:c2:98 UHLW 1 7 ep0 230
192.168.100.2 00:0a:11:45:14:70 UHLS 2 15 ep0 532
192.168.0.7 10:0c:27:7c:c2:45 UHLS 0 0 lo0
192.168.200.10 192.168.0.1 UGHS 1 5 ep0 20
(root@box)~>#

Data packets now will know they need to travel to gateway G
(192.168.0.1) first in order to reach PC #3 (192.168.200.10) . At gateway
G, they will travel through the SLIP connexion to PC #3, however, as far
as PC #4 is concerned, data packets simply need to be sent in the
direction of gateway G for them to get to their destination. Luckily, the
gateway is directly connected to PC #4, and as such, a route to it would
have been automatically added by the system. It may have also been added
manually using route(8) or arp(8).

2.6.3. ROUTE(8) and the Default Route

Unfortunately, we do not always know the exactly route to a host
as we did in the case of PC #3. We knew it was exactly one hop away and
that this hop was the gateway G. Let us assume that PC #3 is not directly
connected to gateway G, but is in some distant network.


(192.168.100.5) (192.168.200.10)
ppp0 sl0
PC #1 PC #3
| |
| / \
| Haze of Networks
| \ /
| |
| (192.168.200.2)
| (00:0c:ax:6a:c1:10)
(00:0b:27:5c:d3:100) (192.168.0.1) (192.168.0.7)
(00:0b:27:5c:d3:89) (00:0c:ac:7d:c2:98) (10:0c:27:7c:c2:45)
Bridge ------------------ G ------------------- PC #2
|
|
|
(192.168.100.2)
(00:0a:11:45:14:70)
PC #4


We must take a different approach. We still see that data packets must
pass through gateway G in order eventually reach PC #3, however, we do not
know how many hops PC #3 is away. Furthermore, we may also wish contact
other hosts periodically that are located in the "Haze of Networks."
Setting a route to each of them ahead of them, if such a route is even
possible to be set, would suddenly turn into nightmare. Such situations
are handled by the "default" route. When there is no direct route set to a
host, data packets are then moved out the "default" route. In this case,
the default route would be gateway G as it is the intermediary that
connects PC #2 with PC #3 and the rest of the "Haze of Networks." Before
we set the "default" route, let us delete the route we set to PC #3:

(root@box)~># route delete 192.168.200.10
delete host 192.168.200.10
(root@box)~>#

and now:

(root@box)~># route add default 192.168.0.1
add net default: gateway 192.168.0.1
(root@box)~>#

(root@box)~># netstat -r
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 1 10 ep0
localhost localhost UH 0 2 lo0
192.168 link#1 UC 0 0
192.168.0.1 00:0c:ac:7d:c2:98 UHLW 1 7 ep0 230
192.168.100.2 00:0a:11:45:14:70 UHLS 2 15 ep0 532
192.168.0.7 10:0c:27:7c:c2:45 UHLS 0 0 lo0
(root@box)~>#

Also, the route to 192.168.100.2 has become superfluous as packets
can reach it via the "default" route. As such, we can remove it also:

(root@box)~># route delete 192.168.100.2
delete host 192.168.100.2
(root@box)~>#

(root@box)~># netstat -r
Routing tables

Internet:
Destination Gateway Flags Refs Use Netif Expire
default 192.168.0.1 UGSc 1 10 ep0
localhost localhost UH 0 2 lo0
192.168 link#1 UC 0 0
192.168.0.1 00:0c:ac:7d:c2:98 UHLW 1 7 ep0 410
192.168.0.7 10:0c:27:7c:c2:45 UHLS 0 0 lo0
(root@box)~>#

Clearly, the "default" route is powerful and makes many small-time
routing issues easier to deal with, and not to mention, allows for a very
scalable network environment.

2.6.4 Network Routes & Host Routes

Here we also have our first contact with setting routes to
networks. the "default" route is a route to all networks beyond a host's
direct routes. Routes can also be set to specific networks or subnets; for
instance, if we wished to add a route to the '10.54.81' class C network
which, for argument's sake, ws connected to our host via gateway G, we
would issue the following command:

route add -net 10.54.81 192.168.0.1

2.6.5 Changing Routes with ROUTE(8)

route(8) also has other functions. Changing routes can be
accomplished with the "change" command instead of using "delete" and "add"
in succession. Routes can be looked up and returned using the "get"
command, and the routing table can be flushed (cleared), based on address
family or all routes together using the "flush" command followed by any
optional address family identifiers.

If, for instance, you wished to change the gateway of the route to
192.168.0.1 from 00:0c:ac:7d:c2:98 to 00:12:4c:78:23:10 you could issue
the following command:

route change 192.168.0.1 -link 00:12:4c:78:23:10

If you now wished to change the hop count of this route, you could
issue the following command:

route change 192.168.0.1 -hopcount 2

Now, having done this, if we wished to retrieve information on
this route, we could issue the following command:

(root@box)~># route get 192.168.0.1
route to: 192.168.0.1
destination: 192.168.0.1
gateway: 00:0c:ac:7d:c2:98
interface: ep0
flags:
recvpipe sendpipe ssthresh rtt,msec rttvar hopcount mtu expire
16384 16384 0 0 0 2 1500 0
(root@box)~>#

We can see the hop count value as we had adjusted it, along with
the new gateway. For additional usages of route(8), arp(8), ifconfig(8),
ping(8), and netstat(1) the corresponding man pages should be consulted.

3. PING(8)

ping(8) is your friend. It sends ICMP ECHO packets to the target
host, and if there is a route to the host, and the host is up, an ICMP
ECHO from the host will be recieved. Use it to test the integrity of
routes and/or whether a host is alive.

4. Basic Host and Network Naming

Hitherto we have seen the routing table only reflecting the IP
addresses and in only one instance an actual name - localhost. In large
networks, mapping name -> IP and IP -> name is often handled by a local
NIS or DNS server. For small LANs or where strictly local configurations
are employed such that the naming will only be relevant in a small area of
the network or subnet, naming for hosts can be done in /etc/hosts and
naming for networks/subnets can be done in /etc/networks .

4. Basic Host and Network Naming

Hitherto we have seen the routing table only reflecting the IP
addresses and in only one instance an actual name - localhost. In large
networks, mapping name -> IP and IP -> name is often handled by a local
NIS or DNS server. For small LANs or where strictly local configurations
are employed such that the naming will only be relevant in a small area of
the network or subnet, naming for hosts can be done in /etc/hosts and
naming for networks/subnets can be done in /etc/networks .

cite from http://www.erudition.net/freebsd/Basic-Routing-HOWTO

Rabu, 19 Maret 2008

Basics On How To Identify A Firewall By: C0ldPhaTe

Introduction:

Ever since firewalls where first plugged in. They have protected countless networks from prying eyes and malicious attackers. But in today’s Internet community the are far from the security panacea. More and more security vulnerabilities are discovered every year with almost every firewall on the market today. But to top off all the vulnerabilities in the firewalls department you also got to take a look at something else. Misconfired or unmaintained and unmonitored firewalls make the situation even worse. Below I will go into types of firewalls and how to go about attacking your own personal firewalls to see exactly how secure they are.

Firewall Types:

There are two types of firewalls the dominant the Internet market today. Packet filtering gateways and Application Proxies. Widely considered more secure is the application proxies but it has many restrictive performance limitations which has constrained the ability to adopt traffic out of the company rather then traffic into a companies web server. Packet Filtering Gateways on the other hand are more sophisticated Stateful packet filtering gateways, you will find these in the more larger organizations these will contain high performance ground traffic requirements.

A well-configured and well-designed firewall will make your network almost impenetrable. Most of the attackers who have any skills will know this. They will try to simply try and work around the firewalls by simply trying to exploit trust relationships and weak links security vulnerabilities or will try and avoid the hassle of all this and attack a dialup account into the system. So as a system administrator you will have to be on top of your game because even though you have an impenetrable firewall up don’t mean the whity attacker wont just work his way around it.

Another key is working as a firewall administrator your going to want to know about the enemy attacking your system tools he will use and the techniques he will implode on your firewall. So I would recommend going out and downloading some “Hacking Text Files” such as “The Hackers Hand Books” and anything you can find on the internet on “Hacking” or “Security” in general a knowledgeable system administrator is a asset to a strong firewall configuration. Although you might not be able to stop every attacker from gaining access to your system you will cut down the chances for a newbie attack gaining unauthorized access. But the far more advanced attacks that call themselves “l33t” you might have a problem with. So remember to always keep a well-maintained firewall no mater what the circumstances are.

Firewall Identification:

Almost every firewall on the market today has its own unique marks. A little port scanning, firewalking and banner grabbing will allow the attacker to effectively determine the type and version of the firewall being used and almost all the rules of every firewall on the network. Identification is so important because once you have mapped out the targets firewalls you can begin to understands your target weaknesses and begin to launch exploit attacks against them.

The Noisy Technique:

This is known also as direct scanning, this is bay far the easiest way to look for target firewalls. Port scanning specific ports some firewalls on the market will uniquely identify themselves with a simple port scan, all you need to do is to know what to look for while port scanning. With knowledge of the default firewall ports you can configure your nmap to port scan for the selected firewall ports.

So you think your safe because you think your Intrusion Detection System (IDS) will detect these more whity attackers, wrong most Intrusion Detection Systems (IDS) will come configured to hear the most noisy and most clumsy attackers port scans. So most attackers running a port scan on your system with any knowledge doing port scans will remain unnoticed until its actually too late.

Route Tracing:

This is the more quite and subtle way of finding firewalls on a network. You can use the traceroute for Unix or for Windows NT the tracert.exe to find each hop along the path of the target. With Linux you will have the –I option which performances traceroutes by sending simple ICMP packets as opposed to its default UDP packet techniques. For those of you who don’t understand packets look for my “Understanding And Using Packets” tutorial it has a comprehensive list of packets and packeting techniques. Chances are when doing trace route you will see a Host right before your target host chances are this will be a firewall but you wont knows this for sure until you do a little more fingerprinting on the target system or systems.

Another thing you will have to take into your attack is that I have found some firewalls on bigger networks such as www.pixelmedia.com or www.dod.net will not respond to TTL expired packets. But some routers and firewalls are setup too not to return to ICMP TTL expired packets from both the (ICMP and UDP packet). In this cause you will have to try other techniques to find out more specifics on the target firewall or router this can cause for a longer time trying to attack the target system then planed on. On thing you will always want to remember to take your time because once on a target system you the attack have gained unauthorized access which in the united states if a federal offence which will often mean jail time. So it is key to map your moves precisely and always cover your tracks. You can never be to safe when it comes to keeping your identy unknown to the public.

Banner Grabbing:

Port scanning for Firewall ports is helpful when it comes to locating firewall information. But unfortunately most firewalls being used today you will not find listen on the default ports like Microsoft. I would recommend reading a text file on connection to a host with telnet to read there banners or also downloading a port scanner that will read the target banners for you such as 7th Sphere port scanner. Also you will have to take into consideration that many popular firewalls will announce their presents by simply connecting to them. So telneting to the firewall port will often give you the type of firewall running and version information. All this is information you will be able to use to search for exploits on the target. Also using netcat on port 21, which is known as the default File Transfer Protocol (FTP).

C:\>nc –v –n 208.179.244.10 21

(UNKNOWN) [208.179.244.10] 21 (?) open

220 Secure Gateway FTP server ready.

Conclusion:

Within this text file I have talked about the basics methods of finding out what types of firewalls a target host is running. I would also recommend go and downloading off the net a “port list” you can simply go to www.google.com and type in “Port Listings” or “Firewall Port Listings” and you will be amazed with the returned data. There are more advanced techniques to finding out what type of firewalls a target is running but nine times out of ten the techniques within this document will turn up the vulnerable information needed to being your attack on the target. I would also recommend of your reading this not to go out and try to attack www.microsoft.com or bigger sites such as. One you will get your ass arrested and two you will need a lot more information then you just a simple text file. Attacking bigger networks is fun yes, but start off small and build up your knowledge of systems and the applications running on system before you go and try to compress a 250 computer network. If you have any questions you can find me on the mirc channels listed below.

MIRC - irc.dal.net #Antilamer, #cctc, #h4ckerz, #crystalz, #hackalot, #Hackfest, #Hack-i, #Hacku

E.Mail - gbrooks@mcintoshstudent.com

AOL IM: Myst1kal One

Other Documents I Have Written:

In depth Guide Too Hacking Windows Using NetBIOS – February 7, 2003

A complete users guide to port scanning – February 06, 2003

A Quick Unix Command Guide – January 30, 2003

A Definitive Trojan Port Listing – January 30, 2003

Basics On How To Identify A Firewall – January 23, 2003

The Common Gateway Interface (CGI) – November 28, 2002

Microsoft IIS Unicode Exploit Explained - November 13, 2002