On Thu, 23 May 2002, Ramin Alidousti wrote:
> > > > > Best of luck with the request, and I'm fascinated to know why this is
> > > > > considered a sensible way to run UDP....
> > > > One can easily run DNS this way, for load balancing, etc.
> > > Can you come up with a scenario for this DNS case? Do you mean that
> > > I send a DNS query to A and B would give me the answer?
> > Yes. A is a NAT box that load balances (but doesn't hide) B, C, etc. So,
> What do you mean by a NAT box that does not hide? Does it NAT or not?
> If it NATs then it hides!!
No. I mean that
Alien IP/UDP port --> A IP/UDP DNS
gets changed to
Alien IP/UDP port --> {B,C,...} IP/UDP DNS
i.e. Alien IP/UDP port isn't SNAT'ed. The packets are only DNAT'ed with
-j DNAT --to-destination <B,C,... IP range>
> > the reply to your request to A could come from either one of B, C, etc.
> > And A can be something as small as a 386 because kernel-level NAT'ting
> What do you mean by "kernel-level NAT'ing"? I thought you said that A
> doesn't hide B or C, two sentences ago!!
I mean that, other than for rule definitions, the NAT box's userland is
not involved.
> > doesn't need a lot of ummph. We've tried a similar thing with SAMBA a
> > few years ago, although SAMBA also involves TCP on a more regular basis,
> > making things a little messier. This is handy when you're waiting for
> > mucky-mucks to decide on the funding for a bigger server.
> Have no experience with SAMBA... But if it uses TCP how do you do what
> you're asking here for UDP. And you just call it a little messier. It
> simply doen't work with TCP...
That's right, I can't do that with TCP. I have to SNAT it. The mix of
UDP and TCP required for SAMBA is what makes this messy. In any case,
this was just an experiment to see what we could get away with in a
crunch. I would never dream of using this for production for any extended
period of time (sysadmin issues).
In any case, my intent with the DNS and SAMBA examples was to show how
UDP's multiple reply IP capability can be exploited (and used as an
external test case for UDP SNAT'ing). And to show that this problem is
not specific to Globus.
> > > But, anyway, If you do SNAT for the outgoing UDP packets, what prevents
> > > you to do DNAT for the _unrelated_ incoming UDP packets? Or maybe I don't
> > > understand you question well?
> > That would generate a lot of false positives and negatives. By INPUT
> > time, I don't see how I can determine whether the packet wasn't de-masq'ed
> > simply because its source addr/port wasn't what the outgoing packet said
> > it would be. Neither can I tell if the target port was masq'ed in the
> > first place (this also true of a PRE-ROUTING rule). By then, it's too
> > late anyway because the routing decision's already been made. No, this
> > needs be done during de-masq'ing, part of PRE_ROUTING.
> I'm still not getting this.
> If you have the IP and port of your internal (UDP) servers (yes, this only
> works for predetermined port numbers) then you can do:
> $IPT -t nat -A PREROUTING -i <internal interface> \
> -p udp -d <external ip> --dport <server port> \
> -j DNAT --to <internal IP>
Getting back to the problem at hand (where the internal network is in fact
hidden): After filtering out bad external destinations, I'd do
iptables -t nat -A POSTROUTING -o <external interface> \
-s <internal network> -j SNAT
Due to the way conntrack currently works, as packets come in from the
internal interface, say <Hidden IP:hidden port> --> <Alien IP:Alien port>,
this amounts to generating the equivalent to an additional rule of the
form
iptables -t nat -A PREROUTING -i <external interface> -p {upd,tcp} \
-d <external IP> --destination-port <mport_n> \
-s <Alien IP> --source-port <Alien port> \
-j DNAT --to-destination <Hidden IP>:<Hidden port>
... where mport_n is whatever <Hidden IP:Hidden port> got -SNAT'ted to.
So the equivalent of 2.2's udp_dloose functionality would be the optional
removal of -s and --source-port specifications from the latter (virtual)
command. This can't be done in userland because the SNAT'ting of a
particular packet isn't done there.
> But, if you mean that the internal host runs a client and sends a UDP to
> IP1:PORT1, then yes, you cannot have a reply back from IP2:PORT2 to that
> client, as you don't know the port of the client.
Yep.
> I think that you're better off correcting the behavior of the remote end
> than openning up such a hole in your firewall.
Again, the "hole" also exists on any single system using UDP (client or
server). The introduction of a firewall into this mix changes nothing at
all security-wise. It only changes the politics.
Also, it might be fortunate Globus is Open Source, but that's not
necessarily the case in general.
Marc.
+----------------------------------+-----------------------------------+
| Marc Aurele La France | work: 1-780-492-9310 |
| Computing and Network Services | fax: 1-780-492-1729 |
| 352 General Services Building | email: [EMAIL PROTECTED] |
| University of Alberta +-----------------------------------+
| Edmonton, Alberta | |
| T6G 2H1 | Standard disclaimers apply |
| CANADA | |
+----------------------------------+-----------------------------------+
XFree86 Core Team member. ATI driver and X server internals.
