Oskar Sandberg wrote:
>
> On Thu, May 03, 2001 at 11:22:00AM -0400, Derek Glidden wrote:
> <>
> > Most firewalls nowadays, or at least the ones being managed by competent
> > admins, take a "Deny by default" approach. In other words, not only on
> > inbound but also on outbound connections, *all* connections are denied
> > unless explicitly approved.
>
> What possible reason is there to do that short of fucking with your users?
> I mean, it isn't even going to help against troyans, since any troyan
> worth a damn that gets in will call out using port 80 these days (if not
> otherwise then not to be spotted).
It's called "security." I would venture to say that most
companies/corporations over a couple of dozen people, and even smaller
ones with competent security administrators operate this way. Smaller
companies because they are still small enough that if someone needs
something opened up, it's not a big deal to walk over to his desk and
get the network guy to do it. Larger companies because they really,
really don't want people doing things like, say, setting up SSH tunnels
to their web server that port-forwards ports 137, 138, 139 from the
internet at large back to their desktop machine on which they then
enable routing.
I am pretty strongly on your side, but I also understand the reasoning
behind a "deny by default" approach. I've seen a lot of lusers do a lot
of clueless stuff that could leave some pretty big corporations flapping
in the breeze if their security weren't of the more fascist variety. It
really comes down to the fact that 90% of machines nowadays run an
Operating System that's insecure by default and any straw at which the
security admins can grasp to reduce the potential danger is siezed as
tightly as possible.
I blame society. :)
(Of course, the scenario above with SSH works fine if you just have your
sshd listening on port 80... But I digress...)
> > If I set "nodeAddress" to the address of the cablemodem's "real"
> > external address, it gets advertised to the rest of the Freenet
> > properly, but when the Node starts up and attempts to service any
> > requests, it tries to connect to that address, which it can't reach
> > since a) it's not the machine's real address and b) it can't connect to
> > it through the firewall because firewalls have a real hard time (i.e.
> > don't) rewriting packet addresses for packets coming from the address to
> > which they are supposed to be rewritten, and routing packets that are
> > coming from the machine/interface to which they're then supposed to be
> > re-routed.
>
> Is it fproxy that is failing to connect to the node? I thought that fproxy
> connected to localhost by default - doesn't it?
Not for me, although I don't recall if it was fproxy or the FCP stuff
that was trying to connect to the address given in the "nodeAddress"
parameter. When I get home I can change the settings back and try it
again with the 0.3.9 release and see how it behaves.
In either case, the same misbehaviour was occuring when freenet clients
would talk to the Node from either another box on the local network
(that had been allowed access in .freenetrc) or on the box running the
Node.
> > Short version: if the config file had "bindAddress" and
> > "advertiseAddress" as seperate entries, this would not require *any*
> > trickery - just different values for each of those settings and then
> > people with cablemodems, DSL or other semi-permanent addresses could run
> > Freenet Nodes without having to do weird split-DNS stuff.
>
> The node never explicitly binds itself to the address in nodeAddress - it
> is there exactly for times when the address it is bound to is different
> from what should be advertised.
>From my experience, leaving the "nodeAddress" unset caused the Node to
advertise itself as the machine's "real" address, i.e. unroutable.
Setting it to the external address caused some part of the Node to try
to contact that external address which would eventually fail because of
various firewall issues.
If this is considered a bug, I'll go home tonight and reproduce it and
get a more complete and technical description of what's happening.
Although it may not behave that way with 0.3.9.1 code.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
#!/usr/bin/perl -w
$_='while(read+STDIN,$_,2048){$a=29;$b=73;$c=142;$t=255;@t=map
{$_%16or$t^=$c^=($m=(11,10,116,100,11,122,20,100)[$_/16%8])&110;
$t^=(72,@z=(64,72,$a^=12*($_%16-2?0:$m&17)),$b^=$_%64?12:0,@z)
[$_%8]}(16..271);if((@a=unx"C*",$_)[20]&48){$h=5;$_=unxb24,join
"",@b=map{xB8,unxb8,chr($_^$a[--$h+84])}@ARGV;s/...$/1$&/;$d=
unxV,xb25,$_;$e=256|(ord$b[4])<<9|ord$b[3];$d=$d>>8^($f=$t&($d
>>12^$d>>4^$d^$d/8))<<17,$e=$e>>8^($t&($g=($q=$e>>14&7^$e)^$q*
8^$q<<6))<<9,$_=$t[$_]^(($h>>=8)+=$f+(~$g&$t))for@a[128..$#a]}
print+x"C*",@a}';s/x/pack+/g;eval
usage: qrpff 153 2 8 105 225 < /mnt/dvd/VOB_FILENAME \
| extract_mpeg2 | mpeg2dec -
http://www.eff.org/ http://www.opendvd.org/
http://www.cs.cmu.edu/~dst/DeCSS/Gallery/
_______________________________________________
Devl mailing list
[EMAIL PROTECTED]
http://lists.freenetproject.org/mailman/listinfo/devl
