Bugtraq mailing list archives
Alert: Routing and RAS Filtering issue
From: aleph1 () DFW NET (Aleph One)
Date: Fri, 27 Jun 1997 12:48:13 -0500
---------- Forwarded message ---------- Date: Thu, 26 Jun 1997 12:24:11 -0400 From: Russ <Russ.Cooper () RC ON CA> To: NTBUGTRAQ () RC ON CA Subject: Alert: Routing and RAS Filtering issue DO NOT RESPOND TO THIS MESSAGE WITHOUT REMOVING ALERT: FROM THE SUBJECT LINE. I've just uncovered what appears to be a major problem with the filtering abilities of the Routing and RAS Service (R&R - Steelhead). I should say that this issue is currently being investigated by MS, but given the newness of the product, the lack of wide deployment, and the seriousness of the problem, I thought I should send this message out. R&R has no concept of an established connection. So in order to allow for two way communication over any protocol to any host, both Output = and Input rules must be configured. So, for example, if I wanted to permit an Exchange Server to communicate over the Internet for SMTP only, I'd need the following table of rules; Filter Source IP Dest IP Protocol Source Port Dest Port Output 1.2.3.4 any TCP 0 25 Input any 1.2.3.4 TCP 25 0 Output 1.2.3.4 any UDP 0 25 Input any 1.2.3.4 UDP 25 0 Output 1.2.3.4 any TCP 0 53 Input any 1.2.3.4 TCP 53 0 The first rule allows outbound connections to Internet SMTP servers The second rule allows data back from my outbound sessions The third rule allows inbound connections from the Internet The fourth rule allows data back to my inbound sessions The fifth and sixth rules are for DNS The problem is in the reciprocal rules. The second rule above allows a connection to any port on my system as long as it originates from port 25 on any system on the Internet. How difficult would it be to write a program to use a source port of 25 and a destination port of, say, 19, and send a request to the chargen server to start spitting stuff out? = Or have it access TCP139 repeatedly doing login requests. Nothing would ever come back to me (since there isn't a reciprocal rule to allow outbound traffic back from the port I'm targeting), but I could easily do a Denial of Service on the machine on ports they never expected to see traffic on. In the case of a machine without the RPC patch, but using R&R filtering to prevent connections to TCP135, I could drive the machine to 100% CPU utilization. My point is not what can be done, but that it is possible to connect to ports that have been thought to be filtered. Here is a table representing the documentation provided in R&R = regarding setting up PPTP Filtering. This is intended to duplicate what NT does when you set the PPTP Filtering option without having R&R installed; Filter Source IP Dest IP Protocol Source Port Dest Port Output any any TCP 1723 any Input any any TCP any 1723 Output any any TCP any 1723 Input any any TCP 1723 any Output any any 47 any any Input any any 47 any any As you can see, their own documentation is telling you to open up all destination ports on your machine to an inbound connection from = anywhere with the only limit that the inbound connection must originate from = port 1723. Since there is no packet analysis taking place, that connection can carry any traffic you want to feed it. Once again, let me stress, I understand that such a connection would = not be able to retrieve data from the NT server, so it couldn't be used to interact with the box, but it could be used to access ports other than the intended port and send that port data, thereby possibly killing the process, setting it into some abnormal termination, or simply flooding it with traffic. Without the concept of "established" connections, the filtering abilities of R&R are useless. They are misleading at best (since = nowhere in the documentation is this fact explained or even mentioned) and will ultimately lead people to believe they have a stronger form of security than they really do. I had hoped that R&R represented a significant addition to my arsenal = of tools/methods used to protect an NT box, but it clearly does not. I would say that the product falls way short of being what MS intended it to be also. An NT server with R&R installed would need to be placed between a pair of *real* routers with *real* packet filtering for it to be viable as any kind of security solution that involved packet filtering. It would have been far better to not provide any packet filtering thereby removing the possibility that someone might think their packet filtering gives them any form of security or = functionality. Cheers, Russ R.C. Consulting, Inc. - NT/Internet Security owner of the NTBugTraq mailing list: http://ntbugtraq.rc.on.ca/index.html
Current thread:
- Re: Solaris Ping bug (DoS), (continued)
- Re: Solaris Ping bug (DoS) just me. (Jun 26)
- Re: Solaris Ping bug (DoS) Francesco Messineo (Jun 26)
- 'sec-fix' for NT 3.51 Aleph One (Jun 26)
- Problem in dxterm (ULTRIX) Trevor Schroeder (Jun 26)
- Re: Solaris Ping bug (DoS) Philip Kizer (Jun 26)
- Solaris Ping bug(inetsvc) Renteria Tabares J. (Jun 27)
- Announce: ypcat for Win NT/95 Aaron Spangler (Jun 27)
- Re: Solaris Ping bug (DoS) Geoff Mulligan (Jun 27)
- Win95 ping bug nomad () APOLLO TOMCO NET (Jun 29)
- Re: Solaris Ping bug (DoS) Jon Edwards (Jun 30)
- Alert: Routing and RAS Filtering issue Aleph One (Jun 27)
- Solaris Ping Bug and other [bc] oddities Aleph One (Jun 23)
- Re: [ADVISORY] 4.4BSD Securelevels Howie Kaye (Jun 26)
- Re: [ADVISORY] 4.4BSD Securelevels Thomas H. Ptacek (Jun 26)
- SUMMARY: Solaris Ping bug (DoS) Gnuchev Fedor (Jun 27)
- Security hole affects many cvs pserver installations Aleph One (Jun 27)