[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Help-gnunet] Re: udp traffic on port 65535
From: |
Christian Grothoff |
Subject: |
Re: [Help-gnunet] Re: udp traffic on port 65535 |
Date: |
Tue, 20 Aug 2002 13:33:39 -0500 |
User-agent: |
KMail/1.4.1 |
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tuesday 20 August 2002 01:14 pm, David Hansen wrote:
> On Mon, Aug 19 at 17:55 Christian Grothoff wrote:
> > Port 65535 is also used for fragmented packets. I kind of doubt that
> > you've really got a kernel bug. What's the MTU of your network? How did
> > you get the portnumber?
> >
> > On Monday 19 August 2002 06:49 am, Peter Presslein wrote:
> > > Am Dienstag, 6. August 2002 04:23 schrieb Christian Grothoff:
> > >
> > > Hello again :-)
> > >
> > > > > since i installed gnunet 0.4.4 i have a lot of udp traffic
> > > > > on port 65535 going outside to other nodes.
>
> I just realized that i've the same problem...
>
> $IPCHAINS -A input -f -i $EXTDEV -l -j ACCEPT
>
> seems to help. But i dont know if this might be a security risk.
Well, that's what I figured, too. From the ipchains man-page:
NOTES
Fragments are handled differently. All fragments after the first used
to be let through (which is usually safe); they can now be filtered. This
means
that you should probably add an explicit rule to accept fragments if
you are converting over. Also, look for old accounting rules which check for
source
and destination ports of 0xFFFF (0xFF for ICMP packets) which was the
old way of doing accounting on fragments.
- ------
since an MTU of 1492 will mean that GNUnet traffic would be fragmented, that
explains the problem very well. While I don't see a particular security risk
with letting through fragments, there are solutions:
a) a stateful firewall (iptables, 2.4 kernel) should handle the case much
better
b) advertise MTU in the GNUnet handshake and automagically reduce to
that size. This would increase the efficiency of the system and solve the
problem at the same time. The code can not handle this at the moment,
though. Maybe something to keep in mind for the future.
Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
iD8DBQE9YouD9tNtMeXQLkIRAglTAJ9IFfNsgNSAq/WDchaL8aDA+MvymgCgiFMk
O6NGzba3rmglrLVOyfjGdSA=
=cICP
-----END PGP SIGNATURE-----