Date: April 30th 2010

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

April 2010
Volume 3, Issue 4


In this issue:
* Editorial
* IT Industry news: Accidentally Importing Foreign Censorship Policy
* Tip of the month: Firewall Rule Best Practices
* Mettle SE feature: Server Load Balancing
* Case Study: Mettle SE at a Research and Education Institute in Kerala



* Editorial *

Greetings,

This month passes with yet another episode of wrong BGP advertisement hogging the Internet. This occurred in
China this time. Result: China's censorship was enforced outside their country. Read the full story in the
Industry News section.

A badly maintained system is prone to go wrong and will turn into a maintenance nightmare. Firewall is no
exception. This month's Tip of the Month section describes how the firewall configuration in Mettle SE can be
kept neat and tidy. It is nothing but a set of conventions that can be followed easily.

Redundancy is what we think when it comes to high availability. It is easier said than done when it comes to
setting up redundant servers or services and putting them into use effectively. This requires additional
infrastructure components to direct traffic and check out availability etc. Mettle SE supports this and this
feature is part of standard firmware. Read about this in this month's Mettle SE Feature column.

This month's case study explains how Mettle SE enabled a premier research institute to implement a secure IT
infrastructure and policy enforcement in their campus.

Happy networking!

Editor, Mettle News
(mettlenews@mettle.in)


* IT Industry News: Accidentally Importing Foreign Censorship Policy *

You're browsing the Internet from a place with no Internet censorship, but one fine day the websites you used
to visit have become unavailable or you're presented with restricted user access. You may not have realised,
but your computer must have come under the Internet censorship policy of another country! Sounds strange?
Read on!

With advancing technology, sophisticated filtering technologies are increasingly being applied to restrict
access to the Internet. Internet filtering is done by corporations and by some governments. Given the open
nature of the Internet, one country's restrictions, if not handled very carefully, can foul global Internet
access. This article is about one such incident, Internet filtering done in China affecting other parts of the
world and going undetected for 3 weeks. Given the increasing complexity and efficiency of this technology, and
the difficulty in controlling a very open Internet, and the desire of some to do just that could be a
harbinger of things to come.

To understand this, one needs a bit of Internet routing know how, the behaviour of DNS and the root name
servers, and the economics of Internet routing.

When you type www.facebook.com into your browser, your computer first contacts a DNS server to convert this
name into an IP address in order to contact the host serving this content. Answers to DNS requests are cached
on both your machine and the servers involved to save time and to reduce the load of subsequent identical
queries. Now suppose that the caches on your computer and your DNS server are both empty and you make the
above query. Your DNS server first contacts a Root name server with your request. If configured according to
convention, the Root name server will not provide the answer to your query by itself, instead directs your DNS
server to the .com Name servers. In turn, .com name servers will direct your DNS server to the Facebook.com's
name server, which will ultimately provide IP address to of Facebook's web servers.

Now suppose corporate Z runs a root name server and Z wants to restrict Facebook access. Nothing requires Z to
direct you to the .com name servers as in the chain of resolution described above. Since Z sees your complete
request, it could just answer it directly. If Z gave you the wrong answer, it would effectively block your
access to Facebook. Since Internet runs on trust, you'll also end up caching Z's invalid response (called
“cache poisoning”) and with Z being the one who tells you how long to cache the result. Or Z could actually
provide the correct answer, but a firewall in front of Z could alter the DNS query response on its way back
to you.

Incident Details

This scenario might seem very unlikely but it in fact just happened with the I-Root instance that runs out of
China. The problem existed from March 3rd until March 25th, before it was reported and corrected. Despite the
fact that a lot of people could have been impacted, the chances of any one of them having gotten the incorrect
DNS response are extremely remote. Thanks again to the way DNS operates and the overall resiliency of the
Internet.

China censors the Internet in a variety of ways, one way is to return invalid answers to DNS requests to
Chinese users. For example, a Chinese DNS server is returning 46.82.174.68 as an IP address for
www.facebook.com, when in fact all legitimate Facebook IPs are of the form 66.220.x.y or 69.63.x.y. Such
seemingly random IPs are also returned for www.twitter.com, www.youtube.com and many other domains. This is
normal and expected behavior inside China.

