
1) Introduction
Where are Firewalls needed and why?
2) Typical Architecture for Firewall Implementation
Single -Box Architecture
Screened Host Architecture
Screened Subnet Architecture
3) Types of Firewall Implementations
Firewall Technologies
Packet Filtering
Proxy Services
4) Security Strategies Implemented using Firewall
Default Permit
Default Deny
Least Privilege
Defence in Depth
Choke Point
5) Limitations of Firewall
6) Setting up a Packet Filter Firewall
Setting up an Internal Network
A Dual Host Configured using iproute2
Setting up Rules
Advanced Routing and Bandwidth Allocation using iproute2 and tc
7) Netfilter/IPtables
What are Netfilter/IPtables?
Packet Selection:IPtables
Packet Filtering
NAT
Packet Mangling
VPN
Connection Tracking
How a Rule is Built
8) Enabling Basic, Required Internet Services
Allowing DNS
Allowing the AUTH User Identification Services
9) Enabling Common TCP Services
10) Enabling Common UDP Services
11) Advanced Routing and Traffic Control
Introduction
Considering the popularity and the reach of the Internet into the personal and professional lives of people today, it becomes evident that, like real life, Privacy and Protection need to be taken care of in the cyber world, too.
Firewalls are part of the gamut of tools available to assist in achieving Internet Security for a Network.
What are Firewalls? (The Basics)
A Firewall is basically a protective device. When one connects to the Internet, there are three things that are put to risk
· Local Data
o Secrecy
o Integrity
o Availability to Self
· Computer Resources
· One’s Reputation
Firewall acts as a barrier between the internal network and the Internet so as to screen through only the information that is considered safe by the Network Administrator.
In theory, a Firewall serves multiple purposes
· It restricts entering into the Network at carefully controlled points
· It prevents attacks from getting close to interior defenses
· It restricts leaving the Network at carefully controlled points
Logically, a Firewall is a separator, restrictor and an analyzer.
Firewalls are one of the most indispensable components of the System for Security Conscious Users, Networks offering Services to a group of users or the World Wide Web, Corporations involved in e-commerce as well as Educational Institutions.
This is because any machine connected to the Internet is subject to several attacks. Some of them can be enumerated as
Intrusion: Penetrating into the Local System to utilize resources pretending to be a legitimate user.
Denial of Service: This class of attacks is aimed purely at disrupting the services offered by the machine so that the users of the service are unable to use it at all.
Information Theft: This type of attack deals with compromising the Secrecy of Data by simply acquiring a copy of the information serviced by a computer with the only difference that the information is handed over into the wrong hands.
Typical Architectures for Firewall Implementation
(1)Single-Box Architecture
These are the simplest Firewall Architectures and have a single object that acts as a Firewall. They’re easy to implement, test and maintain but do not offer defense in depth and hence are not very secure. All the security is concentrated at a single point. If that fails, the entire security framework collapses.
Screening Routers and Dual-Homed Hosts are classic examples of Single Box Architectures. These are low cost implementations of Firewalls on a network.

(2)Screened Host Architecture
Such an architecture comprises of a router configured to permit or deny traffic based on a set of permission rules installed by the administrator and a host on a network behind the screening router. The degree to which a screened host may be accessed depends on the screening rules in the router. The primary security is provided by packet filtering.

The most appropriate places to setup such architectures are:
· There are few connections to and from the Internet
· The Network being protected has a high level of host security
(3)Screened Subnet Architecture

This architecture comprises of a subnet behind a screening router. This adds an extra layer of security to the Screened host architecture that provides defense in depth. Breaking into the host doesn’t make the internal hosts completely vulnerable. The degree to which the subnet may be accessed depends on the screening rules in the router. This and multiple variants of this architecture are suitable for most uses.
A Firewall is usually installed at the point where the protected Internal Network connects to the Internet. Thus, it gets a chance to screen all the incoming and outgoing traffic thereby allowing only acceptable traffic to pass through and deal with other traffic as specified in the security policy.
The physical implementation of a Firewall is most often, a combination of a set of Hardware components (Routers) and appropriate software.
Packet Filtering (Network Layer) [given by Packet Filtering Routers]
A filtering firewall works at the network level. Data is only allowed to leave the system if the firewall rules allow it. As packets arrive they are filtered by their type, source address, destination address information contained in each packet .

