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