Chapter 1

INTRODUCTION

 

Myriad hacking intrusions into network systems in recent times has spurred this project to develop a secure Firewall on the most secure Operating System of the world – OpenBSD. Along with the Firewall the project also fulfills the implementation of Network Address Translation (IP Masquerading), Port mapping and Reverse Port mapping to provide a secure network structure for Motilal Nehru Regional Engineering College.

 

1.1 Objectives of the Project

The objectives of the project are as follows:

1.       To provide a secure network structure for the MNREC network

2.       To implement an OpenBSD packet filtering Firewall in the gateway of the network

3.       To implement Network Address Translation to translate internal to external Addresses

4.       To implement a security policy for the network

5.       To implement redirection to enable certain internal servers like a mail server, ftp server and www server

6.       To implement a Virtual Private Network

7.       To secure the Gateway PC by implementing OpenSSH in that PC, thus configuring it as an SSH client

 

 

 

 

 

 

 

 

Chapter 2

FIREWALLS AND NETWORKS

 

2.1 Firewall

A firewall is any device used to prevent outsiders from gaining access to your network. This device is usually a combination of software and hardware. Firewalls commonly implement exclusionary schemes or rules that sort out wanted and unwanted addresses.

 

2.2 Components of a Firewall

Firewalls can be composed of software, hardware, or, most commonly, both. The software components can be either proprietary, shareware, or freeware. The hardware can be any hardware that supports the software being used.

If hardware, a firewall can (and often does) consist of no more than a router. Routers have advanced security features, including the capability to screen IP addresses. This screening process allows you to define which IP addresses are allowed to connect and which are not. Other implementations consist of both hardware and software.

In any event, all firewalls share a common attribute: the capability to discriminate or the capability to deny access generally based on source address.

 

 

2.3 Why Firewall

·          Internet susceptible to all kinds of spoofing and other attacks from unauthorized and malicious users.

·          Academic institutions are some of the least guarded and so the most vulnerable.

·          An Internet firewall is a security mechanism that allows limited access to a site from the Internet, allowing approved traffic in and out according to a security policy. This lets you select the services appropriate to your needs, while barring others which may have significant security holes.

 

2.4 Firewall Characteristics

·          A firewall is a set of related programs, located at a network gateway server , that protects the resources of a private network from users from other networks.

·          Enforces the Security policy of a network

·          Can log internet activity efficiently

·          Used in intranets to allow its workers access to the wider Internet

·          Used to prevent outsiders from accessing internal network private data resources

·          Also controls what outside resources internal network users have access to.

·          Works with a router and examines each network packet to determine whether to forward it toward its destination

·          A firewall also includes or works with a proxy server  that makes network requests on behalf of workstation users.

·          Often installed in a specially designated computer separate from the rest of the network so that no incoming request can get directly at private network resources.

·          It guards against all sorts of attacks and keeps a network secure.

·          In firewalls, one can follow either an accept-all or deny-all policy.

·          Two types of Firewalls

1.       Packet filters

2.       Proxy servers

·          Firewall may screen requests to make sure they come from acceptable (previously identified) domain name and Internet Protocol  addresses.

·          A firewall may support  additional features including logging and reporting automatic configuration alarms at given thresholds of attack and user friendly configuration interface.

 

2.5 Types of Firewalls

There are different kinds of firewalls, and each type has its advantages and disadvantages. The most common type is referred to as a network-level firewall. Network-level firewalls are usually router based. That is, the rules of who and what can access your network is applied at the router level. This scheme is applied through a technique called packet filtering, which is the process of examining the packets that come to the router from the outside world.

In a router-based firewall implementation, the source address of each incoming connection (that is, the address from which the packets originated) is examined. After each IP source address has been identified, whatever rules the architect has instituted will be enforced. For example, perhaps the architect decides that no network traffic will be accepted from any address within Microsoft Corporation. Thus, the router rejects any packets forwarded from microsoft.com. These packets never reach the internal server or the network beneath it.

Router-based firewalls are fast. Because they only perform cursory checks on the source address, there is no real demand on the router. It takes no time at all to identify a bad or restricted address. Nevertheless, the speed comes with a price: Router-based firewalls use the source address as an index. That means (barring controls against such access) packets sent from forged source addresses can gain at least some level of access to your server.

Thus the main features of the packet filtering firewall are:

·          The firewall works at the network level

·          It is much faster than a proxy server

·          There is much less load on the machine

·          Filtering is on the basis of source and destination address, port number and protocol, etc

·          Content filtering is not possible, i.e. things like cookies, tickets, keywords, etc cannot be filtered

·          The firewall is invisible to the user

·           

A PROXY SERVER

                Another type of firewall is a proxy server firewall. The main characteristics of a proxy server are:

·          It works at the Application level

·          It is capable of Content filtering, ie. filtering by content rather than by address

·          The proxy makes a request to the server on the web on behalf of the host

·          To the server, it appears that the request is coming from the proxy.

·          These are much slower than packet filtering firewalls.

·          There is much more scope for filtering and more control over the user

·          The proxy has to be configured for every separate application that wants to access the internet

 

2.5 Need for NAT (Network Address Translation)

·          The NAT router translates source and destination addresses of traffic coming into and leaving the private network.

·          There are much more private network addresses than public addresses. Public IP network addresses are:

A class: 10.0.0.0 network

B class: 172.31.0.0 network

C class: 192.168.0.0 network

To accommodate these, NAT is vital.

·          The private IP addresses are not valid outside the internal network. Thus it is necessary to translate them into valid public IP addresses at the router itself.

·          Translates private internet addresses to public (valid) internet addresses and vice versa

·          Also called IP Masquerading as it disguises the source IP addresses of internal hosts from the outside world.

·          It works by mapping requests from different internal hosts to different ports. This is called port mapping. Reverse Port Mapping is port mapping in the reverse direction

·          It also enables specific internal hosts to be used as service providers (eg. http server, ftp server, etc.) to the outside world. This is performed by using redirection.

 

2.6 NAT, Firewall And Proxy : A comparision

 

2.6.1 Proxy:  Proxy servers are available for: Win95, NT, Linux, Solaris, etc.

            Pro:    +  1 IP address ; cheap

                       + Optional caching for better performance (WWW, etc.)

            Con:  - All applications behind the proxy server must both SUPPORT  Proxy services and be CONFIGURED to use the Proxy server

                 A proxy server uses only public IP address, like IP MASQ, and acts as a translator to clients on the private LAN (WWW browser, etc.).

                 This proxy server receives requests like TELNET, FTP, WWW, etc. from the private network on one interface.  It would then in turn, initiate these requests as if someone on the local box was making the requests.   Once the remote Internet server sends back the requested information, it would re-translate the TCP/IP addresses back to the internal MASQ client and send traffic to the internal requesting host.  This is why it is called a PROXY server. 

                   (Note:  ANY applications that you might want to use on the internal machines *MUST* have proxy server support  like Netscape and some of the better TELNET and FTP clients.  Any clients that don't support proxy  servers won't work.)

 Another nice thing about proxy servers is that some of them can also do caching (Squid for WWW).  So, imagine that you have 50 proxied hosts all loading Netscape at once.  If they were installed  with the default homepage URL, you would have 50 copies of the same  Netscape WWW page coming over the WAN link for each respective computer. With a caching proxy server, only one copy would be downloaded by the proxy server and then the proxied machines would get the WWW page from the cache.  Not only does this save bandwidth on the Internet connection, it will be MUCH MUCH faster for the internal proxied   machines.

 

