The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

[Phrack] Alternative Thinking in H.323 Capable Firewall Design (security sound)

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>
Ключевые слова: security, sound,  (найти похожие документы)
-------[ Phrack Magazine --- Vol. 9 | Issue 55 --- 09.09.99 --- 17 of 19 ] Subject: [Phrack] Alternative Thinking in H.323 Capable Firewall Design --------[ Dan Moniz <> ] To wit: "Thus it is said that one who knows the enemy and knows himself will not be endangered in a hundred engagements. One who does not know the enemy but knows himself will sometimes be victorious, sometimes meet with defeat. One who knows neither the enemy nor himself will invariably be defeated in every engagement" - Sun Tzu Chou Dynasty, Warring States period of China (circa 403 BC). "If your own power of insight is strong, the state of affairs of everything will be visible to you. Once you have obtained complete independent mastery of martial arts, you will be able to figure out the minds of opponents and thus find many ways to win. This demands work." - Shinmen Musashi no Kami, Fujiwara no Genshin (Miyamoto Musashi) Tokugawa Era, Third Tent Government of Japan (circa 1643 AD). "Better one blow with a pickax than a thousand taps with a mattock." - Tran Thai Tong (first king of the Tran Dynasty) Tran Dynasty of Vietnam (1225-1400 AD) Abstract: This paper illustrates some basics about the H.323 standard, then touches on H.323 security in the context of network mapping, and posits a possible solution, and then compares it with other existing ideas, and ends by developing a basic idea framework for said solution. Extended Abstract: Using H.323 applications leads to severe firewall security and scalability issues on all sides. This paper describes a compromise solution, between using HFCI (a one-time Internet Draft work-in-progress [now since expired]) and a generic but equally function solution such as SOCKS. The prime points focused upon include network disclosure and fundamental access control, as well as managing the very complicated nature of H.323 connections and contents. The paper finishes by presenting an annotated reference list and encourages the reader to investigate further into the issue. The author also proposes to develop the proxy noted in the paper and set-up his goals for the project, with source code and other notes to be released at a later date in a follow-up paper. Introduction: H.323, an ITU-T standard, is the dominant standard for Voice-over-IP (VoIP) that the telecommunications community is considering to build IP based data networks for telephony. The multiplexing ability, the self-healing nature of IP networks, and the potential for new value-add services are the main reasons telephony is being merged into the data sphere. All IP networks are insecure. Because of the ease in which rouge elements could be introduced, open network designs are obviously not feasible. Closed network designs also benefit no one, especially when using H.323 since the standard is very intensive in the number of connections and the care with which they must be handled. Further information about H.323 is available in the resources we denote at the end of this paper. We assume a basic familiarity with the standard and common implementations and H.323 applications. Issue: H.323 is very port intensive, necessitating four UDP streams (two for RTP and two for RTCP), and also has specific guidelines for which ports these have to be. The RTP ports must be adjacent even numbered ports, while the RTCP must be adjacent odd numbered ports. These streams are also very ephemeral, so maintaining correct state is a large issue with the UDP end. H.323 also has TCP connections involved with the H.323 call setup and associated parts of the call. This standard was never intended to connect large scale networks, handle issues of local number portability, or to interconnect to untrusted networks. When an untrusted network is used in an H.323 peering context, care must be taken to note that dial plans are encoded in ASN.1, and the IP network architecture must be communicated to every gateway and gatekeeper that will be receiving and controlling calls. For a paranoid RBOC or LEC, this is unacceptable. Therefore, NAT and ASN.1 cleansing must be performed. A viable way to perform accounting of CDR, as well as VAS must be taken into account, but it is out the scope of this paper. Common solutions for H.323 involved opening all UDP ports, obviously a very scary situation. In 1997, Intel wrote a whitepaper (noted in the bibliography) which expresses the issues involved in proxying H.323 in an effective, secure fashion. Recently, an Internet Draft authored by S. Mercer and A. Molitor along with M. Hurry and T. Ngo described the H.323 Firewall Control Interface (HFCI). This Internet Draft expired in June 1999, and it was referenced here only as a work once in progress. The HFCI posed the idea of developing a generic API for proxying H.323 in a specialized H.323 Gateway system. The overall idea was to develop the HFCI in such a way that H.323 would be able to open up "pinholes" in the firewall rather than necessitating an all-open state on all UDP ports. Current research and thought into the issue with people in the industry points to a growing deprecation of HFCI as a specialized proxy solution and using something more generic like SOCKS, since the design of HFCI replicates much of SOCKS functionality. The author poses the idea that a gateway more in the style of FWTK is an agreeable and arguably more manageable solution than either a customized interface or a generic use proxy solution. The advantages to this model, later explained in detail in this paper, include a compromise between a completely generic solution and tailored gateway, easy integration with existing firewall installations, and retention of central control. Synthesis: Having said the above, a (very) brief explanation is needed. As D. Brent Chapman and Elizabeth D. Zwicky illustrate on pp. 200-205 of _Building Internet Firewalls_, some specific differences exist between SOCKS and FWTK style proxying systems. For the purpose of this paper, it is assumed that the details of the proposed HFCI project replicate much of SOCKS' functionality applied to a specific environ (that of H.323 and pals), which is what research and current discussion with industry engineers suggests. Furthermore, some are of the belief that an RFC standard like SOCKS benefits H.323 in a more direct fashion, seeing no need for a specialized stand-alone solution, and that SOCKS is malleable enough to handle H.323 with a minimum of hassle. This is sound thinking. Organizations running SOCKS based proxies could integrate H.323 applications into their enterprise without having to support an entirely new product or interface. By using existing standards, a lot of the overhead is cut down, with the trade off of a little custom configuration. Returning to the differences inherent in SOCKS and FWTK, the following comparative checklist is provided: > SOCKS is a generic serv-all solution. Every SOCKS-ified client runs through the SOCKS proxy and connects to the server at the backend. > FWTK uses multiple, smaller, application-specific proxies. Clients connect to their respective FWTK proxy and then connect to the server at the backend. > SOCKS relies on modified client code for use with SOCKS. > FWTK provides (out-of-box) the ability to use modified client code or modified user procedures for some of the common applications (such as FTP) and specifies one or the other for other (such as modified user procedures only with telnet). > SOCKS is an RFC standard > FWTK is an unsupported toolkit distributed under a liberal license from TIS. There are other differences as well -- the reader is encouraged to download freely available copies of both systems and tinker. The idea is that H.323 lends itself to a FWTK style application gateway; that is, a gateway could be coded to fit into the FWTK in such a way as to support H.323. This provides some considerable benefits over using either HFCI or SOCKS: > FWTK has established the philosophy that a small, provably secure proxy for each common service works well. > FWTK's methodology provides for a easily managed firewall setup. HFCI is a completely new interface, while FWTK and it's commercial derivative, Gauntlet, have been tested in the field. > Load balancing systems could be put in place to have multiple-system firewalls. Since the FWTK construction is to have an application specific gateway rather than a generic catch-all gateway, one could implement a number of machines, one handling each particular application and its proxy. This would especially make sense in large organizations who have to field a large amount of H.323 traffic. > FWTK could be implemented on both (all) ends of the network. Incoming proxies can hand off traffic to the important internal H.323 infrastructure which in turn could hand off the "finished product", such as it is, to outgoing only proxies (although this is not necessarily a FWTK specific idea, and could be applied to SOCKS). > FWTK's model leans itself to central control, but also to survivability and fault tolerance. Having a "one proxy to one app" structure ensures that should, say, ftp-gw go down, h323-gw (hypothetical name) would stay up. > FWTK promotes a specialized focus in each gateway by the fact that it uses the "one proxy to one app" method. This means that a highly effective proxy could be coded to support H.323 in the most efficient manner possible, which was one of the goals of the HFCI proposal, and still integrate nicely with common firewall solutions, which is behind the drive to use SOCKS. Issues such as the ability to do the required on-the-fly packet destruction/reconstruction to avoid network disclosure are addressed in this paper only in the context that the proposed FWTK-model proxy solution will accomplish this goal, given fast enough hardware and optimized routines. The real bottleneck here is in the packet engine. SOCKS also provides this ability. Hardware issues and the amount of projected traffic are the main variables. The author believes, however, that this proposal shows an acceptable compromise between adopting a completely new and specialized interface (such as HFCI) and a overly generic solution (SOCKS) whilst still staying within the bounds of traditional firewall methodology. A project is underway now between the author of this paper and a valued colleague to develop the solution proposed in this paper and to test it to see if the assumptions made above hold true. Barring licensing restrictions and the expanse of time, a new paper will be published disclosing the project's results and any new findings, along with the source code to the proposed proxy at the conclusion of the endeavor. As always, comments are welcomed and encouraged on this work and on the idea in general. Caveats: This paper does not touch on such other standards competing with H.323 such as SIP. While research was indeed conducted on SIP and other related standards/protocols, they remain outside the scope of this paper. SIP may very well be a better choice for those who wish to enter the world of VoIP services. The author encourages all readers to research the field and develop their own solutions. This paper does not expressly touch on the issue of full network disclosure, one of the bigger concerns when using H.323. The reader is directed to the reference list for suitable material. Having said that, the dual gateway architecture (one handling in traffic and one handling out traffic) lends itself easily to suffice in this concern. Again, the main problem is in handling the ASN.1 issue, and its lack of fixed byte offsets. The author suspects this becomes a larger issue only in high-yield situations, and that new packet engines are being developed to optimize performance as well as correctness which will work to make this less of a concern. References: 1. _H.323 Peering Proxies_ by Kiad <> (URL: This paper lays the groundwork for the network disclosure issue and also explains the troubles with ASN.1. Kiad was originally contacted to co-author this paper, but elected to aid the author with supplementary research and act as a sounding board, which proved invaluable. Kiad also contributed by lending her expertise to some of the material above. Without her, this paper would not exist. This work is dedicated to her -- thank you so much, Kiad. 2. _Building Internet Firewalls_ by D. Brent Chapman and Elizabeth D. Zwicky. (ISBN: 1-56592-124-0) Used as a canonical reference for the differences between SOCKS and FWTK. Unwittingly served as impetus for the FWTK model idea. 3. _The Problems and Pitfalls of Getting H.323 Safely Through Firewalls_ by Intel. (URL: (URL: (Also: Preliminary whitepaper describing the core issues with H.323 and interaction with firewalls. 4. _H.323 Firewall Control Interface (HFCI)_ by S. Mercer, et. al. (I-D title: <draft-rfced-info-mercer-00.txt> Please note that this I-D expired in June of 1999 and is referred to here only as a work once in progress, not as an official standard. 5. The _Art of War_ by Sun Tzu (translated by Ralph D. Sawyer) (ISBN: 0-8133-1951-X) 6. _The Book of Five Rings_ by Miyamoto Mushashi (translated by Thomas Cleary) (ISBN: 0-87773-868-8) 7. _Zen Keys_ by Thich Nhat Hanh (ISBN: 0-385-47561-6) Inspirational materials, all worth reading. ----[ EOF

<< Предыдущая ИНДЕКС Поиск в статьях src Установить закладку Перейти на закладку Следующая >>

 Добавить комментарий

Inferno Solutions
Hosting by

Закладки на сайте
Проследить за страницей
Created 1996-2022 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру