Firewall Wizards mailing list archives
RE: terminal services
From: "Reckhard, Tobias" <tobias.reckhard () secunet com>
Date: Thu, 30 Jan 2003 07:47:46 +0100
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 _______________________________________________ firewall-wizards mailing list firewall-wizards () honor icsalabs com http://honor.icsalabs.com/mailman/listinfo/firewall-wizards
Current thread:
- Re: terminal services, (continued)
- Re: terminal services Barney Wolff (Jan 28)
- RE: firewall design (was: RE: terminal services ) m p (Jan 29)
- RE: terminal services Paul D. Robertson (Jan 28)
- RE: terminal services R. DuFresne (Jan 28)
- Message not available
- RE: terminal services Marcus J. Ranum (Jan 28)
- Re: terminal services Steven M. Bellovin (Jan 28)
- RE: terminal services Reckhard, Tobias (Jan 28)
- Re: terminal services Barney Wolff (Jan 29)
- Re: terminal services Paul Robertson (Jan 29)
- Re: terminal services Barney Wolff (Jan 30)
- Re: terminal services Barney Wolff (Jan 29)
- Re: DNS security (Was: re: terminal services) Mikael Olsson (Jan 31)