2.6.2 1:Many NAT               

                 Pro:       + Only 1 IP address needed (cheap)

                                + Doesn't require special application support

                                + Uses firewall software so your network can become  more secure

                 Con:       - Requires a Linux or BSD Unix box or special ISDN router

                                  (though other products might have this..  )

- Incoming traffic cannot access your internal LAN unless the internal LAN initiates the traffic or specific port forwarding software is installed. Many NAT servers CANNOT provide this functionality.

                The major difference between a MASQ and PROXY server is that MASQ servers don't need any configuration changes to all the client machines.  Just  configure them to use the OpenBSD box as their default gateway and everything  will work fine. Also, many users operate IP MASQ for TELNET, FTP, etc. *AND* also setup a caching proxy on the same box for WWW traffic for the additional performance.

 

2.6.3 NAT:    NAT servers are available on Windows 95/NT, Linux, Solaris, and some of the better ISDN routers

             Pro:           + Very configurable

                                + No special application software needed

                Con:        - Requires a subnet from your ISP (expensive) Network Address Translation is the name for a box that would have a pool of valid IP addresses on the Internet interface which it                                can use.  Whenever the Internal network wanted to go to the Internet, it associates an available VALID IP address from the Internet interface to the original requesting PRIVATE IP address.  After that, all traffic is re-written from the NAT  public IP address to the NAT private address. Once the associated PUBLIC NAT address becomes idle for some pre-determined amount of time, the PUBLIC IP address is                               returned back into the public NAT pool. 

The major problem with NAT is, once all of the free public IP addresses are used, any additional private users requesting Internet service are out of luck until a public NAT address becomes free.

 

2.7 NAT and Proxies

                Outside  of  the  corporate  environment,  one  of  the biggest  enticements  of firewall technology to the end useris the ability to connect several computers through a common external  interface,  often without the approval, knowledge, or even consent of their service provider.  To those  familiar  with Linux, this concept is called IP Masquerading, but to the rest of the world it is known  by  the  more  obscure name of Network Address Translation, or NAT for short.

Chapter 3

SECURITY ATTACKS AND FIREWALLS

 

3.1 Types of Attacks

 

3.1.1 Internet Address Spoofing

Here the hacker generates synthetic data packets with bogus IP sent addresses pretending to be packets from an internal station. It is particularly dangerous for packet filtering firewalls.

 

3.1.2 TCP Sequence Number Attacks

This attack is based on the 3-step handshake sequence used when establishing a TCP connection. It assumes the bogus IP packets can be sent into the internal computer system from outside using IP address spoofing.

Suppose a client A wants to get in touch with the remote shell server B, the 3 steps are as follows-

                1.A->B:SYN, A_Sna

                2.B->A:SYN, A_Snb

                3.A->B:ACK(A_Snb)

Although it is apparent to the outside observer that the initial sequence no. is chosen randomly, but in fact they are produced by a simple algorithm. According to the Internet documentation 693 a 32 bit counter must have its least significant digit increased by 1 every 4 microseconds. Thus it may be predicted what sequence no. a system will use the next time it sets up call.

 

3.1.3 ICMP Attacks

The ICMP is an integral part of the internet protocol and is usedto tell people sending IP packets if a network problem has occurred. They can then take appropriate action. On the other end routers or hosts often analyze such messages automatically and reconfigure accordingly by sending bogus synthetic ICMP packets, hackers can often get computer system to do what they  want.

 

ICMP attacks aim to:-

·          Render the network unusable( source quench, fragmentation needed, destination unreachable, etc.).

·          Change the routing paths( ICMP redirect and so cause the sysytem to collapse).

 

3.1.4 The IP Fragment Attack

Fragmenting IP data Packet is normally used to handle network section that only support a given maximum ip packet length. Once sent the individual fragments are not reassembled immediately but routed on to their final destination. Only then they are put together to give the original IP packet. Apart from IP header all each packet contains is an ID no. and a fragment offset that clearly identifies their fragments and their order. Fragment packets are therefore a threat to firewall system based on packet filtering which base their routing decision on tcp port numbers, because only the first fragment holds the tcp port no.and fragments  with no tcp no. can not be filtered out. If the first packet does not have a fragment sequence the target station rejects any further packet fragments that arrive , but modified tcp implementation can be used to analyze incomplete sequence of fragments and so bypass the firewall system.

 

3.1.5 Internet Routing Attacks

By using inputs in the 8 bit option field, IP packets canbe used to do a no. opf other things as well, but these are normally only used by system manager for testing and monitoring purposes. However  routing options such as “loose source routing”  can also be used to hack into a system  from the outside.

 

3.1.6 The source routing attack

The person who sends the IP routing packet can determine the route through the network. With strict source Routing each route node must be specified in the correct sequence. Any two node listed in the succession must actually have  a direct link between them, if not ,an error message is sent. In contrast loose source routing also allows individual jumps between two specified nodes and is therefore an ideal opportunity for hacker. The data flow to destination can easily be redirected to the hacker’s system.

3.1.7 The RIP attack

Using a RIP attack, it is possible to divert entire communication links between two internal stations via the hacker. To do this , the hacker X simulates an internal station and sends modified RIP packets to the second target station B and to gateways between X and B. The RIP packets tell B and the gateways not to send packts from B to A  but to X. The hacker X analyzes the packets arriving for A and sends them on with the source route option to their actual destination A. By activating the source option X ensures that all packets A sends back to B are monitored.

RIP attacks can be prevented by gateways that block IP address spoofing packets.

 

3.1.8 Broadcast Storm Through Misusing ARP

ARP attacks can be used to overload networks in the hope of bringing about unspecified situations which can then be used to hack into the system.

                If bogus ARP packets are generated to search non-existent IP addresses, this quickly leads to a gateway “broadcast storm”, with all the gateways trying to broadcast on to the networks online. Sending bogus “ARP replies” from the non-existent addresses after the 1st broadcast storm that the gateway broadcasts as well can even enhance this effect. Such broadcast storms quickly fill up most of the available transmission bandwidth and hamstring the network concerned.

 

3.1.9 UDP Spoofing

                Connections based on UDP are to be looked at as insecure in general, as this protocol is extremely easy to simulate. As neither sequence no. nor acknowledgement packets are used, any application based on them must  subject the network address of the host in each case to an authentication process.

               

3.1.10 Hacking Via Remote Login

                Remote login applications such as telnet, rlogin or rsh are particularly vulnerable to  hackers, once inside the network, the hacker can then wreak havoc.

 

3.1.11 Telnet attacks

Telnet is a simple remote terminal application which can be used to control computer systems interactively via the network. First the telnet client sets up its login program, enters the user id and password and opens the telnet session. From hereon in , all keyboard inputs are sent to the remote server and , in the other direction, all remote server outputs are sent to the local telnet client.

                As all telnet applications use the standard network interface NVT, two system can communicate with one another via telnet, even if they use totally different data formats internally. The NVT data format uses the standard 7-bit ASCII character representation with the exception that the most significant bits are used for control commands. The NVT data format is based on the standard ascii character set with the most significant bit reserved for command sequences. Therefore everything transmitted during the telnet session is sent in plain text. This makes it easy for hackers to get hold of telnet logins and password by using monitoring programs like Ethload, Esniff, and Snoop etc.

 

3.1.12 Attack Via rlogin and rsh

                Remote login (rlogin) and remote shell (rsh) are particularly critical in terms of network security using telnet like application many systems can be configured so that they accept each others system ids. By entering the host name and the user id, users can then access any other computer in that system pool without having to use the password. The rsh application even bypass the login procedure altogether and executes commands directly on the target system.

                Once the input has been successfully made the only criteria that have to be satisfied before an r command will be executed are:

