Re: UDP catchall



On Mon, Oct 29, 2007 at 07:49:47PM +0000, Bruce M. Simpson wrote:
Brooks Davis wrote:
While I think this idea has some merit, I think we specifically want
the current wildcard ability to allow for a system that requires
minimal configuration. The problem with a range is that it doesn't
allow disjoint sets and it requires that if you really do want all the
ports you need to produce a list of currently allocated ports to avoid
allocating. A more (over)engineered solution holds some attraction, but
I'm not yet convinced the fact that it could exist precludes the current
implementation.

Actually I concur with you on this point, based solely on the disjoint sets
point.

Another vector of attack would be to put the relay functionality into PF,
which can do the packet matching. However this of course suffers from the
problem that if you just want a plain old UDP socket for mtund, you won't
get that unless you go to the inpcb layer anyway.

But who says mtund needs to use sockets for its traffic relay? There is
definite appeal in *not* doing it in the socket layer at all -- an
adaptation of pf's log socket may suffice...

I can think of a possible implementation of mtund(8) without kernel
patching. The next pf(4) import from OpenBSD will likely allow to log
to some particular pflog(4) interface (instead of the default pflog0).

It will then be possible to create a couple of rules matching one or
more ranges of ports and logging to, say, pflog1. Reading on the
latter, mtund(8) will immediately open a socket bound to the
corresponding port. This is a kind of port knocking. Thanks to TCP
retransmission algorithm or mtunc(1)'s cleverness in case of UDP socket,
the second packet should hit mtund(8).

One downside is that it requires a bunch of configuration in pf.conf(5),
so it may not be as straightforward to set up as one may have expected.

I don't know TCP internals, it may affect TCP slow start or have some
other minor drawbacks. But hey, we're talking about bypassing firewall
:-)...

My 2 cents.
Regards,
--
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >
_______________________________________________
freebsd-net@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscribe@xxxxxxxxxxx"



Relevant Pages

  • Re: UDP catchall
    ... the current wildcard ability to allow for a system that requires ... ports you need to produce a list of currently allocated ports to avoid ... Actually I concur with you on this point, based solely on the disjoint sets ... problem that if you just want a plain old UDP socket for mtund, ...
    (freebsd-net)
  • Re: Grob 103 question
    ... The socket contains three o- ... rings to keep the three ports separated when the probe is inserted. ... Two of the o-rings are easily replaceable from the front opening. ... you cut out the tripple probe mount to do this. ...
    (rec.aviation.soaring)
  • Re: Grob 103 question
    ... The socket contains three o- ... rings to keep the three ports separated when the probe is inserted. ... you cut out the tripple probe mount to do this. ... them to avoid wear and tear on the O-rings. ...
    (rec.aviation.soaring)
  • Re: Wrapping TCP communications in HTTP
    ... We're using Winsock2 sockets with overlapped I/O through completion ports. ... HTTP won't help you a bit since it's not a secure protocol. ... >>> establishes a TCP socket connection to a server, ...
    (microsoft.public.win32.programmer.networks)
  • Re: question related to sockets
    ... The short answer is that the OS doesn't release a socket for up to 4 mins and hence your reconnect would fail. ... This pc, sometimes my app crashes on it, which is pretty usual cuz of application bugs and I fix them of course. ... But the problem is that the ports r left open when the app crashes. ... The *-o* switch for this netstat command shows the process that owns these ports but clearly that process died a long time back and has no signs in the task manager of windows xp either. ...
    (microsoft.public.dotnet.languages.vc)