Date: May 31st 2010

METTLE NEWS
[News letter on Mettle(tm) brand of products; Industry updates, Tips and Case
studies]

May 2010
Volume 3, Issue 5


In this issue:

* Editorial
* IT Industry news: How fragile is the Internet?
* Tip of the month: Troubleshooting Firewall Rules
* Mettle SE feature: Firewall logs


* Editorial *

Greetings!

Networking has two faces: Enterprise networking and the Internet (as seen by ISPs and carriers). The Internet
side of networking is quite challenging and demands a lot of co-operation and trust among operators for it to
work. This month's Industry News provides an interesting but scary problem that prevails in the Internet.

Many a time, every network administrator faces the problem is firewall rule verification-basically finding out
whether the rule written matches the packets. Mettle SE provides a mechanism for this. This saves time and
effort. Also let you know, positively, how good you are in writing firewall policies.

This month's feature section, we explain you the firewall rules and how effectively you can use them them.

Happy networking.

Editor, Mettle News
(mettlenews@mettle.in)


* IT Industry news: How fragile is the Internet? *

Brief Description: Unfixed routing glitch causing concern

Story:

In 1998 a hacker claimed that Internet could be brought down to its heels in 30minutes by exploiting a flaw
which caused online outages occasionally by misdirecting data.

In 2010 the flaw still causes outages every year, although most of the outages are innocent and fixed quickly,
the problem still could be exploited by a hacker to spy on data traffic or take down websites. Reliance on the
Internet has only increased in all these years and an outage could disrupt businesses and governments which
require Internet to function normally.

These outages are called "hijackings" and are caused by the haphazard way through which traffic is passed
between companies that carry Internet data. It is the Internet's open nature which has stimulated its dazzling
growth, and it is this same open nature which is contributing to the outage problem of the Internet.

When an email is sent and a website is opened or done anything else online, the data you send and receive is
handed from one carrier of Internet to another. The data might be handed from your ISP to a third party
company which operates a global network of fiber-optic lines that carry Internet data across long distances.
It, in turn, might pass the data to another carrier that's connected directly to the server computers the data
is intended for.

The crux of the problem is that each carrier along the way figures out how to route the data based only on
what the surrounding carriers in the chain say, rather than by looking at the whole path. Because carriers
pass information between themselves about where data should go, and this system has no secure automatic
means of verifying the routing information is correct, data can be routed to some carrier that isn't
expecting the information. The carrier doesn't know what to do with it, and usually just drops it.

On April 25, 1997, millions of people in North America lost access to all of the Internet for about an hour,
caused by an employee mis-programming a router at a small Internet service provider. That's what happens
when an Internet route gets hijacked. It falls into a "black hole." Routing errors has previously blocked
Internet access in different parts of the world, at different times, often for millions of people.

Last month a Chinese Internet service provider halted access from around the world to a vast number of sites,
including Dell.com and CNN.com, for about 20 minutes.

In 2008, Pakistan Telecom tried to comply with a government order to prevent access to YouTube from the
country and intentionally "black-holed" requests for YouTube videos from Pakistani Internet users. But it also
accidentally published the route international upstream carrier, the upstream carrier accepted the routing
message, and passed it along to other carriers across the world, which started sending all requests for
YouTube videos to Pakistan Telecom. Soon, even Internet users in the U.S. were denied YouTube access for a few
hours.

In 2004, the flaw was put to malicious use when someone got a computer in Malaysia to tell Internet service
providers that it was part of Yahoo Inc. A flood of spam was sent out, appearing to come from Yahoo.

In 2003, the Bush administration's Critical Infrastructure Protection Board assembled a "National Strategy to
Secure Cyberspace" that concluded that it was vital to fix the routing system and make sure route always point
in the right direction.

Unlike other Internet bugs that get discovered and fixed relatively quickly, the routing system has been
unreformed for more than a decade. There is some progress being made but there's little industry-wide momentum
behind efforts to introduce a permanent remedy. Data carriers regard the fallibility of the routing system as
the price to be paid for the Internet's open, flexible structure. The simplicity of the routing system makes
it easy for service providers to connect, a quality that has probably helped the explosive growth of the
Internet.