1.       The call must be made from a privileged port.

2.       The user and system must be entered in the hosts.equiv file or in the users. rhosts file.

3.       The user name and internet address must match.

 

3.1.13 The DNS service and DNS Attacks

Another application that can also be used as a launch pad for hackers is the domain name server or DNS. This service is used to allocate numerical Internet address to domain names.

The domain name area that applies to an organization is called a zone. To keep domain names usable, all Internet subnets are obliged to use a domain name server. Each name server has the four so called databases:-

1         Forward Zone: The Forward Zone database allocates domain names to internet address

2         Reverse Zone: The Reverse Zone database allocates internet address to domain names

3         Local Hosts

4         Reverse Local Hosts

In most cases, DNS attacks are used in preparation for another attack using the remote services (rsh, rlogin, etc.).

If a hacker manages to modify the in-addr.arpa table for DNS concern, so that his own actual internet address is allocated to the name for the trusted host, he wishes to imitate, he can than attack the system using rlogin or rsh. This deceit can be discovered if the application-concerned checks the internet address in the other direction and also uses DNS to demand the allocated the domain name for numerical address given, as in the case with many current versions.

 

3.2 How Firewalls can stop these attacks

Firewalls can stop these kinds of attacks by enforcing security policies, in which packets going into and out of the internal network are monitored and scanned. A decision is made to allow or disallow an incoming or an outgoing packet as per its source or destination IP address, port or protocol used. In proxy server firewalls, content filtering is also possible, in which filtering can be done based on the data contained in the packet. For example, certain keywords can easily be filtered. Filtering out the specific types of packets that cause these attacks prevents specific types of attacks. While formulating the security policy of a network, care should be taken to ensure that normal harmless packets are unaffected.

 

 

3.3 Introduction to Secure Shell (SSH)

SSH (Secure Shell) is used to securely run commands on remote machines, along with many other applications. The primary advantage of using SSH is that all data, including passwords, are sent encrypted between the two machines, as opposed to utilities like rlogin and telnet. This enhances security and data integrity.

In SSH, authentication is done using Public key cryptography. A public and a private key is generated for a particular user, who is identified using them.

The ssh command can also be used to run commands on remote systems without logging in. The output of the command is displayed and control returns to the local system. The format for running a command on a remote host is given as:

% ssh username@hostname  commandname

 

3.4 Introduction to virtual Private Networks (VPNs)

A Virtual Private Network (VPN) allows two private networks to be  connected over a publicly-accessible network. A Virtual Private Network (VPN) allows two private networks to be connected over a publicly accessible network.

The main features of VPNs are:

·          The VPN creates a tunnel between routers on two different networks

·          Data is usually sent encrypted over the tunnel

·          This is necessary for proper encryption and security

·          The two main headers encapsulating a packet are:

1.       AH           Authentication Header

2.       ESP        Encapsulated Security Payload

 

|20 bytes of IP header| |AH information| |ESP payload|

or

|20 bytes of IP header| |ESP payload|

 

 

Chapter 4

THE OPENBSD OPERATING SYSTEM

 

4.1 Introduction

OpenBSD  is a Unix-like security oriented operating system, developed in Canada by a group of developers. BSD stands for Berkeley software distribution. OpenBSD looks and feels like many other Unix-like OS’ es , and belong to the family of OS’es evolved from the 4.3 BSD Operating system originally developed at the University of California, Berkeley.

OpenBSD is a freely-downloadable Operating System under the GNU GPL. It has been claimed to be secure by default, which means that its default settings are aimed at making a network secure, unlike other Operating Systems such as Linux. OpenBSD 3.0 is the latest version, having improved OpenSSH support, cryptography and other features.

OpenBSD is so security oriented that it has been claimed to be the world’s most secure Operating System. It was developed as a result of a three- year security audit. The OpenBSD security auditing team typically has between six and twelve members who continue to search for and fix new security holes. The process followed in OpenBSD to increase security is simply a comprehensive file-by-file analysis of every critical software component.

 
4.2 Security mechanisms incorporated in OpenBSD

1.       OpenSSL

2.       Kerberos

3.       Cryptography

·          An important aspect of security in a modern operating system is cryptographic services and mechanisms. While not a security panacea, cryptography is sometimes the right tool in solving certain problems. In particular, cryptography is extremely useful in solving a number of security issues in the following three areas:

1.       Network security.

2.       Secure storage facilities.

3.       (Pseudo-) Random number generators.

4.       IP Security (IPSec)

 

4.3 Steps for the installation  and post install configuration of OpenBSD

Download OpenBSD from one of the ftp or http sites on a Windows(FAT32) or Linux(ext2) partition

We downloaded it from:

·          http://the.wiretapped.net/OpenBSD/2.9/i386

·          ftp://ftp.openbsd.org/pub/OpenBSD

The list of sites to download it from is available in :

http://www.openbsd.org/ftp.html

Version downloaded:        OpenBSD 2.9

Latest version:                    OpenBSD 3.0

OpenBSD 3.0 supports pf (packet filter) instead of ipf. so we have used version 2.9 only.

The main files to be downloaded are:

·          The Base files(necessary binaries)                base29.tgz

·          The BSD Kernel                                   bsd

bsd.rd

·          The C Compiler                                   comp29.tgz

·          The files of the etc directory               etc29.tgz

·          The various man pages                     man29.tgz

The boot floppy images are

·          floppy29.fs

·          floppyB29.fs

·          floppyC29.fs

The CDROM image file is available in:

·          cdrom29.fs

Make the OpenBSD Boot Floppy or CD by downloading the image file (floppy29.fs) and writing to a floppy using dd(linux), rawrite(dos) or rawwritewin(Windows)

Rawwritewin is an utility to write a raw binary image to a floppy,

It can be downloaded from:

                http://uranus.it.swin.edu.au/~jn/linux/rawwrite.htm

Boot from the Floppy.

Make an OpenBSD partition on the Hard Disk using fdisk.

OpenBSD filesystem is ffs(fast file system) with code A6

 

4.3.1 Installation instructions

·          After booting from the floppy, follow the instructions and give the appropriate responses. The openbsd installer remembers the previous responses, thus making it much easier to perform the installation.

·          First of all, select an appropriate partition on the hard disk

·          Use disklabel to make the / and swap partitions within the OpenBSD partition

·          Configure network card giving IP address

·          Install the base files via ftp or cdrom or from another hard disk partition

The following files are essential:

1.             base29.tgz            The base binary file distributions

2.             comp29.tgz           The C compiler

3.             bsd                         The bsd kernel

4.             etc29.tgz                Various other utilities

Download and configure a boot manager like OS-BS, Ranish or GAG to enable multiboot of OpenBSD with Dos or Windows partitions

4.3.2 X Configuration

·          Run /usr/X11/bin/XF86Setup and configure X as per the hardware configuration

·          Otherwise run xf86config3 or xf86config and do the settings

·          Else edit the file /etc/X11/config/XF86Config manually

·          Run startx to see if the configuration works correctly.

4.3.3 Installing packages

·          Tar the package .tgz file using tar xvzf

·          cd to the /usr/share/packages directory and run pkg_add <package_name>

4.3.4 Recompiling the kernel

Download the kernel source file srcsys.tar.gz

cd to the /usr/src/sys directory. Make one if not present. Tar it using tar -xvzf

run make all and configure <config_file> to recompile the /bsd kernel

 

4.4 OpenBSD network setup

 