However, China hosts an instance of a Root name server, the I-Root, when this server became visible outside of
China on March 3rd, anyone who happened to query it could have got bogus responses. There are thirteen
different root name server IP addresses and the I-root is just one of these, namely 192.36.148.17. In
addition, there are dozens of instances of the I-Root housed in many locations around the world. To get a
bogus DNS response outside of China, you not only had to query the I-Root but you had to query the Chinese
version of it. Not surprisingly, the most exposed countries were all in Asia, but some prefixes in the US were
also vulnerable, more than half of which geo-locate to California.

Let us review the unlikely series of events that would have been required to observe a bogus answer to
www.facebook.com.

1. You attempt to go to www.facebook.com.
2. You don't have this entry in your DNS cache, nor does your DNS server.
3. Your DNS server does not have the .com servers cached either.
4. Your DNS server happens to choose the I-root (as opposed to A-root, B-root, C-root,... M-root etc).
5. Due to current Internet routing in place at your location, your DNS server happens to be directed to
China's instance.

Since Facebook is blocked in China, your DNS server does not get the expected list of .com servers, but rather
a bogus response to your original request, either from the I-root itself or a firewall in between.

You don't have any control over which I-root instance you see from your location. That is determined by
Internet routing. Many of the root name servers are “anycast” from multiple locations around the world. This
means that the associated IP prefixes are announced from multiple locations, all of which house servers with
copies of the appropriate data. BGP, the Internet routing protocol, is then used to sort out who sees which
instance of the root servers from which locations. In general, the Chinese I-root instance is supposedly only
visible from within China, but for 3 weeks these routes leaked out to the global Internet which created this
issue. This announcement leaked out of China when it was leaked by China Network Information Center.

Internet routing is driven more by economics than by physical distance, although the two are often related.
For example, two smaller Internet service providers X and Y, agree to exchange traffic with each other for
free. This common arrangement on the Internet is known as peering and allows X and Y to save money in transit
costs to larger ISPs. Suppose further that X (or one of its customers) is running the I-root. If Y needs to
get to the I-root it should pick its peering link with X, rather than its link to a larger carrier for whom
they have to pay. China Telecom, the largest carrier in China, peers with nearly 100 other ISPs. If those ISPs
or their customers aren't running an instance of the I-root themselves, they might use their peering link to
China Telecom to reach their instance. This is how countries far from China could end up selecting the Chinese
I-root as the "best" of many possibilities.

Conclusions

The article illustrates both the fragility and the resiliency of the Internet. Its fragile because it is
ultimately trust-based and almost anyone can violate that trust, deliberately or by accident. Its resilient
because there are often many alternatives or workarounds for any sabotage or attempts to control it.

Reference: Renesys blog: http://www.renesys.com/blog/2010/03/fouling-the-global-nest.shtml


* Tip of the month: Firewall Rule Best Practices *

Below are general best practice tips to consider when configuring firewall rules. Following best practices
tips will help you to create a secure and robust computer network and easy trouble shooting.

1) Default deny: Two philosophies in computer security related access control are default allow and default
deny. Best practice is to have the default deny strategy. Configure your rules to permit only the bare minimum
required traffic for your networking needs, and let the rest drop with Mettle SE's built in default deny rule.

2) Keep it short: The shorter the rule set, the easier it is to manage. Long rule sets are difficult to work
with, increase human error, tend to become overly permissive and significantly more difficult to audit.
Utilise 'Aliases' to help keep your rule set as short as possible.

3) Review your rules: You should manually review your firewall rules and NAT configuration on a periodic basis
to ensure they still match minimum requirements of your current network environment. The recommended frequency
of such review will vary from one scenario to another. In networks that do not change frequently with a small
number of network administrators and good change control procedures, quarterly or semi-annually is usually
adequate. For fast changing environments or those with poor change control and several network administrators,
the configuration should be reviewed at least on a monthly basis.

