All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Jesse W. Asher" <jasher1@tampabay.rr.com>
To: netfilter@lists.samba.org
Subject: Re: Natted IRC "inherently insecure"?
Date: Mon, 08 Jul 2002 19:26:00 -0400	[thread overview]
Message-ID: <3D2A1F88.9040102@tampabay.rr.com> (raw)
In-Reply-To: 20020708001941.GC653@ns

[-- 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 --]

  parent reply	other threads:[~2002-07-08 23:26 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-07-04 11:42 Natted IRC "inherently insecure"? Jesse W. Asher
2002-07-08  0:19 ` Stephen Frost
2002-07-08  0:38   ` Martin Josefsson
2002-07-08 23:26   ` Jesse W. Asher [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-07-04 22:10 George Vieira

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3D2A1F88.9040102@tampabay.rr.com \
    --to=jasher1@tampabay.rr.com \
    --cc=netfilter@lists.samba.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.