·          The installer detects the network interfaces at install time and configures the necessary setting like hostname, IP address ,etc.

·          The following command enables checking of the status of the interface:

·          ifconfig rl0 (where rl0 is the interface)

·          The following files contain important information regarding network configuration and can be edited to change the parameters:

o               /etc/hosts,  /etc/myname        Hostname

o               /etc/mygate                               Default Gateway

o               /etc/hostname.rl0                    Network Interface Configuration

 

4.5 Setup of SSH in OpenBSD

SSH or secure shell is used for securely logging into and running commands on remote machines. SSL (Secure socket Layer) is the technology used for secure web traffic through the internet.  OpenBSD supports OpenSource implementations of both SSH and SSL, called OpenSSH and OpenSSL respectively

Configuration file for SSH is                                                            ~/.ssh/ssh_config

The configuration of the SSH daemon is defined in                  ~/.ssh/sshd_config

 

4.5.1 Public key cryptography

The various files used are:

·          Public key                                                                              ~/.ssh/identity.

·          Public Keys Installed in                                                      ~/.ssh/authorized_keys

·          Encrypted contents of Private Key                                    ~/.ssh/identity

 

4.5.2 Creating your authentication key

·          Command Used: ssh_keygen

·          Pass Phrase to be given

·          All Pass Phrases and data sent encrypted over the net, unlike in Telnet

·          Public keys used for encryption and private keys for decryption

Other SSH utilities are:

slogin:                                    For secure login

scp:                                        for secure copy

 

4.5.3 SSH-agent

If you frequently open connections to remote systems you can run your session under the ssh-agent. The agent will provide decrypted authentication keys to all the commands when new connections are created.

Ssh-add                command is used to add the keys in memory

4.5.4 Running commands on remote systems

The ssh command can also be used to run commands on remote systems without logging in. The output of the command is displayed and control returns to the local system.

beowulf% ssh hrothgar who

beowulf% scp -p hrothgar:aliases .

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Chapter 5

THE OPENBSD IMPLEMENTATION OF FIREWALLS

 

 

5.1 Introduction To IPFilter

IPFilter is a software package that can be used to provide network address translation (NAT) or firewall services. To use, it can either be used as a loadable kernel module or incorporated into your UNIX kernel; use as a loadable kernel module where possible is highly recommended. Scripts are provided to install and patch system files, as required.

IP Filter is a suite of programs including ipnat, ipf, ipmon,etc. Darren Reed is the author of IP Filter. IPFilter was previously distributed as part of the default OpenBSD distribution up to version 2.9. But due to licensing problems it has stopped being shipped with the default OS and has to be loaded separately.

A Diagram illustrating the flow of TCP/IP packets through the various stages introduced by IP Filter is given below.

An explanation of the various terms in the diagram is as follows:

5.1.1 Network Address Translation (NAT):

·          output packets going through the NAT will have their source IP address changed, if a mapping rule and space in the table exists, prior to being forwarded.

·          input packets going through the NAT will have their destination IP address changed, if it can be found in the table, to the original value.

5.1.2 IP Accounting:

·          input and output rules can be separately setup, recording the number of bytes that pass through. Each time a rule match occurs, the byte count of the packet is added to the rule (allowing for cascading statistics to be collected).

5.1.3 Firewall check:

·          input and output rules can be separately setup, determining whether or not a packet will be allowed through IPFilter, into the kernel's TCP/IP routines or out onto the network.

5.1.4 IP Authentication:

·          packets which are authenticated are only passed through the firewall loops once to prevent double- processing.

 

 

 

 

 

 

                                   IN

                                    |

                                    V

          +-------------------------+--------------------------+

          |                         |                          |

          |                         V                          |

          |            Network Address Translation             |

          |                         |                          |

          |         authenticated   |                          |

          |       +-------<---------+                          |

          |       |                 |                          |

          |       |                 V                          |

          |       V           IP Accounting                    |

          |       |                 |                          |

          |       |                 V                          |

          |       |        Fragment Cache Check--+             |

          |       |                 |            |             |

          |       V                 V            V             |

          |       |         Packet State Check-->+             |

          |       |                 |            |             |

          |       |       +->--+    |            |             |

          |       |       |    |    V            |             |

          |       V   groups   Firewall check    V             |

          |       |       |    |    |            |             |

          |       |       +--<-+    |            |             |

          |       |                 |            |             |

          |       +---------------->|<-----------+             |

          |                         |                          |

          |                         V                          |

          |                +---<----+                          |

          |                |        |                          |

          |            function     |                          |

          |                |        V                          |

          |                +--->----+                          |

          |                         |                          |

          |                         V                          |

       +--|---<--- fast-route ---<--+                          |

       |  |                         |                          |

       |  |                         V                          |

       |  +-------------------------+--------------------------+

       |                            |

       |                        pass only

       |                            |

       |                            V

       V               [KERNEL TCP/IP Processing]

       |                            |

       |  +-------------------------+--------------------------+

       |  |                         |                          |

       |  |                         V                          |

       |  |                Fragment Cache Check--+             |

       |  |                         |            |             |

       |  |                         V            V             |

       |  |                 Packet State Check-->+             |

       |  |                         |            |             |

       |  |                         V            |             |

       V  |                    Firewall Check    |             |

       |  |                         |            V             |

       |  |                         |<-----------+             |

       |  |                         V                          |

       |  |                   IP Accounting                    |

       |  |                         |                          |

       |  |                         V                          |

       |  |            Network Address Translation             |

       |  |                         |                          |

       |  |                         V                          |

       |  +-------------------------+--------------------------+

       |                            |

       |                        pass only

       V                            |

       +--------------------------->|

                                    V

                                   OUT

Diagram illustrating the flow of TCP/IP packets through the various stages introduced by IP Filter.

 

5.2 The OpenBSD Firewall implementation: Working of a Firewall in OpenBSD

The firewall rules to be implemented are stored in /etc/ipf.rules.

The ipf rules  for an interface fall into basically two classes:

·          The in rules

·          The out rules.

FOR OUTGOING PACKETS

FOR INCOMING PACKETS

The in rules for an interface define the rules governing a packet that goes into an interface. The out rules govern a packet that goes out of any interface. Whether the packet originates or is destined to the internal network or the external network is immaterial. It is very important or note that the rules are for a interface and not for a network.

When a packet comes to an interface, first the “in” rules for the packet are implemented and then the “out” rules for the packet.

 

5.2 OpenBSD Firewall Configuration Steps

·          Edit /etc/rc.conf so that ipf and ipnat are turned ON.

·          Recompile the kernel with options of IPFILTER and IPFILTER_LOG set

·          Edit /etc/ipf.rules  and make the necessary changes needed

Adding Rules

The most common method for adding rules to the kernel's ruleset is via a script file. This file is usually "/etc/ipf.rules". The ipf program will read in the script file whenever the machine boots. Additionally, the following command can be used to flush all of the rules and re-read the contents of the script file:

ipf –Fa –vf /etc/ipf.rules –E

The '-F' flag flushes all rules from the kernel and the 'a' says to flush the active ruleset.. ‘-E’ option enables the rules.

 

5.3 Configuration of NAT and portmapping

·          In IPFilter, NAT rules are stored separately from IPF rules. The NAT rules are read from a file called "/etc/ipnat.rules". Likewise, the NAT rules are injected into the kernel using a different tool.

·          The following line will activate the NAT rules specified in the /etc/ipnat.rules file:    

ipnat -f /etc/ipnat.rules

·          Add "net.inet.ip.forwarding=1" to the file "/etc/sysctl.conf".

