Natted IRC "inherently insecure"?

Natted IRC "inherently insecure"?

[Jesse W. Asher]

Someone recently indicated to me that they believed that natting IRC 
through a firewall was "inherently insecure" and I wanted to get 
opinions on that statement.  I guess, in my mind, it isn't any more or 
less secure than any other service natted through the firewall - it all 
depends on how comfortable you feel with the inherent security of the 
client/tool that you're using.

Comments?

-- 
Jesse W. Asher              jasher1@tampabay.rr.com

RE: Natted IRC "inherently insecure"?

[George Vieira]

It is insecure if you use the older IRC module as there was a flaw..

thanks,
George Vieira
Systems Manager
Citadel Computer Systems P/L
http://www.citadelcomputer.com.au



-----Original Message-----
From: Jesse W. Asher [mailto:jasher1@tampabay.rr.com]
Sent: Thursday, 04 July 2002 9:42 PM
To: netfilter@lists.samba.org
Subject: Natted IRC "inherently insecure"?



Someone recently indicated to me that they believed that natting IRC 
through a firewall was "inherently insecure" and I wanted to get 
opinions on that statement.  I guess, in my mind, it isn't any more or 
less secure than any other service natted through the firewall - it all 
depends on how comfortable you feel with the inherent security of the 
client/tool that you're using.

Comments?

-- 
Jesse W. Asher              jasher1@tampabay.rr.com

Re: Natted IRC "inherently insecure"?

[Stephen Frost]

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

* Jesse W. Asher (jasher1@tampabay.rr.com) wrote:
> 
> Someone recently indicated to me that they believed that natting IRC 
> through a firewall was "inherently insecure" and I wanted to get 
> opinions on that statement.  I guess, in my mind, it isn't any more or 
> less secure than any other service natted through the firewall - it all 
> depends on how comfortable you feel with the inherent security of the 
> client/tool that you're using.
> 
> Comments?

The client/tool is one thing but I think what they were probably getting
at is the issue of DCC.  The problem with DCC is that it expects to be
able to reach any >1024 port on the remote system.  The two clients work
out, over the IRC network, the ports to use.  If your firewall doesn't
allow connections to high ports outbound or inbound, and you don't use
some kind of IRC helper in your firewall, then DCC won't work.  This may
be acceptable to you but some people feel they need DCC.  Using an IRC
helper in your firewall can mitigate these problems some.  They can't
fix everything though because of the way in which the DCC protocol
works.  A user using DCC can potentially allow a scan of the high ports
on at least the machine they're IRC'ing from.

Unfortunately I'm not very familiar with the internals of the netfilter
IRC-helper module or what checks it does but there are some things it
has no way to know due simply to where it has to be and what it gets to
see.  I havn't heard of many people getting attacked in such a way
though so the chances of you being exploited in that way are probably
pretty slim.  Unless you have someone going for you specifically using
an IRC helper will probably be enough.  Most attackers are going for
'easy' targets, things they can sweep large network blocks for; such as
the recent OpenSSH holes, various Windows-based services, etc.

	Stephen

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

Re: Natted IRC "inherently insecure"?

[Martin Josefsson]

On Mon, 2002-07-08 at 02:19, Stephen Frost wrote:

> > Comments?
> 
> The client/tool is one thing but I think what they were probably getting
> at is the issue of DCC.  The problem with DCC is that it expects to be
> able to reach any >1024 port on the remote system.  The two clients work
> out, over the IRC network, the ports to use.  If your firewall doesn't
> allow connections to high ports outbound or inbound, and you don't use
> some kind of IRC helper in your firewall, then DCC won't work.  This may
> be acceptable to you but some people feel they need DCC.  Using an IRC
> helper in your firewall can mitigate these problems some.  They can't
> fix everything though because of the way in which the DCC protocol
> works.  A user using DCC can potentially allow a scan of the high ports
> on at least the machine they're IRC'ing from.
> 
> Unfortunately I'm not very familiar with the internals of the netfilter
> IRC-helper module or what checks it does but there are some things it
> has no way to know due simply to where it has to be and what it gets to
> see.  I havn't heard of many people getting attacked in such a way
> though so the chances of you being exploited in that way are probably
> pretty slim.  Unless you have someone going for you specifically using
> an IRC helper will probably be enough.  Most attackers are going for
> 'easy' targets, things they can sweep large network blocks for; such as
> the recent OpenSSH holes, various Windows-based services, etc.

The only way to get a DCC expections set up is to send out a DCC request
and then the expectation will send packets only to the host that sent
the DCC request. This can be used to sort of add dynamic port-forwards
if you are sitting behind NAT. I don't see it as a real security-problem
as if you want real security you won't use a helper of any kind. And if
a DCC request is sent out with the purpose of letting an attacker in,
the chances are that the attacker already has access to this machine to
send out the DCC request because the user will probably not send it (or
perhaps it's a new email trojan for a certain unnamed mailclient? :).

-- 
/Martin

Never argue with an idiot. They drag you down to their level, then beat
you with experience.

Re: Natted IRC "inherently insecure"?

[Jesse W. Asher]

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


So, if the firewall is set up securely so that ports above 1024 are not 
unfiltered and a "helper application" is in place to help with DCC, then 
IRC is not "inherently insecure"?

Stephen Frost wrote:

>* Jesse W. Asher (jasher1@tampabay.rr.com) wrote:
>  
>
>>Someone recently indicated to me that they believed that natting IRC 
>>through a firewall was "inherently insecure" and I wanted to get 
>>opinions on that statement.  I guess, in my mind, it isn't any more or 
>>less secure than any other service natted through the firewall - it all 
>>depends on how comfortable you feel with the inherent security of the 
>>client/tool that you're using.
>>
>>Comments?
>>    
>>
>
>The client/tool is one thing but I think what they were probably getting
>at is the issue of DCC.  The problem with DCC is that it expects to be
>able to reach any >1024 port on the remote system.  The two clients work
>out, over the IRC network, the ports to use.  If your firewall doesn't
>allow connections to high ports outbound or inbound, and you don't use
>some kind of IRC helper in your firewall, then DCC won't work.  This may
>be acceptable to you but some people feel they need DCC.  Using an IRC
>helper in your firewall can mitigate these problems some.  They can't
>fix everything though because of the way in which the DCC protocol
>works.  A user using DCC can potentially allow a scan of the high ports
>on at least the machine they're IRC'ing from.
>
>Unfortunately I'm not very familiar with the internals of the netfilter
>IRC-helper module or what checks it does but there are some things it
>has no way to know due simply to where it has to be and what it gets to
>see.  I havn't heard of many people getting attacked in such a way
>though so the chances of you being exploited in that way are probably
>pretty slim.  Unless you have someone going for you specifically using
>an IRC helper will probably be enough.  Most attackers are going for
>'easy' targets, things they can sweep large network blocks for; such as
>the recent OpenSSH holes, various Windows-based services, etc.
>
>	Stephen
>  
>

-- 
Jesse W. Asher

"They that can give up essential liberty to purchase a little temporary
safety, deserve neither liberty or safety."  - Benjamin Franklin



[-- Attachment #2: Type: text/html, Size: 2760 bytes --]