Because very little data is analyzed and logged, filtering firewalls take less CPU and create less latency in your network.
Filtering firewalls do not provide for password controls. Users can’t identify themselves. The only identity a user has is the IP number assigned to their workstation.
Proxy Servers (Application Layer)
There are two types of proxy services.
1) Application Proxies -[Given by Application Level Gateways] that do the work for the application (user).
Proxies are mostly used to control, or monitor, outbound traffic. Some application proxies cache the requested data. This lowers bandwidth requirements and decreases the access time for the same data for the next user. It also gives unquestionable evidence of what was transferred as it is easy to log and audit all incoming traffic at the application level. Thus application-level gateways are more secure than packet filters.
Among the disadvantages is the additional processing overhead on each connection. In effect, there are two spliced connections between the end users, with the gateway at the splice point, and the gateway must examine and forward all traffic in both directions.

2) SOCKS Proxies -. [Given by Circuit Level Gateways] that cross wire ports to establish connections.
Socks is a generic proxy independent of a specific client/server protocol. This uses source IP address and destination IP address to decide on whether to make a connection to the internet or not. This level is between the packet filtering level and proxy level as far as security is concerned.The services provided here which are discussed later are:
1) NAT
2) Encrypted Authentication
3) Encrypted Tunnels
Security Strategies implemented using Firewalls
A firewall is able to screen out communication based on the policy defined by the
Network Administrator. There are two basic approaches that can be taken depending on the needs of the network.
Prohibit all communication that is not expressly permitted. This kind of stance makes sense from a security point of view and is an obvious choice for administrators
Default Permit
Permit all communication that is not explicitly prohibited. This stance is more appealing to users but is extremely risky and takes into consideration only things that the Network Administrator can predict beforehand to be capable of compromising the security of the network.
Besides these, there are several simple strategies that can be employed to enhance the security of the network using Firewalls:
Least Privilege
This involves designing operational aspects of a system to operate with a minimum amount of system privilege. This reduces the authorization level at which various actions are performed and decreases the chance that a process or user with high privileges may be caused to perform unauthorized activity resulting in a security breach.
Defense in Depth
It is a security approach whereby each system on the network is secured to the greatest possible degree. This approach is usually used in conjunction with firewalls.
Choke Point
A Choke Point forces attackers to use a narrow channel to penetrate the network allowing for easy monitoring and screening of traffic entering and leaving the network.
Limitations of Firewalls
Like all technologies, a firewall has its share of pros and cons. A few of the shortcomings that a network having a firewall at its gateway is subject to are:
· It can’t protect against malicious insiders
· It can’t protect against connections that don’t go through it
· It can’t protect against completely new threats
· It can’t fully protect against viruses
Firewalls encompass a variety of technologies...in fact; anything that is designed to protect an internal system from external threats is a Firewall.
Setting up a Packet Filter Firewall
The Firewall designed and implemented uses a Packet Filter (Network Layer) Technology and is implemented in a Single Box Architecture using a Dual-Homed Host as the router and a dummy host representing the internal network.