4) Document your configuration: Use of the 'description' field in firewall and NAT rules is always recommended
to document the purpose of each rule. In larger or more complex deployments, you should also maintain a more
detailed configuration document describing your entire Mettle SE configuration. When reviewing your
configuration in the future this should help you determine which rules are necessary and why they are there.

5) Reducing log noise: Logging is enabled on the default deny rule in Mettle SE by default. This means all the
noise getting blocked from the Internet is going to get logged. Sometimes you won't see much noise, but in
many environments you will find something incessantly spamming your logs. Sometimes spamming cover up logs
that are important, and its a good idea to add a block rule on the WAN interface for repeated noise traffic.
By adding a block rule without logging enabled on the WAN interface, the traffic will still be blocked, but no
longer fill your logs.

6) Logging Practices: By default Mettle SE does not log any passed traffic and logs all dropped traffic. This
is a practical setting as logging all passed traffic should rarely be done due to log levels generated. There
is a catch in this, blocked traffic cannot harm the network, but traffic that gets passed could be very
important log information to have if a system is compromised. After eliminating useless block noise as
described in the previous section, the remainder is of some value for pattern analysis purpose. If you are
seeing a significantly more or less log volume than usual, its probably good to investigate why.


* Mettle SE Feature: Server Load Balancing *

Server load balancing allows you to distribute traffic between multiple internal servers. It is commonly used
with web servers and SMTP servers though it can be used for any service that uses TCP.

There are two portions of configuration for the server load balancer. Virtual server pools define the list of
servers to be used, which port they listen on, and monitoring method to be used. Virtual servers define the IP
address and port to listen on, and the appropriate pool to direct the incoming traffic to that IP address and
port.

To configure Virtual server pools:

1) Go to: Services --> Load Balancer --> Click + button to add a new pool.
2) Name --> Enter a name for the pool here. The name is referenced later when configuring virtual server.
3) Description --> You may enter an optional description here/
4) Type --> Select 'Server'
5) Behaviour --> Select 'Load Balancing'
6) Port --> This is the port your servers are listening on internally. This can be different from the external
port.
7) Monitor --> Defines the type of monitoring to use. Selecting 'TCP' will make the balancer connect to the
port defined above, if it cannot connect, server is considered down. Choosing 'ICMP' will monitor the defined
servers by pinging them, and will be marked down if there is no ping response.
8) Monitor IP --> Not applicable with server load balancing
9) Server IP Address --> Fill in the IP address of the servers in the pool.
10) List --> Shows the list of servers you have added to this pool. You can remove a server from the pool by
clicking on its IP address and clicking remove from pool.
11) Click on 'Save' and proceed to configure virtual servers.

To Configure virtual servers:

1) Name --> Enter a name for the virtual server here, this is not parsed.
2) Description --> You may enter a long description here, its not parsed.
3) IP Address --> Enter the IP address that the virtual server will listen on. This is usually your WAN IP or
a Virtual IP on WAN interface.
4) Port --> This is the port the virtual server will listen on. It can be different from the port on your
servers are listening internally.
5) Virtual Server Pool --> Select the previously configured pool from the list.

After configuring server pool and servers, you should create a firewall rule to allow the traffic to the
servers and the ports they are listening on. Please refer to our KB article for detailed information.

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


* Case Study: Mettle SE at a Research and Education Institute in Kerala *

Vertical: Education/Campus
Geography: Trivandrum, Kerala

Client Profile:

This client is an autonomous research institute, established in 1971, with an objective to promote research,
teaching and training in disciplines relevant to development. The institute is considered to be one of the
foremost development economics research centers in the country. The core activities of the institute are
research, teaching and training. They conduct programmes affiliated to Jawaharlal Nehru University. Institute
has gained recognition from the University of Kerala as a center for its doctoral studies. Institute is
supported financially by the Government of Kerala and Indian Council of Social Science and Research.

Problems:

