On Tuesday 09 April 2002 03:48, Brian J. Murrell wrote:
> I must be missing something here because we seem be going around
> and around on this issue. There are no "defined" ports that you
> can discern what gets opened and what doesn't. It sounds to me
> like all ports are ephemeral, which mak
On Tuesday 09 April 2002 03:48, Nils Ohlmeier wrote:
> If i understand the spec correct, a UPnP deamon have also to
> provide control over your ppp-deamon. The main aspect of the spec
> is configuring and controling your dialup connection and the
> posibility to configure port-forwarding is addit
On Tuesday 09 April 2002 01:18, Henrik Nordstrom wrote:
> But this thread is about how we can provide UPnP port mapping within
> iptables/netfilter in a sensible manner, not how poor the reality of
> Internet security actually is when you do not trust your clients at
> all. I say providing UPnP wi
On Tue, Apr 09, 2002 at 01:04:30AM +0200, Henrik Nordstrom wrote:
>
> a) The NAT defice fully trusts the client and opens whatever the
> client requests it to without asking.
:-(
> b) Authentication, requiring the user to identify himself before
> allowing the request and you trust the user.
On Monday 08 April 2002 16:29, Brian J. Murrell wrote:
> If it is indeed possible to do this. How does the UPnP determine
> for what purposes a client request is being made? If the answer is
> "well the client says what it is for" then again, that is useless.
There is multiple choices here.
a
On Monday 08 April 2002 18:03, Nils Ohlmeier wrote:
> Brian you always wrote about trusting your clients. If
> you do not trust your clients don't connect them to the internet.
> How do you know in detail what your clients send or
> receive over connections to port 80? I assume that nearly all
In article <[EMAIL PROTECTED]>,
Brian J. Murrell <[EMAIL PROTECTED]> wrote:
>On Sun, Apr 07, 2002 at 11:13:58AM +0200, Andre Breiler wrote:
>I think I disagree. Security (access mitigation) as always been
>there, NAT as kinda "grown on", through a historical path of
>MASQUERADING in 2.2, and heck
Message -
From: "Harald Welte" <[EMAIL PROTECTED]>
To: "Henrik Nordstrom" <[EMAIL PROTECTED]>
Cc: "Eric Wirt" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Sunday, April 07, 2002 5:12 AM
Subject: Re: [UPnP-SDK-discuss] UPNP Server/Applicati
> Brian you always wrote about trusting your clients.
> If you do not
> trust your clients don't connect them to the internet.
> How do you know in detail what your clients send
> or receive over connections
> to port 80? I assume that nearly all readers of this mailing
> list would be
>
On Monday 08 April 2002 16:29, Brian J. Murrell wrote:
> On Mon, Apr 08, 2002 at 11:16:38AM +0200, Harald Welte wrote:
> > I totally agree. Of course those 'orders' would need to go through some
> > firewall-admin defined policy, before hitting netfilter/iptables.
>
> If it is indeed possible to
> By definition there are no "defined" ports. Because the UPnP
> device has to allocate ports out to a whole lan of clients
> wanting (for
> instance) a listener, the same port cannot be used by all
> listeners. From the previous definition of how Messenger uses
> UPnP, a broker on the .NET n
On Mon, Apr 08, 2002 at 11:56:29AM +0200, Henrik Nordstrom wrote:
>
> By the same way as you firewalling policy knows to allow the user to
> go out on port 80. You have a policy saying that users X & Y are
> allowed to punch such holes for port 456 under certain given
> conditions.
By definit
On Mon, Apr 08, 2002 at 11:16:38AM +0200, Harald Welte wrote:
>
> I totally agree. Of course those 'orders' would need to go through some
> firewall-admin defined policy, before hitting netfilter/iptables.
If it is indeed possible to do this. How does the UPnP determine for
what purposes a cli
On Monday 08 April 2002 05:45, Brian J. Murrell wrote:
> > Only within the limitations of what the UPnP device accepts.
>
> But that is the question. If apps are just asking for mappings on
> the UPnP device (i.e. listen TCP port 456) how can the device
> impose any limitiations. There is nothi
On Monday 08 April 2002 05:36, Brian J. Murrell wrote:
> But even with it, I have to trust the client app that it will do
> good (and secure) with the hole in the firewall that I have
> allocated for it.
See my earlier message. The holes should be subject to your
firewalling policy.
> Oh. I s
On Sun, Apr 07, 2002 at 06:28:01PM -0400, Brian J. Murrell wrote:
> On Sun, Apr 07, 2002 at 03:33:23PM +0200, Henrik Nordstrom wrote:
> >
> > A firewall who gives no access is very effective, but not likely to
> > make you very famous as it also inhibits any communication to take
> > place.
>
On Sun, Apr 07, 2002 at 03:48:26PM +0200, Henrik Nordstrom wrote:
> On Sunday 07 April 2002 12:07, Brian J. Murrell wrote:
>
> > > Dynamically inserting/removing rules seems like a big hack, but
> > > not like a solution.
> >
> > Why? I thought that userspace solutions were _always_ considered
>
On Mon, Apr 08, 2002 at 05:49:36AM +0200, Nils Ohlmeier wrote:
> FCP is our own creation, because of the lack of an 'offical' protocol from
> the IETF. It was and probaly will never become an offical IETF protocl.
Well, it has been an IETF draft, hasn't it?
> The basic idea behind the FCPd is f
On Mon, Apr 08, 2002 at 04:27:11AM +0200, Henrik Nordstrom wrote:
>
> The UPnP server do not officially know the application no, but in
> each portmap request there is at least a connection description /
> comment describing the use connection,
Which a security adminstrator has to trust. Bad!
On Sunday 07 April 2002 10:51, Harald Welte wrote:
> The 'official' IETF approach on how to NAT SIP/SDP is that you have to
> run some SIP proxy, which communicates the to-be-opened port and NAT
> mappings over some protocol (formerly FCP, firewall configuration protocol)
> to the firewall.
>
> As
On Mon, Apr 08, 2002 at 09:39:16AM +1000, Reynolds, Alfred wrote:
>
> Okay, I haven't read the spec either (geez, I hope someone does ;) but I
> suspect that the UPnP request contains some kind of "service-type" field in
> the request,
So we are trusting the client apps now?
> so you can allow
On Monday 08 April 2002 03:28, Tom Marshall wrote:
> The difference is that a SIP proxy will only allow stuff that looks
> like SIP through the firewall. This UPnP protocol looks like it
> will allow pretty much anything, including the ability to expose an
> internal machine's listen sockets to
On Monday 08 April 2002 00:28, Brian J. Murrell wrote:
> Right! But my impression is that you have no idea which
> application is requesting the access through the UPnP server. A
> security policy of "allow whatever the clients ask for" is no
> security policy at all, and unless the firewall/UP
> > The 'official' IETF approach on how to NAT SIP/SDP is that you have to
> > run some SIP proxy, which communicates the to-be-opened port and NAT
> > mappings
> > over some protocol (formerly FCP, firewall configuration protocol) to
> the
> > firewall.
>
> And how is the SIP proxy any safer tha
> Okay, I haven't read the spec either (geez, I hope someone does ;) but
I
> suspect that the UPnP request contains some kind of "service-type"
field
> in
> the request, so you can allow (for example) VoIP but not Computer
games
> (previous emails described it using soap, and soap is great at havi
> On Fri, Apr 05, 2002 at 12:37:01PM -0600, Glover George wrote:
> > Am I right in understanding this logic behind doing connection
tracking?
> > The first protocol involved that needs to be messed with is SIP.
Does
>
> I've been spending quite some time digging into SIP and thinking about
> pos
> I am not sure I see it as being more "flexible" but rather lax.
>
> > allowing use of various kinds of protocols
>
> But it's not a choice of "various" protocols. From my understanding,
> once you turn on UPnP, any application that knows how to ask the
> server can have whatever access (list
On Sun, Apr 07, 2002 at 03:48:26PM +0200, Henrik Nordstrom wrote:
>
> How I understood Harald is that he do not regard a userspace daemon
> who dynamically changes the iptables ruleset as the correct approach,
> but the correct approach rather a userspace daemon who directly
> insert new conne
On Sun, Apr 07, 2002 at 03:33:23PM +0200, Henrik Nordstrom wrote:
>
> A firewall who gives no access is very effective, but not likely to
> make you very famous as it also inhibits any communication to take
> place.
Understood. But a firewall that takes "orders" as to what to open and
close w
On Sunday 07 April 2002 12:07, Brian J. Murrell wrote:
> > Dynamically inserting/removing rules seems like a big hack, but
> > not like a solution.
>
> Why? I thought that userspace solutions were _always_ considered
> "the better way(tm)" to do things when possible. What is a better
> solution
On Sunday 07 April 2002 11:58, Brian J. Murrell wrote:
> If you are building a "access provider" and not a "firewall", yes,
> but I guess what I am asking is don't more netfilter boxes go in
> for security than access provision?
A firewall who gives no access is very effective, but not likely to
On Sun, Apr 07, 2002 at 11:12:23AM +0200, Harald Welte wrote:
>
> To be more precise: A userspace daemon using the upcoming ctnetlink
> interface to add connection tracking entries / nat mappings and
> ip_conntrack_expect's to the firewall.
Hey, that sounds like the stateful packet filter engin
On Sun, Apr 07, 2002 at 11:13:58AM +0200, Andre Breiler wrote:
>
> Yes it does since the UPnP thread started.
Good, it's not just me.
> Yes this is one aspect but here is an other.
> It's used for NAT in first place with the side effect of added security
> sometimes.
I think I disagree. Secur
On Sunday 07 April 2002 04:19 pm, Brian J. Murrell wrote:
> On Sat, Apr 06, 2002 at 03:32:05PM -0500, Eric Wirt wrote:
>> 2) When a program needs traversal through the firewall, it will ask the
>> gateway for X number of ports to specifically be opened and forwarded to
>> the inside machine. The
On Sun, 7 Apr 2002, Brian J. Murrell wrote:
> On Sat, Apr 06, 2002 at 03:32:05PM -0500, Eric Wirt wrote:
> >
> > 2) When a program needs traversal through the firewall, it will ask the
> > gateway for X number of ports to specifically be opened and forwarded to the
> > inside machine. The gatewa
On Sun, Apr 07, 2002 at 12:55:37AM +0200, Henrik Nordstrom wrote:
> On Sunday 07 April 2002 00:09, Eric Wirt wrote:
>
> > 1) I'm not terribly familiar with the netfilter architecture.
> > Maybe one of the netfilter developers can chime in and tell me what
> > the proper way to hook into netfilte
On Fri, Apr 05, 2002 at 12:37:01PM -0600, Glover George wrote:
> Am I right in understanding this logic behind doing connection tracking?
> The first protocol involved that needs to be messed with is SIP. Does
I've been spending quite some time digging into SIP and thinking about
possible solut
On Sat, Apr 06, 2002 at 03:32:05PM -0500, Eric Wirt wrote:
>
> 2) When a program needs traversal through the firewall, it will ask the
> gateway for X number of ports to specifically be opened and forwarded to the
> inside machine. The gateway will report to the calling program (Messenger)
> whi
On Sat, 6 Apr 2002, Eric Wirt wrote:
> http://www.intel.com/labs/connectivity/upnp/tech.htm. They have several
> whitepapers with more specific information on device discovery and NAT
> traversal.
Is there a NAT traversal specification for this? If it's there, I
didn't see it.
- James
--
On Sunday 07 April 2002 00:09, Eric Wirt wrote:
> 1) I'm not terribly familiar with the netfilter architecture.
> Maybe one of the netfilter developers can chime in and tell me what
> the proper way to hook into netfilter would be?
Not being a core developer, but clearly the correct approach to
> A UPnP daemon with netfilter hooks (and whatever else it needs to hook
> into) is the proper way to do this and go on with it. In the spirit of
> hating Microsoft, some people may abandon this idea. But it is becoming
> widely accepted. And lets face it, I administer some 60 windows
> machine
il 06, 2002 2:32 PM
To: [EMAIL PROTECTED]
Subject: [UPnP-SDK-discuss] UPNP Server/Application Gateway for Linux
I have been on the lookout for a UPnP Internet Gateway for Linux for
some
time, and am glad to see that the discussion seems to have begun in
earnest.
I have been researching implementing
I have been on the lookout for a UPnP Internet Gateway for Linux for some
time, and am glad to see that the discussion seems to have begun in earnest.
I have been researching implementing a UPnP gateway that works with
netfilter for several months now, and wanted to throw out some more
information
t; To: 'Glover George'
> Cc: [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: [UPnP-SDK-discuss] UPNP Server/Application
> Gateway for Linux
>
>
> So, UPnP is independent from the messenger problem.
> The messenger problem is the classic H.323 proble
ick'
> Cc: [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: RE: [UPnP-SDK-discuss] UPNP Server/Application Gateway for
> Linux
>
>
> (P.S. - I'm putting this at the top because everyone may not want to
> read this but I'd like a quick answer on this point :
&
for linux. Of course we need to get with netfilter, ISC
(Bind), etc and talk to them about UPnP, their feelings on it, and how
best we might implement this with their products.
I'm waiting on comments. Thank you.
> -----Original Message-----
> From: Jeffrey Damick [mailto:[EMAIL
46 matches
Mail list logo