There were three major stepsin the process of setting up the entire System:
· Setting up an Internal Network (A Dual-Homed Host configured) using iproute2 (for IP Forwarding and Masquerading)
A dual homed gateway is a system that has two or more network interfaces, each of which is connected to a different network. In firewall configurations, a dual homed gateway usually acts to block or filter some or all of the traffic trying to pass between the networks.
This setup was a preliminary requirement to the configuration of the Firewall so as to ensure passage of all traffic to the internal host through a choke point.
After the entire setup was ready and the internal host was able to connect to external hosts through the gateway, the firewall was to be put into place.
(A Packet Filter on Linux)
The Package iptables are built and rules are configured to monitor and filter out packets that went through our gateway.
Iptables uses the mechanism of chains to filter out packets passing through the host.
There are three default chains input, output and forward that determine the fate of the packets destined for the host, generated from the host and passing through the host respectively.
Rules such as accept, deny, reject, log, pass to another chain, etc. can be setup on all of the chains based on various fields in the packet header such as source and destination addresses, protocols, options, etc.
This is done to allow fair queuing of packets from the hosts on the internal network.
In conjunction with iproute2, a package called tc (Traffic Controller) was used to allocate definite bandwidths to the hosts on the internal Network.
A detailed description of the configuration procedures is discussed below.
Netfilter/Iptables
The netfilter/iptables project is the Linux 2.4.x / 2.5.x firewalling subsystem. It delivers you the functionality of packet filtering (stateless or stateful), all different kinds of NAT(Network Address Translation) and packet mangling. It can be used for all kinds of firewalling, NAT or other advanced packet processing. The major part of netfilter/iptables (doing all the hard work) is included in the standard Linux Kernel. In order to do your runtime configuration of the firewalling subsystem, you will need the iptables userspace command.
Netfilter is a set of hooks inside the Linux 2.4.x kernel's network stack which allows kernel modules to register callback functions called every time a network packet traverses one of those hooks.
Iptables is a generic table structure for the definition of rulesets. Each rule within an IP table consists out of a number of classifiers (matches) and one connected action (target). Netfilter, iptables and the connection tracking as well as the NAT subsystems together build the whole framework.
Main Features
· stateful packet filtering (connection tracking)
· all kinds of network address translation
· flexible and extensible infrastructure
· large number of additional features as patches
A packet selection system called IP Tables has been built over the netfilter framework. This packet selection method is used for packet filtering (the `filter' table), Network Address Translation (the `nat' table) and general pre-route packet mangling (the `mangle' table).
This table, `filter', should never alter packets: only filter them.
One of the advantages of iptables filter over ipchains is that it is small and fast for any given packet, there is one (and only one) possible place to filter it. This makes things much simpler for users than ipchains was.
NAT
It translates IP addresses of the internal hosts to hide them from outside monitoring. Thus it is also called IP masquerading .This table is slightly different from the `filter' table, in that only the first packet of a new connection will traverse the table: the result of this traversal is then applied to all future packets in the same connection.
Masquerading, Port Forwarding, Transparent Proxying
Source NAT(where the first packet has its source altered)
Destination NAT (the first packet has its destination altered).
Masquerading is a special form of Source NAT: port forwarding and transparent proxying are special forms of Destination NAT.
Packet Mangling
The packet mangling table (the `mangle' table) is used for actual changing of packet information. It hooks into netfilter at the NF_IP_PRE_ROUTING and NF_IP_LOCAL_OUT points.
Virtual private network (VPN)
Virtual private network (VPN) allows to securely connect two physical separated networks over the internet . They also allow users to address remote internal hosts directly by their hidden IP addresses .
They can be implemented in two ways.
1. Leasing lines from the telephone company
2. Encrypted Tunneling
Connection Tracking
Connection tracking is fundamental to NAT, but it is implemented as a separate module; this allows an extension to the packet filtering code to simply and cleanly use connection tracking (the `state' module).

A leased line private network

Table
The -t option specifies which table to use. By default, the filter table is used. The following options are available to the -t command:
1. nat
The nat table is used mainly for Network Address Translation. Packets in a stream only traverse this table once. The first packet of a stream is allowed, we presume. The rest of the packets in the same stream are automatically NAT’ed or Masqueraded etc, in case they are supposed to have those actions taken on them. The rest of the packets in the stream will in other words not go through this table again, but instead they will automatically have the same actions taken to them as the first packet in the stream. This is one reason why you should not do any filtering in this table.
2. filter
The filter table should be used for filtering packets generally. For example, we could DROP, LOG, ACCEPT or REJECT packets in this table. There are three chains built in to this table.
3. mangle
This table is used mainly for mangling packets. We could change different packets and how their headers look among other things. Examples of this would be to change the TTL, TOS or MARK. Note that the MARK is not really a change to the packet, but a mark for the packet is set in kernel-space which other rules or programs might use further on in the firewall to filter or do advanced routing on with tcas an example.
The command tells iptables what to do with the rest of the commandline that we send to the program.
Matches
The matches can be broken into five different subcategories. First of all there are generic matches which are generic and can be used in all rules. Then we have the TCP matches which can only be applied to TCP packets. We have UDP matches which can only be applied to UDP packets and ICMP matches which can only be used on ICMP packets. Finally we have special matches such as the state, owner and limit matches and so on.
Targets/Jumps
The target/jumps tell the rule what to do with a packet that is a perfect match with the match section of the rule. For e.g., ACCEPT, DROP..
.
Packet Traversal of Tables and Chains
When a packet first enters the firewall, it hits the hardware and then gets passed on to the proper device driver in the kernel. Then the packet starts to go through a series of steps in the kernel before it is either sent to the correct application locally, or forwarded to another host or whatever happens to it.
Forwarded Packets
1) On the wire
2) Arrives on the interface (eth0, etc.)
3) Passes through table mangle, chain PREROUTING
4) Passes through table nat, chain PREROUTING
5) Kernel makes the routing decision using its routing table
6) Passes through table filter, chain FORWARD
7) Passes through table nat, chain POSTROUTING
8) Packet comes on the outgoing interface
9) On the wire, again
Packets Destined for Local-host
1) On the wire
2) Arrives on the interface (eth0, etc.)
3) Passes through table mangle, chain PREROUTING
4) Passes through table nat, chain PREROUTING
5) Kernel makes the routing decision using its routing table
6) Passes through table filter, chain INPUT
7) Packet gets to the Local process/application
Packets from Local-host
1) Local process/application
2) Passes through table mangle, chain OUTPUT
3) Passes through table nat, chain OUTPUT
4) Passes through table nat, chain OUTPUT
5) Passes through table filter, chain OUTPUT
6) Kernel makes the routing decision using its routing table
7) Passes through table nat, chain POSTROUTING
8) Goes out on some interface (eth0, etc.)
9) On the wire
Enabling Basic, Required Internet Services
Allowing DNS (UDP/TCP Port 53)