·          Edit /etc/ipnat.rules  and make the necessary rule changes

·          In the end, add the rules by running

ipnat -CF –f  /etc/ipnat.rules

This would flush the current rules and substitute them with the new rules from the file /etc/ipnat.rules.

5.4 Setup of a VPN in OpenBSD              

 

5.4.1 ISAKMP

               ISAKMP (or IKE) is the key exchange mechanism for a VPN ISAKMP manages the exchange of cryptographic keys that you would normally have to manually manage with ipsecadm(8). It employs a two-phase process for establishing the IPsec connection between two gateways.

   

5.4.2 Setting Up The VPN

                The following settings in /etc/sysctl.conf will enable ESP, IPsec access control lists, and IP Forwarding. Note that enabling AH is not necessary in this case because it is not used.

·          net.inet.ip.forwarding=1

·          net.inet.esp.enable=1

·          net.inet.ip.ipsec-acl=1

If transforms that have AH mentioned are being used, then AH should be enabled by adding

        net.inet.ah.enable=1.

 AH is not required and does not encrypt the payload data; it simply provides for a better authentication for each packet.

 

5.4.3 Manual VPN Configuration

The steps are as follows:

·          You will need to define two Security Associations (SA's) on each end of the VPN.

·          The IPSEC routes use the SPIs configured within the SA to determine where to send the IPSEC traffic, and what encryption and authentication schemes to use. The flow command creates a flow that determines which packets are routed via which SA.

·          Set the IPF rules to allow packets of esp Protocol

 

 

5.4.4 Isakmpd Configuration

The default key exchange policy are setup according to the files:

             /etc/isakmpd.policy

of the gateway concerned.

5.4.5 Starting the VPN

The first time that this daemon is run, execute the command          $ isakmpd -d -DA=99

The daemon will not be running in daemon mode but as a regular process. It will log everything to console (stdout and stderror ).

5.4.6 Final Setup of the VPN

If all has worked well, edit the /etc/rc.conf file to have isakmpd=YES. This will bring up the VPN whenever OpenBSD is rebooted.

 

5.5 Domain Name Service

 

5.5.1 Introduction to Domain name Service (DNS)

           

Domain Name Service is a network facility allowing IP network domains to provide name-to-IP address resolution and IP address-to-name resolution in response to a query.

5.5.2 Need For Domain Name Service

1.       If we have an IP LAN on which we do not wish to replicate "hosts" files of local addresses machine by machine. In such a case, we may use our OpenBSD machine as a DNS server and serve queries from the other machines on our LAN.

2.       If we have an IP LAN on which reside machines we will wish to be findable via DNS query by machines on another IP LAN or WAN.

 

5.5.3 Software Components Of the DNS Server

·          named ("name daemon"): OpenBSD uses BIND Version 4

·          Configuration files in the directory hierarchy under /var/named/.

 

5.5.4 Setting Up Of the DNS in OpenBSD

1.       Initially set the domain name in the configuration file /etc/resolv.conf so that name resolution requests actually get sent to the named set  by us.

domain mnrec.ac.in

lookup file bind

2.       Appropriately setup the Server in the /etc/hosts file

# Host addresses

127.0.0.1               localhost               localhost.localdomain

172.31.52.6          ganesh                 ganesh.mnrec.ac.in

3.       Setting up of the “named” daemon

The name daemon named is launched during system startup from /etc/rc if the line installed by default in /etc/rc.conf.

named_flags=NO                # for normal use: “”

is changed to

named_flags=””                    # for normal use: “”

4.       Also, examine these lines in /etc/rc.conf:

named_user=named                         # Named should not run as root unless necessary

named_chroot=/var/named               # Where to chroot named if not empty

These defaults will be correct for nearly all setups.

5.       To start named by hand, use the ndc command. For example:

$ ndc start

or

$ ndc restart

6.       Stopping DNS

The best way to stop the name daemon is to use the ndc command. For example:

# ndc stop

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Chapter 6

THE MNREC NETWORK STRUCTURE AND THE FIREWALL

 

6.1 MNREC Network setup

The OpenBSD router, which connects the internal (172.31.0.0) network with the outside world, has two interfaces:

·          fxp0 : the external interface having address of 210.212.49.13

·          rl0: : the internal interface having address of 172.31.52.9

The college is connected to the internet through the Cisco router (address 210.212.49.1), which connects to the VSNL lines from Allahabad.

The OpenBSD router acts as a DNS client and resolves the DNS queries by referring them to the DNS server ganesh.mnrec.ac.in at address 172.31.52.6.

The routing table of the OpenBSD router is modified as follows:

·          By default, all packets are forwarded through the fxp0 interface

route add 0.0.0.0 210.212.49.13

·          All packets destined for the 172.31.0.0 (internal) network should pass through the rl0 interface:   

route add 172.31.0.0 172.31.52.9

·          All packets destined for the 210.212.49.0 (external) network should pass through the fxp0 interface            

route add 210.212.49.0 210.212.49.13

The router also has

·          IP Forwarding enabled in /etc/sysctl.conf

·          IPNAT and IPF enabled in /etc/rc.conf

·          An active firewall with rules specified in /etc/ipf.rules

·          An active NAT with rules specified in /etc/ipnat.rules

 

6.2 Explanation of NAT rules on OpenBSD

 

The ipnat rules file (/etc/ipnat.rules) describes rules for network address translation (IP masquerading), port mapping both forward and reverse and redirection.

IPNAT mappings are defined by using the keyword “map“ which is used to  change the source IP address of a packet being forwarded from the internal network to the external. IPNAT maintains a NAT table through which it keeps track of the packet when it returns from the server in the outside world.

The keyword “rdr” is used for redirection of packets in the case when an internal server (mail, telnet, http, ftp ,etc) is running in the internal network having an internal (172.31) address and an external host wants to access the service provided by it. It changes the destination IP address of the packet.

An explanation of the ipnat rules files for the MNREC OpenBSD router is as follows:

·          The following mapping will provide the internal network with Internet connectivity for tcp/udp traffic

map fxp0 172.31.0.0/16 -> 210.212.49.13/32 portmap tcp/udp 10000:20000

map fxp0 172.31.0.0/16 -> 210.212.49.13/32

·          The first line would map (ie change the source address of) all packets coming at fxp0 (the external interface) from any machine in the internal(172.31) network to 210.212.49.13 (which is the IP address of the fxp0 interface and is a valid IP address given by VSNL). TCP or UDP packets would be mapped to ports in the range of 10000 to 20000 while all other packets would be mapped to any random port number.

·          For redirection (through rdr command) of input packets, a separate rdr instruction is to be given for each of the servers needed.

·          The various servers are:

FTP server                            port 21                   ganga.mnrec.ernet.in         172.31.50.9

UPMCAT http server          port 80                   upmcat.mnrec.ac.in            172.31.160.30     

Mail (SMTP) server            port 25                   ganga.mnrec.ac.in              172.31.50.9

·          Requests to these servers come at the external fxp0 interface of the firewall at 210.212.49.13.

·          The rules are such that any requests coming to the local ftp port would be redirected to the FTP server at ganga, forcing all users to connect through it. Same is with the other servers.

rdr fxp0 0.0.0.0/0 port 21 -> 172.31.50.9 port 21

rdr fxp0 0.0.0.0/0 port 2000 -> 172.31.160.30 port 80 tcpudp

rdr fxp0 0.0.0.0/0 port 3000 -> 172.31.50.9 port 25

·          The second of the rules states that any external requests coming to the external interface fxp0 at port number 2000 should be redirected to the port 80 (http) of the UPMCAT server at 172.21.160.30. The number 2000 is chosen arbitrarily and has no special significance.

·          In the main site web page (www.mnrec.ac.in) referring the UPMCAT server, a corresponding link has to be made in order to redirect the request to the firewall instead of the proxy i.e. a link to http://210.212.49.13:2000

·          The third rule is similar to the second. The requests coming at the fxp0 interface of the router at port 3000 are to be redirected to ganga.mnrec.cc.net , the SMTP server at 172.31.50.9 at port 25. Here too a corresponding link to http://210.212.49.13:3000 has to be made in the html page on the website referring the mail server

 

6.3 Firewall policy

The firewall implemented follows a “default to deny” policy. This means that any packets not explicitly allowed are blocked. Although this is the safest way to secure any network, it is tedious to open the corresponding port each time a new service is to be allowed.

 

6.4 Ports to allow

Port numbers and the corresponding services allowed for the firewall are as follows:

Service                                  TCP Port Number               UDP Port Number

SSH                                        22

LDAP                                      389                                         389

Netmeeting                           >=1024                                  >=1024                  Videoconferencing

                                                1503

HTTPS                                   443                                                                                         SSL

Quicktime 4                          RTSP                                     RTP                        Steaming Video

MSN Messenger                  1863                                      

Squid                                     3128                                       3130                       Web proxy cache

Mirabilis ICQ                         >=1024                                  4000      

Yahoo voice chat                 5000-5001                            5000-5010

Yahoo messenger              5050                                                                       Messages

Yahoo messenger              5100                                                                       Webcams

VNC                                        5800+,5900+                                       

Common IRC                       6665-6669                                                            Internet Relay Chat

Real Audio                            RTSP,7070                           6970-7170            Steaming audio and video

RTP                                         6970-6999                                                           RealTime Transport

                                                                                                                                Protocol (Apple QT4)

MSN Gaming Zone             28800-29000                       28800-29000

DirectX gaming                    47624

6.5 Working of the Firewall and NAT on a packet                        

When a packet reaches a particular interface, first of all NAT mapping is done on that packet, if any such NAT mappings are defined for that interface. Then IPF rules are implemented.

WORKING OF IPNAT AND IPF ON AN OUTGOING PACKET

 

6.6 Test Setup

Test network setup is as follows:

·          Internal Host at 172.31.62.37 with default gateway set to 172.31.52.9 and DNS server set to 172.31.52.6

·          Web Server on the internal Lan at 172.31.160.30

·          OpenBSD Router in the middle having the following two interfaces:

rl0                   On the internal network having IP 172.31.52.9

fxp0                 On the external network having IP 210.212.49.13

·          External Web Server www.rediff.com at address 64.41.191.70

·          The internal host (172.31.62.37) sends a request to the web server for the default page through its web browser. Since its default gateway is set to the rl0 interface (172.31.52.9) of the OpenBSD router  the request comes to the router. NAT and portmapping is done on the packet and the IP address of the requesting machine is mapped to the address 210.212.49.13 with the port range within 10000-20000 as specified in the ipnat.rules file.

·          The packet is checked by the firewall and matched against the rules specified in ipf.rules file to decide whether or not to forward it.

·          In the end, it is forwarded to it’s the fxp0 interface of the router as per the settings its routing table

·          The request from the translated address 210.212.49.13 arrives at the web server which then sends back the requested index page index.html back to the router at the port at which it was mapped to

·          The address is translated back to the original address in the internal 172.31.0.0 network and the page www.rediff.com/index.html is forwarded back to the rl0 interface from the fxp0 interface after again checking against firewall rules

·          Finally the requested page arrives at the original machine 172.31.62.37 which is displayed by the browser

The status of the commands is as follows:

·          netstat –rn or route show for the internal host shows the default gateway as 172.31.52.9

·          The status of the NAT rules file is shown by ipnat –l and shows the active mapping:

# ipnat -l

List of active MAP/Redirect filters:

map fxp0 172.31.0.0/16  -> 210.212.49.13/32  portmap tcp/udp 10000:20000

map fxp0 172.31.0.0/16  -> 210.212.49.13/32

rdr fxp0 0.0.0.0/0 port 21 -> 172.31.50.9 port 21 tcp

rdr fxp0 0.0.0.0/0 port 2000 -> 172.31.160.30 port 80 tcp

rdr fxp0 0.0.0.0/0 port 3000 -> 172.31.50.9 port 25 tcp

List of active sessions:

MAP 172.31.62.37  1391  <- -> 210.212.49.13   10159 [64.41.191.70 80]

·          The ping command gives the following status

# ping www.rediff.com

PING www.rediff.com (64.41.191.70): 56 data bytes

--- www.rediff.com ping statistics ---

24 packets transmitted, 0 packets received, 100% packet loss

which is because www.rediff.com does not answer the ping command.

·          The nslookup command gives the following output:

# nslookup www.rediff.com

Server:  ganesh.mnrec.ac.in

Address:  210.212.49.14

        Non-authoritative answer:

Name:    www.rediff.com

Address:  64.41.191.70

 

Testing of Redirection is done as follows:

·          From an external PC (outside the MNREC network) from a cybercafe, the following site is browsed:

        http://210.212.49.13:2000

·          The UPMCAT server at 172.31.160.30 has its default gateway set to 172.31.52.9 and DNS to 172.31.52.6

·          ipnat –l gives the following output:

        RDR 172.31.160.30    80    <- -> 210.212.49.13   2000  [210.131.31.14 38171]

        where 210.31.31.14 is the address of the Cybercafe machine

Thus all tests are successful.

 

 

 

 

 

 

 

 

 

Chapter 7

CONCLUSION AND FUTURE DIRECTIONS

 

Thus we have successfully installed OpenBSD and implemented the Firewall policy on the router. we have also enabled NAT and port mapping as well as redirection. We have implemented SSH on the router and secured the college network. Thus we have successfully completed the objectives of the project and implemented an operational firewall.

The firewall that we have implemented at present cannot do content filtering as it is a packet filter at the network level. To enable content filtering and enhanced functionality, we can implement a proxy server firewall on top of the firewall we have already implemented. The proxy server would be coded in C and use the Unix socket programming interface. Together the proxy server and the packet filter would ensure protection and security for the network.

We can also see and modify the OpenBSD code to make it more secure. There is a need of writing an OpenBSD driver for IBM RAID. We can also make the control of the firewall easier by writing a Graphical User Interface and other utilities to enable proper monitoring and control. We can implement our own encryption algorithms for internal network data transfer.

Thus the firewall combined with encryption and other measures would enable the network to be secure from all types of attacks.

 

 

 

 

 

 

 

 

 

Chapter 8

REFERENCES AND BIBLIOGRAPHY

 

(i)OpenBSD 2.9 for the Intel platform downloaded from the internet via ftp

·          Ftp site:                  ftp://ftp.openbsd.org/pub/OpenBSD/2.9/i386/

·          Http site:                                http://the.wiretapped.net/pub/OpenBSD/2.9/i386/

 

(ii)OpenBSD Documentation Downloaded from the following sites:

·          www.openbsd.org

·          www.bsdtoday.com

·          www.daemonnews.org

·          www.securityportal.com

·          www.monkey.org

·          www.onlamp.com

·          www.perfectisolation.org

·          www.openlysecure.org

·          O Reilley Network                www.oreillynet.com

 

 (iii)Books on Firewalls and security issues studied:

·          Linux Firewalls by Robert L Ziegler (Techmedia)

·          Building Internet Firewalls by D. Brent Chapman & Elizabeth D. Zwicky (O’Reilly and Associates)

·          Building Linux and OpenBSD Firewalls by Wes Sonnenreich and Tom Yates (O’Reilly and Associates)

·          Maximum Linux Security by Anonymous (BPB Techmedia)

 

(iv)Previous project reports studied:

·          Firewall Design and Implementation (1999-2000)

·          Design and implementation of a TCP/IP internet Firewall (1997-98)

·          Design of an firewall using proxy server (1998-99)

 

 (v) OpenBSD mailing lists and forums attended:

·          The Official Mailing list: Send mail to [email protected] with the body of the message as subscribe <mailing-list>

·          Tech-tips forums for OpenBSD server (www.tek-tips.com/grelated.cfm/lev2/3/lev3/20/pid/744)

·          OpenBSD news and forums (unix.about.com/cs/openbsdnews/)

·          BSD Vault (http://bsdvault.net/viewforum.php?forum=7)

·          freebsdforums.org (http://www.freebsdforums.org/forums/forumdisplay.php?s=&forumid=23)

 

(vi) Other helpful links

·          IPFilter home page (www.ipfilter.org or http://coombs.anu.edu.au/~avalon/)

·          SSH home page (www.openssh.com)

·          SSL home page (www.openssl.org)

·          Official openbsd faq (www.openbsd.org/fq.html)

·          OpenBSD man pages (www.openbsd.org/cgi-bin/man.cgi)

·          ipf-howto: the world renowed document and most authoritative reference on ipfilter

(http://www.obfuscation.org/ipf/ipf-howto.txt)

 

(vii)Internet RFCs (www.ietf.org/rfc/ and www.faqs.org/rfcs )

rfc2685 - Virtual Private Networks Identifier

rfc2663 - IP Network Address Translator (NAT) Terminology and Considerations

rfc2647 - Benchmarking Terminology for Firewall Performance

 

APPENDIX 1. CONFIGURATION FILES

 

/etc/ipnat.rules

 

map fxp0 172.31.0.0/16 -> 210.212.49.13/32 portmap tcp/udp 10000:20000

map fxp0 172.31.0.0/16 -> 210.212.49.13/32

rdr fxp0 0.0.0.0/0 port 21 -> 172.31.50.9 port 21

rdr fxp0 0.0.0.0/0 port 2000 -> 172.31.160.30 port 80 tcpudp

rdr fxp0 0.0.0.0/0 port 3000 -> 172.31.50.9 port 25

 

/etc/ipf.rules

 

HEAVY FIREWALL with DEFAULT ALLOW-ALL POLICY

pass out from any to any

pass in from any to any

block in log quick on fxp0 proto icmp from any to any icmp-type redir

block in log quick on fxp0 proto tcp/udp all with short

block in log quick on fxp0 from any to any with ipopts

block in log quick on fxp0 from 192.168.4.0/24 to any

block in log quick on fxp0 from localhost to any

block in log quick on fxp0 from 0.0.0.0/32 to any

block in log quick on fxp0 from 255.255.255.255/32 to any

block in on fxp0 proto udp from any to any

block in log on fxp0 proto udp from any to any port = sunrpc

block in log on fxp0 proto udp from any to any port = 2049

pass in on fxp0 proto udp from any to any port = domain

pass in on fxp0 proto udp from any to any port = talk

pass in on fxp0 proto udp from any to any port = ntalk

block return-rst in log on fxp0 proto tcp from any to any flags S/SA

block return-rst in on fxp0 proto tcp from any to any port = auth flags S/SA

pass in on fxp0 proto tcp from any to any port 1024 >< 5000

pass in on fxp0 proto tcp/udp from any to  172.31.50.9 port = 25

pass in on fxp0 proto tcp/udp from any to 172.31.160.30 port = 80

pass in on fxp0 proto tcp/udp from any to 172.31.50.9 port = 21

pass in on fxp0 proto tcp from any to 172.31.52.9 port = ssh

 

 

FAIRLY HEAVY FIREWALL WITH DEFAULT DENY-ALL POLICY

#

#  This is a fairly heavy firewall used to keep everyone  out of the MNREC internal network while #  still allowing people within the  network to get outside.

#  Pass any packets not explicitly mentioned by subsequent rules

#

pass out from any to any

block in from any to any

#

#  Block any inherently bad packets coming in from the outside world.  These include ICMP

#  redirect packets, IP fragments so short the filtering rules won't be able to examine the whole

#  UDP/TCP header,and anything with IP options.

#

block in log quick on fxp0 proto icmp from any to any icmp-type redir

block in log quick on fxp0 proto tcp/udp all with short

block in log quick on fxp0 from any to any with ipopts

#

#  Block any IP spoofing attempts.

#

block in log quick on fxp0 from 172.31.0.0/24 to any

block in log quick on fxp0 from localhost to any

block in log quick on fxp0 from 0.0.0.0/32 to any

block in log quick on fxp0 from 255.255.255.255/32 to any

#

#  Block all incoming UDP traffic except talk and DNS traffic.  NFS and portmap are special-cased #  and logged.

#

block in on fxp0 proto udp from any to any

block in log on fxp0 proto udp from any to any port = sunrpc

block in log on fxp0 proto udp from any to any port = 2049

pass in on fxp0 proto udp from any to any port = domain

pass in on fxp0 proto udp from any to any port = talk

pass in on fxp0 proto udp from any to any port = ntalk

#

#  Block all incoming TCP traffic connections to known services, returning a connection reset so

#  things like ident don't take forever timing out.

#

block return-rst in log on fxp0 proto tcp from any to any flags S/SA

block return-rst in on fxp0 proto tcp from any to any port = auth flags S/SA

#

#  Allow incoming TCP connections to ports between 1024 and 5000, as  these don't have

#  daemons listening but are used by outgoing  services like ftp and talk. The range from 1024 to

#  8000 includes the usage of ports for yahoo messenger , MSN messenger, voice chat, net to

#  phone, ICQ, VNC, Real Audio, Netmeeting, etc

pass in on fxp0 proto tcp/udp from any to any port 1024 >< 8000

pass in on fxp0 proto tcp/udp from any port = ftp-data to any port 1024 >< 6000

#  port 443 is for HTTPS (SSL)

pass in on fxp0 proto tcp/udp from any to any port 443

#  below is for MSN Gaming Zone

pass in on fxp0 proto tcp/udp from any to any port 28800 >< 29000

#  The following rule is for DirectX Gaming

pass in on fxp0 proto tcp/udp from any to any port 47624

#

#  Now it is to be remembered that for EVERY new service to be enabled in the MNREC network,

#  a seperate new rule would have to be written. Also it is possible that some other important

#  applications exist that use a different range of ports from those mentioned above. New rules

#  would have to be added as and when necessary

#  Now allow various incoming TCP connections to particular hosts, SMTP to the mail host

#  ganga.mnrec.ac.in, www to the UPMCAT web server and ssh to the  OpenBSD firewall

#  gateway itself that can be used to gain access to the protected network from the outside world.

#  NAT COMES BEFORE IPF, so the addresses would have been mapped already

#

# for the mail server at ganga

pass in on fxp0 proto tcp/udp from any to  172.31.50.9 port = 25

# for the UPMCAT http server

pass in on fxp0 proto tcp/udp from any to 172.31.160.30 port = 80

# for the ganga ftp server

pass in on fxp0 proto tcp/udp from any to 172.31.50.9 port = 21

# for enabling ssh at the OpenBSD gateway itself

pass in on fxp0 proto tcp from any to 172.31.52.9 port = ssh

 

 

/etc/ssh_config

 

   ForwardX11 no

   FallBackToRsh no

   UseRsh no

   IdentityFile ~/.ssh/identity

   Port 22

 

/etc/sshd_config

 

Port 22

HostKey /etc/ssh_host_key

HostKey /etc/ssh_host_rsa_key

HostKey /etc/ssh_host_dsa_key

ServerKeyBits 1664

LoginGraceTime 600

KeyRegenerationInterval 3600

PermitRootLogin no

IgnoreRhosts yes

StrictModes yes

X11Forwarding no

X11DisplayOffset 10

PrintMotd yes

KeepAlive yes

SyslogFacility AUTH

LogLevel INFO

RhostsAuthentication no

RhostsRSAAuthentication no

HostbasedAuthentication no

RSAAuthentication yes

PasswordAuthentication yes

PermitEmptyPasswords no

Subsystem        sftp       /usr/libexec/sftp-server

 

 

/etc/sysctl.conf

 

net.inet.ip.forwarding=1   # 1=Permit forwarding (routing) of packets

net.inet6.ip6.forwarding=1           # 1=Permit forwarding (routing) of packets

machdep.allowaperture=2                       # See xf86(4)

 

/etc/rc.conf

 

#!/bin/sh -

routed_flags=NO                        # for normal use: "-q"

mrouted_flags=NO         # for normal use: "", if activated

rarpd_flags=NO              # for normal use: "-a"

bootparamd_flags=NO    # for normal use: ""

rbootd_flags=NO                        # for normal use: ""

sshd_flags=""                # for normal use: ""

sendmail_flags="-q30m" # for normal use: "-bd -q30m"

smtpfwdd_flags=NO       # for normal use: "", and no "-bd" above.

named_flags=""             # for normal use: ""

rdate_flags=NO              # for normal use: name of RFC868 timeserver

timed_flags=NO             # for normal use: ""

ntpdate_flags=NO          # for normal use: NTP server; run before ntpd starts

photurisd_flags=NO        # for normal use: ""

isakmpd_flags=NO         # for normal use: ""

mopd_flags=NO             # for normal use: "-a"

httpd_flags=NO              # for normal use: "" (or "-DSSL" after reading ssl(8))

apmd_flags=NO             # for normal use: ""

dhcpd_flags=NO                        # for normal use: "-q"

rtadvd_flags=NO                        # for normal use: list of interfaces

                                    # be sure to set net.inet6.ip6.forwarding=1

route6d_flags=NO          # for normal use: ""

                                    # be sure to set net.inet6.ip6.forwarding=1

rtsold_flags=NO             # for normal use: interface

                                    # be sure to set net.inet6.ip6.forwarding=0

                                    # be sure to set net.inet6.ip6.accept_rtadv=1

ftpd_flags=NO                # for non-inetd use: "-D"

identd_flags=NO                        # for non-inetd use: "-b -u nobody -elo"

xdm_flags=NO               # for normal use: ""

# For enabling console mouse support (i386 architecture only)

moused_flags=NO                     # for ps/2 try: "-p /dev/psm0", serial: "-p /dev/cua00"

rwhod=NO

nfs_server=NO               # see sysctl.conf for nfs client configuration

lockd=NO

gated=NO

kerberos_server=NO       # kerberos server. run 'info kth-krb' for assistance.

kerberos_slave=NO        # kerberos slave server.

amd=NO

ipfilter=YES

ipnat=YES                    # for "YES" ipfilter must also be "YES"

portmap=YES                # almost always needed

inetd=YES                    # almost always needed

ntpd=YES                     # run ntpd if it exists

afs=NO                         # mount and run afs

# Multicast routing configuration

multicast_host=NO        # Route all multicast packets to a single interface

multicast_router=NO      # A multicast routing daemon will be run, e.g. mrouted

# miscellaneous other flags

gated_flags=

ypserv_flags=                            # E.g. -1 for YP v1, -d for DNS etc

yppasswdd_flags=                     # "-d /etc/yp" if passwd files are in /etc/yp

nfsd_flags="-tun 4"                     # Crank the 4 for a busy NFS fileserver

amd_dir=/tmp_mnt                     # AMD's mount directory

amd_master=/etc/amd/master    # AMD 'master' map

ipfilter_rules=/etc/ipf.rules           # Rules for IP packet filtering

ipnat_rules=/etc/ipnat.rules         # Rules for Network Address Translation

ipmon_flags=-Ds                                    # To disable logging, use ipmon_flags=NO

syslogd_flags=                          # add more flags, ie. "-u -a /chroot/dev/log"

named_user=named                   # Named should not run as root unless necessary

named_chroot=/var/named                      # Where to chroot named if not empty

afs_mount_point=/afs                 # Mountpoint for AFS

afs_device=/dev/xfs0                  # Device used by afsd

afsd_flags=-z                             # Flags passed to afsd

shlib_dirs=                                # extra directories for ldconfig

local_rcconf="/etc/rc.conf.local"

[ -f ${local_rcconf} ] && . ${local_rcconf}

 

 

/etc/resolv.conf

 

domain mnrec.ac.in mnrec.cc.net

search mnrec.ac.in mnrec.cc.net

nameserver 210.212.49.14

nameserver 172.31.52.6

 

hostname.fxp0

 

inet 210.212.49.13 255.255.255.240 NONE

 

hostname.rl0

 

inet 172.31.52.9 255.255.0.0 NONE

 

 

 

APPENDIX 2. SUMMARY OF IMPORTANT COMMANDS ON     OPENBSD

 

or dnsquery www.servername .com

For example: mount –t msdos /dev/fd0a /mnt/floppy

For CDROM the filesystem is iso9660

For example: tar –cvf sd0b /usr

Important files are:

 

APPENDIX 3: BOOT MANAGERS IN OPENBSD

 

GAG:  Graphical Boot manager:

GAG can boot upto 9 Operating Systems at the same time. GAG can be downloaded from: http://www.rastersoft.com/gageng.htm

To install GAG you need a floppy drive and create a boot floppy with GAG on it. The gagboot image is downloaded at the website. This boot image has to be written in raw form to a floppy using either fdisk for windows 98, dd (disk dump) for linux or rawritewin,which is the best, for windows 98/2000/xp (It can be downloaded from http://uranus.it.swin.edu.au/~jn/linux/rawwrite.htm)

Installation is well documented and a brief outline is listed:

·          Download the Image file from the Net

·          Extract the Files

·          Write the disk image using rawrite or ntrw, or from your unix box.

·          Boot from the floppy diskette

·          Set configuration using a nice easy to follow graphical system

rawrite is supplied with the image file and also available together with ntrw from the CD Distribution or ftp site.

The main features of GAG are:

·          Boot Manager allows setting a default OS, and startup timer.

·          Supports booting from separate drives (eg. HD1, HD2, Floppy)

·          Install after both OSs have been installed

·          Graphical installation and startup menu (nice beautiful touch)

·          Well documented

·          Tested with MS Windows FAT32 & OpenBSD 2.9

·          You don't need to keep looking for that DOS boot CD/floppy: The GAG floppy is bootable

 

Other Boot managers are:

·          mattsoft Boot Manager downloaded from http://www.penguin.cz/~mhi/mbtmgr

·          OS Boot Selector 2.0Beta8 downloaded from http://www.prz.tu-berlin.de/~wolf/os-bs.html

·          Partition Magic 5.0 Boot Magic

Useful information about various OpenBSD boot managers is available at:

http://www.nomoa.com/bsd/dualboot.htm

Hosted by www.Geocities.ws

1