> On Jun 2, 2005, at 1:39 PM, Darren Reed wrote:
> >> That, and I encourage users to SSH port forward using a semi-trusted
> >> machine in the DMZ, just as one ought to terminate a VPN endpoint in
> >> the DMZ by preference, where you can.

> >
> > But ssh isn't a VPN technology per se, it's encrypted telnet (or
> > rlogin
> > or..) that I use from my desktop to my destination so I have some sort
> > of measurable security benefit.

> Inconsistency detected. Do you remember saying:

Indeed I do. And I said the above with full knowledege of what I'd said.
Primarily because you evolved your argument to find a way to counter the
tunnel aspect.

> I regard SSH with port forwarding as being similar in scope to VPN
> access, or IP-over-PPP tunneling, or any similar form of network
> encapsulation.

And it's part of the same product, it isn't seperate. You're expecting
people to treat it differently depending on how they use it. I use it
like many others do - for the combined functionality at the same time
and there's no sacrificing one for the other.

> [ ... ]
> >> Sure. If some random user or guest plugs in a laptop with an 802.11
> >> card or a wireless router to a companies' internal subnet, they've
> >> configured a backdoor, a network topology which goes around the
> >> firewall and thus is a serious hole to network security.

> >
> > This is an irrelevant example, for which there are solutions.

> If some random user can easily set up a route which goes around the
> firewall, much less permits untrusted traffic back through, that
> represents a serious, possibly critical weakness to your network
> security.

Well then secure your LAN. This can be done. This is why your example
is irrelevant. If you (or anyone else) chooses to run an insecure LAN
then you take on these risks. If you've signed up for that then don't
complain about it. LANs do not need to be insecure.

> > It's like you're going out of your way to exclude "manage" from
> > applying
> > to things like UPnP because if it did (and in a useful way) then you
> > wouldn't have a platform to stand on to argue that it is bad.

> No. It's like I have a viewpoint on how to setup, configure, and
> manage a network which was formed years before UPnP was invented.

Right and now that viewpoint is growing stale. The IT industry is
very dynamic, you need to grow and move with the times or get left

> I don't think UPnP is helpful for other situations, because
> anyone who can set up DNS or a DHCP server is already managing the
> network well enough that UPnP doesn't really add anything.

I disagree and we'll have to agree to disagree.

> > Or maybe, as someone who writes software, I look at the problem and
> > see ways it can be solved rather than obstacles that cannot be
> > overcome.

> Do you regard security as problem to be solved, or as an obstacle?

A problem to be solved.

> I don't choose to run it on machines where I don't need to, and
> especially I don't choose to run it on machines with data I want to
> keep secret. [1] If we could convince users *not* to run untrusted
> software, a great deal of the current disaster with emailed viruses/
> trojan horse problem would go away.

This begats a whole other conversation about whether or not software
is trustworthy and what makes it one way or another.

I could try and preempt the entire discussion by saying unless you've
got signed executables from your vendor and your OS verifies them, as
well as those for drivers, then you've no guarantee that you're only
running trusted software. But I think it's best summed up by referring
back to Marcus who recently (on this list noted that perhaps the
Orange Book guys got it write...after how many years of saying it was
pointless ? Oh, and just because *you* compile something yourself
does not make it trustworthy. Go read about the .. worm(?) .. in one
of the original C compilters.

But the real problem is that today, to get the most out of what the
Internet and computers have to offer, we're generally _forced_ to
run 'something' that is not completely trustworthy.

> I'm happier setting up a fileserver which does not
> allow end-users shell access, for example, or which forbids setuid-
> execution in the partition where user home directories are kept.

More chest beating. These things are "old hat".

firewall-wizards mailing list