|
TCP Tunnels, Where =
University and=20
Security Policy Breaks Down
Jonathan Sloop
December =
14,=20
2000
Problem: TCP Tunnels are =
circumventing=20
University policy restrictions. Port restrictions on our firewall =
edge=20
device had been blocking outbound Napster and similar file sharing =
services. Now the word on TCP Tunneling is spreading among users =
and is=20
providing them with unauthorized Internet file sharing, and =
potentially=20
giving hackers a backdoor to our private network.
Situation: Our University does =
not have an=20
official written policy against Napster or Napster like Internet =
file=20
sharing programs, however we have not opened the associated ports =
on our=20
firewall to allow default access. The reason for this is fear. =
Fear of the=20
uproar from the students if we officially blocked Napster. Fear =
that if=20
Napster were allowed to run freely on our campus the network would =
grind=20
to a halt. Collision domain would collide and our Internet =
connection=20
would seize. This University has no desire to become a sensor on =
how the=20
Internet is used, but at the same time we feel some responsibility =
to=20
provide reliable consistent access for students educational =
endeavors.=20
Background Information: For the =
past=20
several years the University has provided desktop computers in =
every dorm=20
room. The total number of University owned PCs on campus is =
quickly=20
approaching 4000. There are no restrictions on students adding =
their own=20
PCs to the network. Our Internet connection is currently a =
throttled=20
10Mb/s on an OC3 line. This can be quickly opened to 45Mb/s if =
there is=20
justification and someone is willing to pay the additional =
tariffs.=20
Several years ago we were a 12 class C network desperately trying =
to=20
figure out how to keep 4000 computers on the Internet with only =
3000 or so=20
IP address. We also had several unauthorized servers on campus =
providing=20
Web, Ftp, Telnet, etc. to the Internet. There were even cases of =
former=20
students leaving connected servers running commercial web =
applications in=20
dorm rooms of friends. Why not, the University was proving free =
Internet=20
access. Even with a policy against student servers no one was =
attempting=20
to enforce it. One way identified to help curb these problems was =
to=20
install a firewall.
Firewalls and Universities are kind =
of like=20
trying to mix oil and water. The University’s faculty will =
maintain that=20
open access is necessary for research and educational endeavors. =
The=20
student’s will insist it is their constitutional right under =
the first=20
amendment to do what ever they want. In the end networking people =
have an=20
uphill battle. Convincing all interested parties that it’s =
necessary to=20
spend tens of thousands of dollars funding a project that =
conflicts with=20
the faculty and student’s opinions isn’t easy. For =
this University it took=20
outside influences to finally make a commitment to a firewall =
project.=20
Along came the FBI, remember those =
unauthorized=20
servers. Apparently some of those servers were used to bounce =
attacks at=20
some high profile sites out on the Internet. The FBI promptly =
introduced=20
the terms Firewall and Network Security to the University’s=20
decision-makers. Still nothing was done, no budgets were created, =
almost=20
no reaction at all, but the idea was rolled around. This new =
concept=20
called Network Security might be worth looking into, sometime, =
maybe=20
later? Then came the Audit, the auditors took a look around and =
said, how=20
are you protecting your mission critical data, students grades, =
protecting=20
everyone’s privacy? How are you keeping the bad people out =
there on the=20
Internet from connecting to your data systems? How are you keeping =
students form accessing sensitive data? Where are your=20
firewalls?
The Networking Staff had already =
done extensive=20
research into firewalls and network security in general. We knew =
that we=20
could use NAT (Network Address Translation) sometimes referred to =
as IP=20
masquerading, to solve our IP shortage.(1) We would simply use a =
single=20
external IP address and a class A private internal address scheme. =
We=20
would use the private or non-routable class A network 10.0.0.0 =
with over=20
16 million IP addresses on our private network. Non-routable IP =
addresses=20
are covered under RFC 1597.(2) With more than enough IP addresses =
to go=20
around and the added security of a non-Internet routable address =
set to=20
boot. The only down side to NAT would prove to be a requirement =
from our=20
state funded ISP to log every connection to the Internet, ouch! =
They=20
understandably want to retain the ability to collect forensic =
evidence in=20
the event some unscrupulous University user were to attack an =
Internet=20
site without proper authorization. Students are often very =
surprised to=20
hear that the first amendment does not protect them from their own =
malicious activities over the Internet. Unfortunately our =
connection logs=20
are one to two gigabytes almost daily. This means to keep logs for =
30 days=20
we need somewhere between 40 and 60 gigabytes of active storage. =
Permanent=20
storage is an even bigger problem, maybe no one will ask for last =
month’s=20
logs.
Installing a firewall would help us =
prevent=20
External Hosts (People on the Internet) from connecting to servers =
setup=20
by students on the private network. It should be noted that we did =
have an=20
IT staff member setup a Linux box that was hacked from the =
Internet, then=20
used to leapfrog an attack to another high profile web site(so the =
students aren’t always to blame). That site graciously =
called the FBI on=20
us, that was our second visit, actually I think they just called =
this=20
time. By not allowing external hosts to initiate connections to =
computers=20
on the private network, we believed we would be protecting our =
Internal=20
users form the big bad Internet, and preventing unauthorized use =
of our=20
Internet connection. Building on the concept of a Layered Defense, =
(for=20
those of us in plausible denial, "a defense in depth") there are =
two=20
mechanisms that we believed would prevent an External to Internal=20
connection. The first being NAT, it is literally impossible =
(assuming all=20
routers in the hop across the Internet are configured correctly) =
to=20
connect to a computer on our Private network via its 10.0.0.0 IP =
address.=20
Even if an intruder somehow knew the IP address of one of the PCs =
on our=20
private network the first router on the Internet the Hacker hit =
would drop=20
the packet. With a NAT/Firewall, from the External network’s =
point of view=20
all 4000 computers appear to have the same IP address. So if a =
Hacker were=20
to attempt to connect to a PC on the Private network using the =
External IP=20
address of the NAT/Firewall they would simply get dropped. The=20
NAT/Firewall would not know which of the 4000 Private PCs it was =
supposed=20
to forward the packets to, so it gets rid of it. The second is the =
rule=20
base or policy list on the Firewall. If the rules say don’t =
allow External=20
hosts to connect to Private hosts it won’t let them. TCP =
Tunneling has=20
proven to defeat both of our Layered Defenses.
For the most part when you install =
a proxy type=20
firewall its default configuration has all TCP and UDP ports =
blocked. I=20
have often heard this referred to as, "What’s not explicitly =
allowed is=20
denied." All of the software firewall products I have used =
followed this=20
simple rule. Our University policy for port opening =
reads:
External and =
Internal Private=20
Networks:
Any identified =
and approved=20
ports will be opened for outgoing IP TCP/UDP traffic, Internal =
Private=20
host requests will be allowed to pass through the firewall, =
their=20
immediate response will be returned to the Internal Private =
requesting=20
host. All Internal Private hosts will appear to have the IP =
address of=20
the external firewall network interface as seen by the External =
network,=20
this is referred to as Network Address Translation (NAT). All =
incoming=20
traffic from the External network that is not in response to an =
Internal=20
Private host request will be blocked.
External and =
Public=20
Networks:
Requests from =
External network=20
hosts will be allowed to access public services on public =
servers=20
through associated ports (i.e. web services through port 80 =
TCP).=20
The procedure for =
requesting=20
that a port or service be allowed to pass through the firewall =
from the=20
Internal Private or External network is to send an email to the =
Firewall=20
Administrator at administrator@OMITED.edu. The request will be=20
researched then submitted to the Network Security Council for =
review and=20
approval.
Note: The =
firewall is designed=20
to protect Internal Private users from IP based attacks =
originating from=20
the External network and therefor regrettably limits some =
Internet=20
services.
TCP Tunneling: There has been =
much said=20
about the legal ramifications of passing copyrighted material =
within=20
Napster’s community and its associated software. Eventually =
the courts=20
will decide whether or not Napster will be allowed to conduct =
business as=20
it has from its inception. The Internet has long been an effective =
means=20
of stealing intellectual property. Crackers and Hackers have had a =
long=20
history of disregarding copyright laws, Napster is seams is just a =
means=20
to that end. I think in the end it will come down to whether =
Napster=20
knowingly allows its users to break copyright laws, and I =
don’t see how=20
they can’t. The University quite frankly, just wants to =
protect its=20
bandwidth, therefore no Napster.
What is Napster up to? From behind =
our=20
firewall, from a technical perspective, not much, that is until =
you=20
tunnel. I used the command ‘netstat –a –n =
1’ at a DOS prompt to watch what=20
connections and ports were active during a Napster session. =
Netstat with a=20
‘–a’ will display the active connections, =
‘-n’ will keep the application=20
from trying to resolve Foreign (IP) Address to a Domain Name, and =
the ‘1’=20
is the number of seconds till the data is refreshed. Napster v2.0 =
BATA 7=20
first makes a connection to 64.124.41.19:8875/TCP SYN_SENT then=20
64.124.41.17:8875/TCP SYN_SENT.(3) Because our firewall does not =
have a=20
port open for 8875 TCP the first SYN to 64.124.41.19 gets no =
response. So=20
the Napster program sends a second SYN to 64.124.41.17 on the same =
port,=20
this also gets to the firewall and is dropped. Napster apparently =
gives up=20
and prompts the user with an, "Unable to Connect to Server!" =
message.=20
Note: I have found that Napster has several IP addresses within =
the=20
64.124.41.0 address space that they use for connections, so if you =
try=20
this you may get slightly different results. For a longtime this =
has been=20
sufficient to discourage users at our University from using =
Napster and=20
freeing us from potential bandwidth problems not to mention legal =
issues.=20
We are sort of taking the easy way out. By not having an official =
policy=20
against Napster we haven’t come under any scrutiny for =
censuring web=20
sites, and Napster did not work.
Rumor has it that our students have =
figured out=20
a way around the closed port 8875 policy and are now readily using =
Napster. It looks like the majority of our growing Napster users =
are using=20
a TCP Tunnel to circumvent the blocked 8875 port. I ran the =
‘netstat –a –n=20
1’ command at a DOS prompt then started the HTTP-Tunnel =
Client v2.3.1587=20
(Beta), I downloaded from their site.(4) It clams to be free but =
never the=20
less relentlessly splashes banners. The first thing I noticed is =
that=20
Netstat showed several connections to Foreign Addresses via port =
80 TCP.=20
One of the connections looked like the one HTTP-Tunnel Client was =
using to=20
connect to its server on the Internet, 64.224.202.127:80 TCP. I =
did a=20
Tracert to this address and found its DNS entry to be=20
mail.rentmontreal.cc, not what I expected. I stopped the tunnel =
then=20
started it again, same result. I wonder if they know they have =
been coded=20
into this application.
To get Napster to use the =
HTTP-Tunnel Client=20
you must configure Napster’s Preferences. Within the Napster =
application=20
select the proxy tab. Set the proxy type to ‘SOCKS5’, =
Proxy IP to=20
‘127.0.0.1’, the port to ‘1080’, and =
select ‘Download files through=20
proxy.’ With the HTTP-Tunnel running I started a connection =
with Napster.=20
Watching ‘netstat –a –n 1’ I saw a new =
series of port activity; Foreign=20
Address of 64.224.202.115:80 TCP, a Local Address of =
127.0.0.1:1080 TCP to=20
a Foreign Address of 127.0.0.1:1766 TCP and another on 1771 TCP, a =
Local=20
Address of 127.0.0.1:1771 TCP to a Foreign Address of =
127.0.0.1:1080 TCP.=20
Meanwhile the HTTP-Tunnel Client shows that it is establishing a=20
connection with 64.124.41.171:8875 (Napster).
Connection =
Flowcharts:
Normal Napster, behind our =
Firewall;
 =20
