RE: [fw-wiz] terminal services

From: Reckhard, Tobias (tobias.reckhard@secunet.com)
Date: 01/30/03 

From: "Reckhard, Tobias" <tobias.reckhard@secunet.com>
To: firewall-wizards@honor.icsalabs.com
Date: Thu Jan 30 03:09:18 2003

Please disregards Outlook's excuse for quoting..

On Wednesday, January 29, 2003 6:30 PM, Barney Wolff wrote:
[snip]
> I believe you've misunderstood what I wrote. If you allow
> queries to DNS
> or NTP out from high ports, you must, with a non-state-keeping filter,
> allow UDP inbound to high ports from port 53 or 123. But
> without state,
> you won't notice that the supposed DNS response from port 53
> is going to
> port 1434 and is an attack packet.

True. If that's what you meant, I indeed misunderstood you.

> The solution, without state, is to
> allow packets in only to ports 53 and 123, and ensure that outbound
> requests are sent only from those ports. If you can't do
> that you must
> keep state.

All of this only applies if I see the need to solve a potential problem,
namely being flooded by tons of possibly spoofed UDP packets aimes at my NTP
or DNS clients (they're clients to the Internet, servers to internal
machines). The question is what the problem really is that I'm trying to
solve.

If it's the traffic that's eating up my WAN link, which is the point of
lowest bandwidth everywhere I've been, neither of your proposed solutions
will help at all.

If it's the daemon on the target machines crashing, eating up too many CPU
cycles, trashing on disk or similar due to being overloaded with lots of
silly packets, then I suppose a stateful firewall could help. Since source
ports are completely arbitrary and someone targetting UDP ports 53 or 123
should know that some popular implementations use the same fixed source
ports, they could choose those source ports just as well as random ones or
any other one (such as 1434). Restricting a dumb packet filter to check
source ports on responses buys you squat.

The stateful firewall may help you. But the fact that your daemon is going
nuts is a serious problem, IMHO. That should be fixed. It should not be
difficult for an NTP or DNS daemon to throw away unwanted packets without a
lot of fuss. Could very well be that BIND and ntpd don't perform all that
well in this regard. But there's no difference in their behaviour when faced
with packets coming from port 34626 than if they come from port 53/123.

> This is just wrong - both bind's named and ntpd can be
> configured to send
> requests only from 53/123.

I'm talking about the protocols, not individual implementations. Popular as
they may be, they don't define the protocol. These two simply call
themselves 'reference implementations'. There are a great many other
implementations that behave differently and are still fully compliant with
the protocols.

> ntpd does it by default; it's ntpdate that
> sends from a high port.

Exactly. ntpdate is an NTP client, isn't it?

As for BIND, BTW, it used to default to sending everything from UDP port 53.
Nowadays, AFAIK, it picks one random port (or probably asks the OS for one)
and keeps using that. dnscache from the djbdns package requests a random
port for each and every request.

Sure, you can use use ntpd and BIND (and configure the latter appropriately)
to be able to restrict the destination ports on inbound packets. You're
forcing the attacker to use source port 53 and 123 respectively. Not much of
a challenge..

> Just to be clear, I am NOT suggesting that
> checking the source port of inbound packets does any good. I
> am suggesting
> that controlling the source port of your own outbound requests allows
> you to restrict what destination ports inbound packets may target, if
> you're using a simple router filter rather than a
> state-keeping firewall.

Ah, OK. It's of no practical use, though, so why even bring it up as an
(albeit deficient) alternative to a stateful firewall (your preference,
seemingly) or well engineered daemons (my preference, though stateful
firewalls can be beneficial - I just don't like the fact that I usually have
no choice but to accept the firewall implementor's concept of 'virtual'
state for stateless transport protocols, i.e. anything besides TCP).

Cheers,
Tobias

Relevant Pages

  • RE: Localhost packets on WAN
    ... when the source port is 80 and the destination port is ... > misconfigured load balancers in front of a web site. ... packets originating from your network, ...
    (Incidents)
  • Re: What is going on with my Dialup?
    ... also forward it to an unused port, and have that port provide the ... verses the RST or ICMP 3,3. ... The lack of response causes the remote computer to make ... Others think that by not responding to unwanted packets, ...
    (comp.os.linux.networking)
  • Re: Logs: Many hits with source port of 80
    ... The hits from source port 80 to dest port 37852 are IMHO almost ... you should probably see a couple other packets - perhaps ... packets if either you send the load balancer a packet, ... >>I have seen similar hits for the past three months. ...
    (Incidents)
  • Re: Error 720 connecting to server via VPN
    ... By default the router's firewall is configured to drop ICMP packets ... Select WAN Setup> Advanced> Respond to Ping on Internet Port. ... server and the Internet allow GRE packets. ... routers on the user's network are also configured to allow GRE packets. ...
    (microsoft.public.windows.server.sbs)
  • tcp oddities.
    ... After syn-scanning an IP block, ... suprise there was an smtp server sitting on port 25. ... 1353 packets received by filter ... Ethical Hacking at the InfoSec Institute. ...
    (Pen-Test)