All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven M Campbell <Netfilter@SCampbell.net>
To: netfilter@lists.netfilter.org
Subject: Re: Dynamic DNS
Date: Sat, 12 Mar 2005 10:25:59 -0500	[thread overview]
Message-ID: <42330A07.8070605@SCampbell.net> (raw)
In-Reply-To: <Pine.LNX.4.60.0503102052440.16999@darkstar.sysinfo.com>

R. DuFresne wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, 10 Mar 2005, Steven M Campbell wrote:
>
>> R. DuFresne wrote:
>>
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On Wed, 9 Mar 2005, Steven M Campbell wrote:
>>>
>>>> Sebastian Docktor wrote:
>>>>
>>>>> Hi,
>>>>>
>>>>> I want to allow a Dynamic DNS Client to Access the SSH-Server on 
>>>>> my Firewall. But I don't want to open SSH for all IPs,
>>>>> Is it possible that iptables always looks up the ip address from 
>>>>> the hostname, so that only the ip has access which is registrated 
>>>>> under
>>>>> the dyndns?
>>>>>
>>>>>
>>>>
>>>> IMO, it's a very bad idea to lower the security of iptables 
>>>> firewall by making it dependent on DNS for any portion of 
>>>> authorization certification. DNS isn't exactly known for it's 
>>>> stellar security :) Allow me to suggest an alternate path.  Use RSA 
>>>> keyfiles and disallow ssh password authentication, this way you can 
>>>> leave the port open but user's without public keys installed on the 
>>>> server cannot gain access. Generally speaking DNS should have 
>>>> nothing to do with anyone's firewall because DNS would then become 
>>>> the weak link in the security chain and SSH has methods that are 
>>>> better applied to these needs.
>>>>
>>>
>>> Ahh, but this closes one sec loophole and pens another, sshd, which 
>>> has gotten hit with quite a few sec issues.  Keeping the sshd port 
>>> closed to the outside except a few 'special' systems makes the 
>>> likelyhood of a system compromise due to sshd extremely unlikely.
>>>
>>> Thanks,
>>>
>>> Ron DuFresne
>>> - -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>>>         admin & senior security consultant:  sysinfo.com
>>>                         http://sysinfo.com
>>>
>> I underscore my statement that it also reduces the effectiveness of 
>> the firewall by introducing the security challanged dynamic dns as an 
>> authentication model and possibly introducing new attacks based on 
>> the extension.   It is telling that, even though this is a fairly 
>> easy extension to implement, no one in the firewall marketplace does 
>> this and, IMO, for good reason.  In the specific case of the original 
>> poster I would:  Use ip tables to lock down access to the subnets 
>> where this dynamic device could appear and then use the SSH auth 
>> mechanism to deal with the hostname lookup and, as always, keep my 
>> applications (like SSH) up to date... or, even better, if I really 
>> want to call that client a secured host lock down it's address. For 
>> an internet based host a good port-knocking would fair far better 
>> than trusting dns.
>>
>
> That's not my disagreement.  I'd not rely upon DNS, yet I would not 
> leave sshd open not directly to the firewall, nor likely through it, 
> except to specific IP's, and those likely have to be static.  I missed 
> till a reread that you advised controls via sshd <and in most cases 
> tcpd as well>, which was my push in the thread, seems we agreeed all 
> along and I missed that <smile>.
>
> Thanks,
>
> Ron DuFresne
> - -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>         admin & senior security consultant:  sysinfo.com
>                         http://sysinfo.com

Yes, we both agree the best place to put the effort here would be to 
limit the ip address on that client machine, lock down to that address 
set and do what one can to keep sshd secured.   Using Dynamic DNS to 
determine who can gain access to ones firewall is like putting key under 
the front door mat.



  parent reply	other threads:[~2005-03-12 15:25 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-09  6:25 Dynamic DNS Sebastian Docktor
2005-03-09  6:29 ` Brent Clark
2005-03-09  8:04   ` Kenneth Kalmer
2005-03-09 22:35     ` R. DuFresne
2005-03-09  9:07 ` Jose Maria Lopez Hernandez
2005-03-09 10:35   ` Nick Drage
2005-03-09 11:03     ` Jose Maria Lopez Hernandez
2005-03-13 16:28     ` Sebastian Docktor
2005-03-09 15:17 ` Maxime Ducharme
2005-03-09 15:26   ` Maxime Ducharme
2005-03-09 19:34   ` Jason Opperisano
2005-03-09 20:33     ` Maxime Ducharme
2005-03-09 20:41 ` Steven M Campbell
2005-03-09 20:58   ` Steven M Campbell
2005-03-09 22:51   ` R. DuFresne
     [not found]     ` <42304A9A.7050207@SCampbell.net>
     [not found]       ` <Pine.LNX.4.60.0503102052440.16999@darkstar.sysinfo.com>
2005-03-12 15:25         ` Steven M Campbell [this message]
  -- strict thread matches above, loose matches on Subject: below --
2005-03-09  8:53 Sietse van Zanen

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=42330A07.8070605@SCampbell.net \
    --to=netfilter@scampbell.net \
    --cc=netfilter@lists.netfilter.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.