MSN Messenger ALG

MSN Messenger ALG

[Amir Khandani]

Hi,
Is there a ALG for MSN Messenger in iptables? I need that to get file
transfer and voice working between NATed clients.
thanks for any help,

-amir

Re: MSN Messenger ALG

[Harald Welte]

On Wed, Jun 26, 2002 at 11:44:14AM -0700, Amir Khandani wrote:
> Hi,
> Is there a ALG for MSN Messenger in iptables? I need that to get file
> transfer and voice working between NATed clients.

I assume you are talking about the SIP protocol?

No, nobody came up to either write or sponsor support for SIP yet. It's
a fairly complex protocol...

> thanks for any help,
> -amir

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

RE: MSN Messenger ALG

[Glover George]

Yes, SIP can get very hairy, because it's primarily xml -ished based.
The proper way to make MSN Messenger work is using Universal Plug n Play
to do nat traversal.  http://linux-igd.sourceforge.net will make this
work (every feature except file transfer, which we at the UPnP forum are
trying to get Microsoft to hurry up and fix (along with many router
vendors)).  

If there was indeed an SIP conntrack however, it would be so much nicer,
because there are a lot of packages coming out that use SIP but do not
use UPnP.  It's just a matter of sparking enough interest in it to get
someone knowledgeable in netfilter to write one (or someone learning
from scratch).

Glover George
Systems/Networks Administrator
Gulf Sales & Supply, Inc.
dime@gulfsales.com
(228)-762-0268


-----Original Message-----
From: netfilter-devel-admin@lists.samba.org
[mailto:netfilter-devel-admin@lists.samba.org] On Behalf Of Harald Welte
Sent: Thursday, June 27, 2002 6:26 AM
To: Amir Khandani
Cc: netfilter-devel@lists.samba.org
Subject: Re: MSN Messenger ALG

On Wed, Jun 26, 2002 at 11:44:14AM -0700, Amir Khandani wrote:
> Hi,
> Is there a ALG for MSN Messenger in iptables? I need that to get file
> transfer and voice working between NATed clients.

I assume you are talking about the SIP protocol?

No, nobody came up to either write or sponsor support for SIP yet. It's
a fairly complex protocol...

> thanks for any help,
> -amir

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org
http://www.gnumonks.org/
========================================================================
====
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O-
M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

Re: MSN Messenger ALG

[Patrick Schaaf]

On Thu, Jun 27, 2002 at 12:01:05PM -0500, Glover George wrote:
> Yes, SIP can get very hairy, because it's primarily xml -ished based.

SIP is very similar to HTTP, and thus any special protocol action would
best be handled by the traditional application level gateway. The REDIRECT
target can be used to transparently address that gateway.

There's no need for any new magic within iptables, I think.

best regards
  Patrick

Re: MSN Messenger ALG

[Harald Welte]

On Thu, Jun 27, 2002 at 07:49:14PM +0200, Patrick Schaaf wrote:
> On Thu, Jun 27, 2002 at 12:01:05PM -0500, Glover George wrote:
> > Yes, SIP can get very hairy, because it's primarily xml -ished based.
> 
> SIP is very similar to HTTP, and thus any special protocol action would
> best be handled by the traditional application level gateway. The REDIRECT
> target can be used to transparently address that gateway.
> 
> There's no need for any new magic within iptables, I think.

yes, there is. Please believe me, I've spent days reading through the
SIP specs and reading all the documents about SIP firewall/NAT
traversal.

People have even written Master Thesis' about this issue, because of
it's complexity.

In the end, a combination of an application-level proxy and the
firewall/nat device is needed, where the proxy is instructing the
firewall/nat device what to do.

> best regards
>   Patrick

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

Re: MSN Messenger ALG

[Harald Welte]

On Thu, Jun 27, 2002 at 12:01:05PM -0500, Glover George wrote:
> Yes, SIP can get very hairy, because it's primarily xml -ished based.
> The proper way to make MSN Messenger work is using Universal Plug n Play
> to do nat traversal.  http://linux-igd.sourceforge.net will make this
> work (every feature except file transfer, which we at the UPnP forum are
> trying to get Microsoft to hurry up and fix (along with many router
> vendors)).  