Institute is served by a single high bandwidth WAN link. LAN networks is not secured from Virus attacks from
the Internet as they don't have a gateway antivirus installed in their network. Secure WiFi service was to be
made available in the campus. Content Filtering is to be implemented to filter out unacceptable Internet
content and services as a part of the acceptable usage policy laid down by the management. Internet access log
needs to be maintained for the campus. They have servers deployed in their local area network which has to be
made available to authorised users on the Internet. Few users need access to the campus servers remotely.

Solution:

Mettle SE was deployed at the campus to handle their IT infrastructure needs. Solutions provided by Mettle SE
can be grouped into the following sections:

a) ISP Link Termination and Gateway Antivirus
b) Firewall and DMZ
c) NAT and PAT
d) VPN with RADIUS Server
e) Proxy Server and Content Scanning

a) ISP Link Termination and Gateway Antivirus

The Institute is served by a single ISP providing a high bandwidth link. Mettle SE is the terminating point
for the ISP link at the campus. Mettle SE is the gateway for all the computers and server on the campus
network. Mettle SE protects the LAN subnets and computers in the network from viruses, worms, trojans and
other malicious codes and threats from the Internet. Mettle SE updates its internal virus signature database
automatically over the Internet to provide maximum security for the campus network.

b) Firewall and DMZ

To provide optimum security to the computers in the campus, Mettle SE implements a security barricade. Campus
users are served by the campus LAN and WiFi subnets. Mettle SE Firewalls the LAN and WiFi subnets thus keeping
the computers connected to the Internet via Mettle SE safe and secured.

A DMZ also has been setup where their public access servers are kept. The purpose of a DMZ is to add an
additional layer of security to the institute's LAN, an external attacker only has access to hosts in the DMZ,
rather than the whole of the network. The publicly accessible servers are hosted in the DMZ. This setup allows
servers in the DMZ to service both internal and external network, while keeping the LAN safe from possible
threats from the Internet. IP traffic between LAN and DMZ is monitored by Mettle SE, thus keeping out suspect
and unauthorised traffic out of the LAN. In the unlikely situation that security of DMZ is breached, Mettle SE
would keep the LAN and critical machines secured.

c) NAT and PAT

Mettle SE provides Internet connectivity for Desktops, Laptops and Servers hosted in the corporate network.
Mettle SE is configured as the gateway for the computers on the LAN subnets. Manual Network Address
Translation (NAT) is enabled in Mettle SE to provide Internet connectivity to computers which require direct
access to the Internet. Content Scanning is skipped for such computers which connect to the Internet via NAT.
Mettle SE is set as the proxy server for other computers, for which Internet connection needs to be monitored
and controlled.

Port forwarding (PAT) is enabled in Mettle SE to allow an authorised user, to connect to a specific computer
in the LAN, over the Internet. Port forwarding transfers IP packets between the private IP addresses of the
computer on a particular port and a public IP address with a specific port. This ensures that a service in the
host computer can be accessed from the Internet but is secured.

d) VPN with RADIUS Server

A PPTP VPN service has been enabled in Mettle SE to allow authorised users to connect to the campus network
for administrative and academic purposes. Users are issued with unique username and password combination with
which they can connect to Mettle SE from anywhere in the world. VPN user credentials are stored in a RADIUS
server which is linked with Mettle SE. VPN users trying to connect to Mettle SE is authorised against the user
credentials stored in the RADIUS server. Valid users are allowed to connect after verification. Mettle SE VPN
service also allows users to access campus resources irrespective of their location, without compromising
security.

e) Proxy Server and Content Scanning

Routing all IP traffic from the local subnets to the Internet via a proxy service has its advantages. A
research institute would like their students and faculty to use the Internet according to the acceptable usage
policy (AUP). Mettle SE helps the network administrator to enforce AUP with its Proxy Server and Content
scanning engines. The Internet usage policy is best if enforced at the point of presence of the ISP links,
which ensures that content is filtered before it is passed on to the LAN.

Mettle SE has been serving the institute reliably and efficiently since its deployment, meeting the needs of
the management and the system administrators. Mettle SE has proved its Mettle once again, serving our client
reliably round the clock.





--
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.