Peiter Zatko, a member of the "hacker think tank" called the L0pht, told Congress in 1998 that he could use
the BGP vulnerability to bring down the Internet in half an hour. In recent years, Zatko, who now works for
the Pentagon's DARPA, has said the exploit would still work. However he added, it would likely take a few
hours rather than 30 minutes, partly because a greater number of Internet carriers would need to be hit.

Plenty of solutions have been proposed in the Internet engineering community since 1995. The U.S. government
has supported these efforts, spurred in part by the Bush administration's 2003 strategy statement. It has
resulted in some trials of new technology, but adoption by data carriers still appears distant. And the
federal government doesn't have any direct authority to force changes.

One solution being tested would stop short of making the routing system fully secure but would at least verify
part of it. Yet this system also worries carriers because they would have to work through a central database.

Weakness in the system are in the routing between carriers. It doesn't help if one carrier introduces a new
system, every one it connects with has to make the change as well.

As Doug Maughan of the US Homeland Security puts it, "It's kind of everybody's problem, because it impacts the
stability of the Internet, but at the same time it's nobody's problem because nobody owns it".

Meanwhile, network administrators deal with hijacking an old-fashioned way: calling their counterparts close
to where the hijacking is happening to get them to manually change data routes. Let us hope that researchers
will come up with something robust and practical to keep the Internet secure soon.

http://detnews.com/article/20100508/BIZ04/5080399/Unfixed-Internet-glitch-could-strand-users-offline


* Tip of the month: Troubleshooting Firewall Rules *

This month we will help you troubleshoot your firewall rules if they are not behaving as you expect it to.

Check firewall logs:- First step to take while debugging suspected blocked traffic is to check the firewall
logs. With factory setting Mettle SE logs all dropped traffic and will not log passed traffic. If there is no
traffic with a red X next to it in your firewall logs, Mettle SE is not dropping the traffic.
(Firewall logs explained in "Feature of the month"section).

Review rule parameters:- Edit the suspected rule and review the parameters you have specified for each field.
For TCP and UDP traffic the source and destination ports are almost never the same and should be set to any.
If the default deny rule is the cause of problem, you have to create a new pass rule that will match the
traffic that is to be allowed.

Review rule order:- First matching rule for a case wins. No further rules are evaluated.

Rules and interfaces:- Make sure the rules are assigned on the correct interface. Traffic is filtered only by
the rule set configured on the interface where traffic is initiated.

Enable rule logging: By enabling logging on your pass rules, you can view firewall logs and click on an entry
to determine which rule passed the traffic. This can be helpful to determine which rule is matching the
traffic in question.

Packet captures:- This is a mighty good tool for troubleshooting and debugging firewall and traffic issues.
With packet capture you can tell if the traffic is reaching the outside interface or leaving the inside
interface and among many other uses.

How to use packet capture:- http://kb.mettle.in/entry/43/


* Mettle SE feature: Firewall logs *

A firewall log entry is made for each rule that is set to log and for the default deny rule. To view the
parsed logs you have to go to Status -> System Logs on the Firewall tab.

Parsed logs are displayed in 6 columns: Action - Time - Interface - Source - Destination - Protocol. Action
tells what happened to the packet which generated the log entry - its either Pass, Block, or Reject. Time
tells the time when the packet has arrived. Interface is the interface through which the packet entered
Mettle SE. Source is the source IP address and the port the packet originated from, Destination is the
destination IP address and port of the packet. Protocol is the protocol of the packet.

The 'Action' icon displayed in the logs is a link, clicking it will lookup and display the rule which caused
the log entry.

If the Protocol is TCP, you will see extra fields that represent TCP flags present in the packet. These flags
indicate various connection states or packet attributes, some common flags are:

S (Syn) - Synchronise sequence numbers. Indicates a new connection attempt when only SYN is set.
A (Ack) - Acknowledgement to the data received.
F (Fin) - Indicates there is no more data from the sender, connection closing.
R (Rst) - Connection reset

http://kb.mettle.in/entry/52/



--
We would like to receive feedback regarding the content of this newsletter and
request for articles. Please send in your valuable suggestions to
mettlenews@mettle.in.

--
Mettle and Linuxense are trademarks of Linuxense Information Systems Pvt. Ltd.
Other trademarks belong to respective owners. 2008 (C) Linuxense Information
Systems Pvt. Ltd. All rights reserved.