For security reason I'd _never ever_ run a upnp igd on any firewall.
This is just insane.  The firewall has no possibility of knowing if the 
upnp request is sent by a 'legitimate application' or by some new
outlook macro virus.

> If there was indeed an SIP conntrack however, it would be so much nicer,
> because there are a lot of packages coming out that use SIP but do not
> use UPnP.  It's just a matter of sparking enough interest in it to get
> someone knowledgeable in netfilter to write one (or someone learning
> from scratch).

the SIP/SDP helper would be the most complex conntrack helper for
netfilter.  Even H.323 is harmless compared to the full SIP/SDP
protocol.  And there are corner cases like encrypted/authenticated SDP
messages where you will never be able to do NAT.


> Glover George
> Systems/Networks Administrator

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org               http://www.gnumonks.org/
============================================================================
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O- M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

RE: MSN Messenger ALG

[Glover George]

As previously stated before.  We make no assumption that this is secure.
UPnP is finishing up a security mechanism to add on to the UPnP spec for
version 1.0, and version 2.0 of UPnP is not far off, so security
mechanisms are being put in place.   But for the moment, AS WITH
ANYTHING, if you take proper precautions to ensure that your rules in
iptables will prevent any untrusted machines from access UPnP gateway in
the first place, then you don't have these problems.  Sure an app could
request it, but so what?  An app could fake itself into being h.323 as
well.  

A UPnP IGD in version 1.0 is always simply a connectivity device, with
NO implications that it is secure.  The DOCS state it, the website
states it, UPnP forum states it, as well as I and many of my colleagues
on this list.

If there was ever an assumption that it is 100% secure, sorry for
misleading.  Nothing is 100% secure.

Glover George
Systems/Networks Administrator
Gulf Sales & Supply, Inc.
dime@gulfsales.com
(228)-762-0268


-----Original Message-----
From: Harald Welte [mailto:laforge@gnumonks.org] 
Sent: Thursday, June 27, 2002 1:13 PM
To: Glover George
Cc: 'Amir Khandani'; netfilter-devel@lists.samba.org
Subject: Re: MSN Messenger ALG

On Thu, Jun 27, 2002 at 12:01:05PM -0500, Glover George wrote:
> Yes, SIP can get very hairy, because it's primarily xml -ished based.
> The proper way to make MSN Messenger work is using Universal Plug n
Play
> to do nat traversal.  http://linux-igd.sourceforge.net will make this
> work (every feature except file transfer, which we at the UPnP forum
are
> trying to get Microsoft to hurry up and fix (along with many router
> vendors)).  

For security reason I'd _never ever_ run a upnp igd on any firewall.
This is just insane.  The firewall has no possibility of knowing if the 
upnp request is sent by a 'legitimate application' or by some new
outlook macro virus.

> If there was indeed an SIP conntrack however, it would be so much
nicer,
> because there are a lot of packages coming out that use SIP but do not
> use UPnP.  It's just a matter of sparking enough interest in it to get
> someone knowledgeable in netfilter to write one (or someone learning
> from scratch).

the SIP/SDP helper would be the most complex conntrack helper for
netfilter.  Even H.323 is harmless compared to the full SIP/SDP
protocol.  And there are corner cases like encrypted/authenticated SDP
messages where you will never be able to do NAT.


> Glover George
> Systems/Networks Administrator

-- 
Live long and prosper
- Harald Welte / laforge@gnumonks.org
http://www.gnumonks.org/
========================================================================
====
GCS/E/IT d- s-: a-- C+++ UL++++$ P+++ L++++$ E--- W- N++ o? K- w--- O-
M- 
V-- PS+ PE-- Y+ PGP++ t++ 5-- !X !R tv-- b+++ DI? !D G+ e* h+ r% y+(*)

Re: MSN Messenger ALG

[Brian J. Murrell]