Napster via the =
HTTP-Tunnel;
SOCKS5: SOCKS5 is an =
application offered by=20
NEC Inc. marketed interestingly enough as a firewall.(5) The =
following is=20
an excerpt from NEC’s FAQ page. (Grammatical mistakes are on =
NEC’s part, I=20
am sure I have my own)
"SOCKS is networking proxy =
protocol that=20
enables hosts on one side of a SOCKS server to gain full access =
to hosts=20
on the other side of the SOCKS server without requiring direct =
IP=20
reachability. SOCKS redirects connection requests from hosts on =
opposite=20
sides of a SOCKS server. The SOCKS server authenticates and =
authorizes=20
the requests, establishes a proxy connection, and relays =
data."(NEC)(5)=20
I find myself asking the question, =
"Why is=20
their firewall defeating my firewall." SOCKS, simply allows you to =
send=20
all port traffic through one designated port. SOCKS, is similar to =
a VPN=20
connection without encryption (planed for the next version). In =
our case=20
SOCKS appears to be built into the HTTP-Tunnel, however =
HTTP-Tunnel may=20
have its own proprietary code that acts very similar to SOCKS. =
Here is how=20
it works, HTTP-Tunnel is installed and running, Napster is =
configured to=20
use SOCKS5 as its proxy server with an IP address of 127.0.0.1 =
port 1080=20
TCP. HTTP-Tunnel listens to port 1080, picks up the packets sent =
to=20
127.0.0.1 then forwards them to the HTTP-Tunnel Server out on the =
Internet=20
via port 80. Once the HTTP-Tunnel client/server relationship is=20
established anyone within the Napster community will have file =
access to=20
this computer. Theoretically that access is restricted to the =
folders the=20
user has identified in the Napster preferences.
Conclusion: What this means =
is our=20
current policy of blocking applications via their TCP/UDP port is=20
beginning to look futile (that probably wont surprise anyone). =
We’ve had=20
suspicions this was possible when we installed the firewall, but =
chose to=20
ignore the problem until it became an issue. We dream someday of =
having=20
the time and money to be proactive, but for now reactive is the =
norm. When=20
Napster was still fairly new I was able to open a port other than=20
Napster’s default 8875, connect to a proxy server than =
connect to Napster.=20
The port I opened on the firewall was something like 1750/TCP. I =
don’t=20
remember the specifics, but the point is that we knew tunneling =
through=20
the Firewall was possible early on. At a minimum we decided never =
to open=20
1750. Immediately I suspected it would only be a matter of time =
before=20
either Napster changed their software or someone would develop a =
proxy=20
server that used port 80 to tunnel through. Unfortunately it =
happened, and=20
the students have figured it out.
If you read between the lines there =
is a bigger=20
problem than Napster. What if a student has setup a =
Napster/HTTP-Tunnel,=20
and someone on the External network uses one of these as a =
backdoor to=20
your Private network. How could they do this? Maybe disguise a=20
back-orifice client as an MP3 file. Napster has a routine that =
only allows=20
MP3/WMAs to pass through the community, so you would need to be =
creative.=20
After the host MP3 is downloaded and played the executed =
back-orifice=20
sends a short message to its server via port 80 or even the =
existing=20
HTTP-Tunnel running on that computer. The back-orifice server =
responds and=20
your private network is compromised. There may even be a way to =
use the=20
HTTP-Tunnel directly to gain access to the Private network, =
perhaps an=20
unscrupulous HTTP-Tunnel server operator. There is another =
Internet=20
application GNUTELLA, that maybe a much greater risk. Sort of a =
Napster,=20
HTTP-Tunnel, VPN solution all raped into one easy to use free =
application,=20
but that’s another paper.
Will we finally ban Napster at this =
University?=20
Will we ban Tunnels? I think the tunnels are far more serious than =
the=20
potential bandwidth problem associated with Napster. We are =
currently=20
looking at setting up prioritization rules for traffic passing =
through our=20
Cisco routers on both sides of our firewall. I strongly believe =
that to=20
truly secure a network every aspect of that network must be under =
control.=20
Computers would have a fixed load-set that could not be changed by =
the end=20
user. The Internet would be accessible, however applications would =
not be=20
downloadable. Only computers authorized on the network would be =
connected=20
to the network. There are reasonable technologies and methods for=20
implement this, however this does not fit the end users =
expectations,=20
especially at a University. Our users would rather do what they =
care and=20
have someone else consider the risks. As for TCP Tunnel servers =
using=20
ports you can’t block like port 80, find them, find them =
all, and block=20
there IP addresses. Just remember to add this to your network =
security=20
policy.
References =
1. http://www.=
cis.ohio-state.edu/htbin/rfc/rfc1631.html,=20
K. Egevang, P. Francis, May 1994
2. http://www.isi.edu/in-no=
tes/rfc1597.txt,=20
Y. Rekhter, B. Moskowitz, D. Karrenberg, G. de Groot, March=20
1994
3. http://http://www.napster.com/, =
Napster,=20
Copyright 2000 Napster Inc.
4. http://http-tunnel.com/n=
ewpage/icqp.htm,=20
HTTP-Tunnel, Copyright I-SIGHT Design 2000.
5. http://www.socks.nec.com/=
socksfaq.html,=20
NEC, Copyright=20
1996-1999, NEC USA, Inc. |
