Security | Network Gong (yiming@security.zz.ha.cn)
Core member of China Telecom Network security Group
December 2001
Through the Httptunnel technology of this paper, while escaping the shield of firewall and the tracking test of the system, we can see that the network security depends only on some or some means is unreliable, while the blind dependence on the safety system often causes huge security hidden trouble. It is hoped that this paper can arouse the administrator's thinking on the network security protection system.
What is an HTTP hidden channel
What is LAN security, how can the system administrator ensure the security of LAN? This is a constantly changing concept of security, for a long period of time, in the LAN and the outside world to place a firewall, strict control of the open port, you can master the security initiative to a large extent, easy to control the network and other users can use the service. For example, only 80, 532 ports are open on the firewall, and malicious people, both inside and outside, will not be able to use some of the services that have proved more dangerous.
However, it should be noted that the firewall in a sense is very stupid, the administrator of the firewall and the excessive reliance on the resulting slack will inevitably form a major security risks, as a proof, "channel" technology is a good example, this article is to discuss.
So what is a channel? The so-called channel here refers to a way of communicating around the firewall port shielding. Packets at both ends of the firewall are encapsulated in the packet type or port allowed by the firewall, and then through the firewall and the End-to-end communication, when the encapsulated packets arrive at their destination, the packets are restored and the restored packets are delivered to the corresponding service. Examples are as follows:
A host system after the firewall, protected by the firewall, firewall configuration access control principle is to allow only 80 port data access, B host system outside the firewall, is open. Now suppose you need to go from system A to Telnet to B. Using normal Telnet is certainly not possible, but we know that only 80 ports are available, so this time using the Httptunnel channel is a good idea, as follows:
On the A machine, a tunnel client side is allowed to listen for an unused, arbitrary port on this machine, such as 1234, while directing data from Port 1234 to the 80 port on the remote (b-Machine) (note, 80 ports, firewall allowed to pass), Then a server on the B-machine, also hooked on port 80, also directs 80 ports from the client forward to the local Telnet service port 23, so OK. Now on the a machine Telnet native port 1234, according to the packet will be forwarded to the target port 80 of the B-machine, because the firewall allows the data through 80 ports, so the packet flow through the firewall, to B machine. At this point, the B-machine is listening on the 80-port process received packets from a, the packet will be restored, and then returned to the Telnet process. When the packet needs to be returned from B to a, it will be loopback by 80 ports, which can also pass through the firewall smoothly.
In fact, the concept of tunnel has been in effect for a long time, and it is likely that readers have used similar techniques, such as the following URL http://www.http-tunnel.com. It is a professional provider of tunnel services, through their online tunnel server, users in the LAN can use the firewall screen icq,e-mail,pcanywhere, aim,msn, Yahoo,morpheus, Napster and so on a lot of software. We see that there are icq,napster and other software, I believe that many of our readers have used the ICQ,OICQ of the proxy and so on, in fact, they are the same principle.
What is Httptunnel
As a practical example, we introduce a channel software used in "Non-public domain", httptunnel. On the Httptunnel home page (see Resources), there is one end to this conversation,
Httptunnel creates a bidirectional virtual data connection tunnelled in HTTP requests. The HTTP requests can be sent via a HTTP proxy if so desired.
This can is useful for users behind restrictive firewalls. If WWW access is allowed through a HTTP proxy, it's possible to use Httptunnel and, say, Telnet or PPP to connect to a COM Puter outside the firewall.
From this note we can see that it is a proof of the tunnel technology that we are going to introduce today, and we'll give you a general introduction to its use.
Httptunnel's current relatively stable version is 3.0.5, which supports a wide variety of common UNIX systems, including window platforms. It can be downloaded from the relevant site (see Resources), its installation is relatively simple, as install file to do it, not described here.
After installing the entire software, we will get two key files, HTC and Hts, where HTC is the client (c), and HTS is the server (s) end, let's look at how to use it specifically.
Suppose there is a (domain name client.yiming.com) machine, B (domain server.yiming.com) machine, two machines are Solaris environment, a machine in the firewall protection, B machine outside the firewall, the firewall administrator control access rules, only allow 80 and 53 ports for incoming and outgoing packets. And our task is to use Httptunnel from a machine to telnet to B machine, through the restrictions of the firewall. The operation is as follows:
First we start the client side on a, and the command is simple:
Client.yiming.com#htc-f 1234 server.yiming.com:80,
System back to the prompt, we can now use Netstat-an to see more than 1234 ports in the system to listen *.1234 *.* 0 0 0 0 LISTEN
Then we start the server side on the B-machine, and the command is as follows:
Server.yiming.com#hts-f localhost:23 80
System back to the prompt, now we use Netstat to see *.80 *.* 0 0 0 0 LISTEN
The 80 port is listening, and it should be noted that if the system itself is running a Web service (the 80 port itself is listening), it will not affect the Httptunnel's work.
Ok,server and the client side are all started, we can start our "channel" test, on the client.yiming.com to execute the following command to see:
client.yiming.com#telnet localhost 1234
Trying 0.0.0.0 ...
Connected to 0.
Escape character is ' ^] '.
SunOS 5.7
This is yiming ' s private box! Any question,contact me with yiming@security.zz.ha.cn
Login
See the B-Machine login prompt, enter account password to see if the work is normal?
Login:yiming
Password: (omit here;))
sever.yiming.com# ls
Bak check go httpd lost+found MRTG run soft WG
Ok! Work properly, and normal telnet is no different.
By looking closely at the whole process, you will find that trying 0.0.0.0...,connected to 0 is displayed at the very beginning. Instead of trying server.yiming.com...,connect to Server.yiming.com, it's intuitive to see that the client side is forwarding 1234 packets to the native 80 port. (and then forward to the far end) instead of directly connected to the remote B-machine.
The above is a more intuitive test, in order to further verify between server and client is not through 23-port communication, we grab packets to see. We have a grab tool tcpdump in the server (see Resources) look at that.
Server.yiming.com#tcpdump Host Client.yiming.com
Tcpdump:listening on HME0
14:42:54.213699 client.yiming.com.51767 > Server.yiming.com.80:s 1237977857:1237977857 (0) win 8760 (DF)
14:42:54.213767server.yiming.com.80 > Client.yiming.com.51767:s 1607785698:1607785698 (0) Ack 1237977858 win 8760 ( DF)
14:42:54.216186 client.yiming.com.51768 > server.yiming.com.80:. Ack 1 win 8760 (DF)
14:42:54.218661 client.yiming.com.51768 > Server.yiming.com.80:p 1:44 ($) Ack 1 win 8760 (DF)
14:42:54.218728 client.yiming.com.51768 > Server.yiming.com.80:p 44:48 (4) Ack 1 win 8760 (DF)
is limited, it's just a little bit of data in the results, but that's the point, we see that the server and the client have a smooth three handshake, then push the data, and the traffic does go 80 ports. It's kind of interesting.
Look is out, but it is not straightforward, in the end what Ah, we slightly change the operation of the tcpdump, further to see whether the data Telnet is encapsulated in 80-port packet transmission?
Oh, this time clearer, above should be a LS command output results, you can clearly see the results of Telnet! Sure enough, Telnet data is in the 80-Port packet!
Security problems brought by Httptunnel
Write here, we can imagine, if the administrator completely trust the firewall, then in a network with such a hidden trouble, what will happen?
We can see that over the years, the reliance on firewalls has been included in the top 10 security issue of Sans.
That being the case, a natural question arises: can this httptunnel behavior be found?
First of all, we think of the use of intrusion detection system, in the current network security design, firewall plus intrusion detection system is a more popular security linkage configuration, since Httptunnel bypass the firewall, then the IDS system? Let's take a look at the test.
In the following test, we will use the IDS system as snort, version 1.8.2. (see Resources) This is the well-known open source IDs system, described in its description as a lightweight, cross-platform intrusion detection system, in December 2001 in the United Kingdom Independent Test laboratory NSS (see Resources), Defeated all opponents of the commercial IDS system including the Iss,cisco SECURE ids,ca etrust,cybersafe centrax,nfr. Interested readers can also look at this report named Open Source Mounts IDS Challenge (see Resources).
Okay, here's a general introduction to snort, so let's take a look at the results, and Snort has Baussan the data captured by the entire test process as follows:
[**] Web-misc Whisker Splice Attack [* *]
12/02-14:42:54.389175 client.yiming.com:51767-> server.yiming.com:80
TCP ttl:251 tos:0x0 id:3327 iplen:20 dgmlen:42 DF
ap*** seq:0x49ca0ba7 ack:0x5fd4dce3 win:0x2238 tcplen:20
=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+
We saw that Snort had a web-misc whisker splice attack on the captured packets, but the attack didn't happen and Snort was unaware of the tunnel packet. This allows snort to have two problems with the IDS system at the same time, false positive,false negative.
This is also normal, because this is also based on the signature of the IDs system, at present, the large number of IDs system including well-known commercial software ISS,NFR are based on the signature, that is, the system maintains a set of specific attack packets data mode signature. When the system is working, check the contents of the data packet, compare with the data pattern signature in the database, and if it is the same as the signature of an attack pattern, then it is judged that some kind of attack has occurred.
From this we can see that there are some obvious problems: the reliance on signatures inevitably results in two outcomes, false negative, false positive. That is to say, it is easy to understand that when a new attack mode occurs, there is no corresponding data signature in the IDS system, so it is not possible to capture the corresponding attack packets, false negative. At the same time, too much reliance on signature patterns can easily be erroneously reported, as we have shown in the above example. At the same time, the reliance on data signature reduces system performance to a certain extent-all packets need to be compared with IDs system signatures. (See Resources)
In addition, the signature based IDs system itself may be attacked by the signature, an example is stick, the author of the program using the IDS system for signature matching work principle, send a large number of attack characteristics of data packets to the IDS system, so that the IDS system itself processing capacity beyond the limit, This causes the IDs system to be unresponsive. According to author Coretez Giovanni, running for 2 seconds stick can crash the famous commercial IDs system ISS real secure. From what we've seen, total reliance on IDs systems is also risky. (See Resources)
Some ideas to solve
It seems that relying on the IDs at hand is not aware of this behavior, then there are other ways? Let's take a closer look at the Httptunnel packets intercepted during the event.
The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion;
products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the
content of the page makes you feel confusing, please write us an email, we will handle the problem
within 5 days after receiving your email.
If you find any instances of plagiarism from the community, please send an email to:
info-contact@alibabacloud.com
and provide relevant evidence. A staff member will contact you within 5 working days.