[-- Attachment #1: Type: text/plain, Size: 1718 bytes --]

On Fri, Jun 28, 2002 at 08:46:57AM -0500, Glover George wrote:
> 
> UPnP is finishing up a security mechanism to add on to the UPnP spec for
> version 1.0,

Any pointers to these mechanisms?  I can't think of anything that
would work, in real life.  The issue is who can a UPnP gateway trust?
In the definition of "who" is "who is running the app?", as well as
"what is the app?" among other quesitons.

It seems that everybody wants this UPnP gateway for MSN Messenger, but
in my security policy, MS applications are automaticlly excluded from
using the UPnP gateway due to MS's constant obvious disregard for
security in favour of doing whatever they need to to make things work.

> and version 2.0 of UPnP is not far off, so security
> mechanisms are being put in place.

Again, anything I can read?

> But for the moment, AS WITH
> ANYTHING, if you take proper precautions to ensure that your rules in
> iptables will prevent any untrusted machines

Machines is not so much the issue as apps on those machines.  I am not
giving an MS machine access to the gateway because there is a trusted
app on it that wants to use the gateway when there are also untrusted
apps on the same machine or easily installable on the same machine.

Security for a UPnP gateway needs to be more fine grained than just
trusting machines.

> from access UPnP gateway in
> the first place, then you don't have these problems.  Sure an app could
> request it, but so what?  An app could fake itself into being h.323 as
> well.  

Right.  It is this faking that needs to be addressed.  How do I
know that an app that is claiming to be "trusted app foo" really is
foo.

b.

-- 
Brian J. Murrell

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

RE: MSN Messenger ALG

[Glover George]

> On Fri, Jun 28, 2002 at 08:46:57AM -0500, Glover George wrote:
> >
> > UPnP is finishing up a security mechanism to add on to the UPnP spec
for
> > version 1.0,
> 
> Any pointers to these mechanisms?  I can't think of anything that
> would work, in real life.  The issue is who can a UPnP gateway trust?
> In the definition of "who" is "who is running the app?", as well as
> "what is the app?" among other quesitons.

The only pointers I can give is if you can't trust the apps on the
system, the just hold off on making it work for a business like
environment, or somewhere where you're really worried about it.  It
works great for home networks, which for the moment is all it should be
intended for.  I make no claims that someone should use this in a
productive environment where security is at the utmost concern.

That said, I am planning on adding some port/ip verifications, but
that's not the best solution.  The best solution is to wait for the
security aspects of UPnP to be implemented in the spec, and then for
Microsoft to catch up (which as we've seen with the file transfer option
in Messenger, has taken them ridiculously far too long  - since 4.0 to
now, it's still not fixed).

Maybe I should start prefixing these emails out with, if this is for a
home network, but be sure to read the SECURITY doc included in the
distribution.


> 
> It seems that everybody wants this UPnP gateway for MSN Messenger, but
> in my security policy, MS applications are automaticlly excluded from
> using the UPnP gateway due to MS's constant obvious disregard for
> security in favour of doing whatever they need to to make things work.
> 
> > and version 2.0 of UPnP is not far off, so security
> > mechanisms are being put in place.
> 
> Again, anything I can read?
>

It takes Microsoft years to do anything, as well as process my
application to the UPnP members forums.  I'm in contact with the guys at
Thomson Multimedia (formerly owned by Alcatel) who does the modems and
routers, who is currently a member, and he has notified me of it.  Trust
me, I'm taking this up as a college research project (UPnP on linux) and
it won't just go away.  We'll be including Linux's 2 cents in there, for
whatever good it will do.

 
> > But for the moment, AS WITH
> > ANYTHING, if you take proper precautions to ensure that your rules
in
> > iptables will prevent any untrusted machines
> 
> Machines is not so much the issue as apps on those machines.  I am not
> giving an MS machine access to the gateway because there is a trusted
> app on it that wants to use the gateway when there are also untrusted
> apps on the same machine or easily installable on the same machine.
> 
> Security for a UPnP gateway needs to be more fine grained than just
> trusting machines.
> 

I agree.  Some form of authentication between the apps and the gateway.

> > from access UPnP gateway in
> > the first place, then you don't have these problems.  Sure an app
could
> > request it, but so what?  An app could fake itself into being h.323
as
> > well.
> 
> Right.  It is this faking that needs to be addressed.  How do I
> know that an app that is claiming to be "trusted app foo" really is
> foo.
>