DNS uses a communication protocol that relies on both UDP and TCP. Connection modes include regular client-to-server connections, peer-to-peer traffic between forwarding servers and full servers, and primary and secondary name servers connections.
Query lookup requests are normally done over UDP, both for client-to-server lookups and peer-to-peer server lookups. The UDP communication can fail for a client-to-server lookup if the information returned is too large to fit in a single UDP DNS packet. The server sets a flag bit in the DNS message header indicating that the data is truncated. In this case, the protocol allows for a retry over TCP. The figure below shows the relationship between UDP and TCP during a DNS lookup. In practice, TCP isn’t normally needed for queries. TCP is conventionally needed for administrative zone transfers between the primary and secondary name servers.
Zone transfers are the transfer of a name server’s complete information of a network or a piece (zone) of a network, the server is authoritative for (i.e., the official server). The authoritative name server is referred to as the primary name server. Secondary, or backup, name servers periodically request zone transfers from their primary to keep this DNS caches up-to-date.
The AUTH, or IDENTD, user identification service is most often used when sending mail or posting Usenet article. Some FTP sites are also configured to require a resolvable AUTH lookup. For logging purposes, the server initiates an AUTH request back to your machine to get the account name of the user who initiated the mail or news connection.
Allowing Your Outgoing AUTH Requests as a Client
Your machine will act as an AUTH client is you ran a mail or FTP server. There is no reason not to allow your system to be an AUTH client.
Offering AUTH services is a matter of debate. There appear to be no overwhelming arguments to make the case for either side, other than that a growing number of FTP sites require it, and AUTH provides user account information.
If you decide not to offer the service, then the result would be a long wait each time you tried to send mail or post a Usenet article. Your mail client won’t be notified that the mail or article was received for delivery until the identd request timed out. Indeed, you need to reject the connection request to avoid waiting for TCP connection timeout
Enabling Common TCP Services
Possibly no one will want to enable all the services listed in this section, but everyone will want to enable some subset of them. These are the services most often used over the Internet today. This section provides rules for the following:
· Email
· Usenet
· telnet
· ssh
· ftp
· Web services
· finger
· whois
· gopher Information Service
· Wide Area Information Service (WAIS)
FTP remains one of the most common means of transferring files between two networked machines. Web-based interfaces to FTP have become common, as well.
FTP uses two privileged ports, one for sending commands and one for sending data. Port 21 is used to establish the initial connection to the server and pass user commands. Port 20 is used to establish a data channel over which files and directory listings are sent as data.
FTP has two modes for exchanging data between a client and server, normal data channel port mode and passive data channel mode. Normal port mode is the original, default mechanism when using the ftp client program and connecting to a remote FTP site. Passive mode is a newer mechanism, and is the default when connecting through a Web browser. Occasionally, you might encounter an FTP site that supports only one mode or the other. The table below lists the complete client/server connection protocol for the FTP service.
The unusual callback behavior, where the remote server establishes the secondary connection with your client, is part of what makes FTP difficult to track, and thereby difficult to secure, at the packet-filtering level. Therefore the connection-tracking module (ip_conntrack) needs a helper module (ip_conntrack_ftp) to track FTP connections. This module should be loaded in order to correctly track the FTP connections.
Allowing Outgoing Client Access to Remote FTP Servers
It’s almost given that most sites will want FTP client access to remote file repositories. Most people will want to enable outgoing client connections to a remote server.
Outgoing FTP Requests
These rules allow an outgoing connection to a remote FTP server. The state RELATED is used in order to allow those packets that have been related with this connection and identified by the connection-tracking module.
For IPTABLES to correctly track the FTP data channel connection you need to
load the module ip_conntrack_ftp.o
Passive Mode FTP Data Channels
Passive mode is considered more secure than normal port mode because the FTP client initiates both the control and data connections, even tough the connection is made between two unprivileged ports. But, as we don’t know in advance which ports are to be used, therefore we need to leave this work to the FTP helper module for connection tracking (ip_conntrack_ftp).
Allowing Incoming Access to Your Local FTP Server
Whether to offer FTP services to the world is a difficult decision. Although FTP sites abound on the Internet, FTP server configuration requires great care. Numerous FTP security exploits are possible.
If your goal is to offer general read-only access to some set of files on your machine, you might consider making these files available through a Web server. If your goal is to allow file uploads to your machine from the outside, FTP server access should be severely limited on the firewall level, on the tcp_wrapper level, and on the FTP configuration level.
In any case, if you decide to offer FTP services, and if you decide to allow incoming file transfers, write access should not be allowed via Anonymous FTP. Remote write access to your file systems should be allowed only from specific, authenticated FTP user accounts, from specific remote sites, and to carefully control and limit FTP areas reserved in your file system.
For IPTABLES to correctly track the FTP data channel connection you need to load the module ip_conntrack_ftp.o
Passive Mode FTP Data Channel Responses
For IPTABLES to correctly track the FTP data channel connection you need to load the module ip_conntrack_ftp.o
Web services are based on Hypertext Transfer Protocol (HTTP). Client and server connections use the standard TCP conventions. Several higher-level, special-purpose communication protocols are available, in addition to the standard general HTTP access, including secure access over SSL, and access via an ISP-provided Web server proxy. These different access protocols use different service ports.
Standard HTTP Access (TCP Port 80)
In normal use, Web services are available over HTTP service port 80.
Accessing Remote Web Sites as a Client
It’s almost inconceivable in today’s world that a home-based site would not want to access the World Wide Web from a Web browser
Allowing Remote Access to a Local Web Server
If you decide to run a Web server of your own and host a Web site for the Internet, the general server rules allow all typical incoming access to your site.
Secure Web Access (SSL) (TCP Port 443)
Secure Socket Layer (SSL) is used for secure, encrypted Web access. The SSL protocol uses TCP port 443. You will most often encounter this if you go to a commercial Web site to purchase something, use online banking services, or enter a protected Web area where you’ll be prompted for personal information. The table below lists the complete client/server connection protocol for the SSL service.
Accessing Remote Web Sites Over SSL as a Client
Most people will want client access to secure Web sites at some point or another.
Allowing Remote Access to a Local SSL Web Server
If you conduct some form of e-commerce, you’ll mostly likely want to allow incoming connections to SSL-protected areas of your Web site.
Web Proxy Access (TCP Ports 8008, 8080)
Publicly accessible Web server proxies are the most common at ISPs. As a customer, you configure your browser to use a remote proxy service. Web proxies are often accessed through one of two unprivileged ports assigned for this purpose, port 8008 or 8080, as defined by the ISP. In return, you get faster Web page access when the pages are already cached locally at your ISP’s server, and the anonymity of proxied access to remote sites. Your connections are not direct, but instead are initiated on your behalf by your ISP’s proxy. The table below lists the local client to remote server connection protocol for the Web proxy service.
If you decide to run a Web proxy server and provide the service to some of your clients, then the rules must allow the remote clients to use this service.
Enabling Common UDP Services
The stateless UDP protocol is inherently less secure than the connection-based TCP protocol. Because of this, many security-conscious sites completely disable, or else limit as much as possible, all the access to UDP services. Obviously, UDP-based DNS exchanges are necessary, but the remote name servers can be explicitly specified in the firewall rules. As such, this section provides rules for the following services:
· traceroute
· Dynamic Host Configuration Protocol (DHCP)
· Network Time Protocol (NTP)
traceroute is a UDP service that causes intermediate systems to generate ICMP Time Exceeded messages to gather hop count information, and the target system to return a Destination Unreachable (port not found) message, indicating the endpoint of the route to the host.
Traceroute can be configured to use any port or port range. As such, it’s difficult to block all incoming traceroute packets by listing specific ports. However, it often uses source ports in the range from 32769 to 65535 and destination ports in the range from 33434 to 33523.
Enabling Outgoing traceroute Requests
If you intent to use traceroute yourself, you must enable the UDP client ports. Note that you must allow incoming ICMP Time Exceeded and Destination Unreachable messages from anywhere for outgoing traceroute to work.
Allowing Incoming traceroute Requests
Because traceroute is a less secure UDP service and can be used to attack other UDP services, the following example opens incoming traceroute from only your ISP. Note that you must allow outgoing ICMP Time Exceeded and Destination Unreachable messages to be targeted to your ISP for incoming traceroute to work.
Accessing Your ISP's DHCP Server (UDP Ports 67, 68)
DHCP exchanges, if any, between your site and your ISP's server will necessarily be local client to remote server exchanges. DHCP clients receive temporary, dynamically allocated IP addresses from a central server that manages the ISP's customer IP address apace.
If you have a dynamically allocated IP address from your ISP, you need to run the DHCP client on your machine. It's not uncommon for bogus DHCP server messages to fly around your ISP's local subnet if someone runs the server by accident. For this reason, it's especially important to filter DHCP messages to limit traffic between your client and your specific ISP DHCP server as much as possible.
In essence, when the DHCP client initializes, it broadcasts a DHCPDISCOVER query to whether any DHCP servers are available. Any servers receiving the query may respond with a DHCPOFFER message indicating their willingness to function as a server to this client, and include the configuration parameters they have to offer. The client broadcasts a DHCPREQUEST message to both accept one of the servers and inform any remaining servers that it has chosen to decline their offers. The chosen server responds with a DHCPACK message, indicating confirmation of the parameters it originally offered. Address assignment is complete at this point. Periodically, the client will send a DHCPREQUEST message requesting a renewal on the IP address lease. If the lease is renewed, the server responds with a DHCPACK message. Otherwise, the client falls back to the initialization process. The table below lists the local client to remote server exchange protocol for the DHCP. The DHCP protocol is far more complicated than this brief summary, but the summary describes the essentials of the typical client and server exchange.
Allowing Client Access to Remote DHCP Server
The firewall rules allow communication between your DHCP client and a remote server:
DHCP traffic cannot be completely limited to your DHCP server. During initialization sequences, when your client doesn't yet have an assigned IP address or even the server's IP address, packets are broadcast rather than sent point-to-point.
Network time services such as NTP allow access to one or more public Internet time providers. This is useful to maintain an accurate system clock, particularly if your internal clock tends to drift, and to establish the correct time and date at boot-up or after a power loss. A small system user should use the service only as a client. Few, if any, small sites have a satellite link to Greenwich , England , a radio link to the United States atomic clock, or an atomic clock of their own lying around.
Allowing Client Access to Remote NTP Servers
The protocols here support client access to remote NTP Servers.
Advanced Routing and Traffic Control
We will cover the link, addr, route, rule, neigh, tunnel, and monitor parts of the ip command
We will first go through all of the command syntax of the ip command. The generic form of the ip command is :
ip [ OPTIONS ] OBJECT [ COMMAND [ ARGUMENTS ]]
OPTIONS:
OPTION is a multivalued set of modifiers that affect the general behavior and output of the ip utility. All options begin with the "-" character and may be used both in long and abbreviated form. Currently the following options are available
-V, -Version --- print the version of the ip utility and exit.
-s, -stats, -statistics --- output more information.
-f, -family {inet, inet6, link} --- enforce which protocol family to use.
OBJECT:
OBJECT is the object type on which you wish to operate on or obtain information about. The object types understood by the current ip utility are link, address, neighbor, route, rule, maddress, mroute, and tunnel.
link --- physical or logical network device.
address --- protocol (IPv4 or IPv6) address on a device.
neighbour --- ARP or NDISC cache entry.
route --- routing table entry.
rule --- rule in routing policy database.
maddress --- multicast address.
mroute --- multicast routing cache entry.
tunnel --- tunnel over IP.
COMMAND:
COMMAND specifies the action to perform on the object. The set of possible actions depends on the object type. Typically it is possible to add, delete, and show (list) the object(s), but some objects will not allow all of these operations and many have additional actions and commands
ARGUMENTS:
ARGUMENTS is the list of command options specific to the command. The arguments depend on the command and the object. There are two types of arguments that can be issued:
--- flags - which are abbreviated with a single keyword
--- parameters - consisting of a keyword followed by a value
Note that all ip command operations are atomic. This means that if the ip command fails it does not change anything in the system .If the ip command does not work or you get an error message then you may not have the needed functions defined or your kernel is not the one you compiled.
ip address - protocol address management
The address refers to a protocol (IP or IPv6) address attached to a network device. Each device must have at least one address in order to use the corresponding protocol. It is possible to have several different addresses attached to one device. These addresses are not discriminated within the protocol structure so that the term alias is not quite appropriate for such multiple addresses and we will not refer to this situation in those terms.
ip neighbour --- neighbour/arp table management.
The neighbour table objects establish bindings between protocol addresses and link layer addresses for hosts sharing the same physical link. Neighbour object entries are organized into tables.
ip route - routing table management.
This command manages the route entries within the kernel routing tables. The kernel routing tables keep information about protocol paths to other networked nodes.
Prepend does the same thing as the classic route add command by adding the route even if another route to the same destination already exists.
Append which adds the route to the end of the list.
ip tunnel - ip tunneling configuration
The tunnel objects are tunnels encapsulating packets within IPv4 packets and sending them over the IP infrastructure.
ip tunnel add - creating tunnels
remote ADDRESS --- set remote endpoint of the tunnel.
local ADDRESS --- set fixed local address for tunneled packets. It must be an address on another interface of this host.
Conclusion
Firewalls are one of the most indispensable components of the System for Security in an environment as we have today where electronic transactions over the internet are very frequent. Corporations involved in e-commerce as well as Defence Agencies are bound to use a mechanism to shield themselves against various attacks.
Like all technologies, a firewall has its share of pros and cons. Some of the shortcomings that a network having a firewall still suffers are that it cannot protect against malicious insider. It can’t protect against connections that don’t go through it. It can protect against only those threats that it understands and a virus may shatter its worth if it is new for it .
Considering the popularity and the reach of the Internet into the personal and professional lives of people today, it becomes evident that, like real life, Privacy and Protection need to be taken care of in the cyber world, too.
Firewalls are part of the gamut of tools available to assist in achieving Internet Security for a Network.
REFERENCES
Books
· “Computer Networks” Andrew s. Tanenbaum
· “Cryptography and Network Security” William Stallings
· “Cryptography and Network Security” Singh and Vishwamitra
Web Sites
· Firewall.com
· Google.com
· Turbo10.com
{ 0 comments... read them below or add one }
Post a Comment