[?] DYNDNS host vulnerability

Hello all,

it's convenient to use a DYNDNS domain name like myhost.dyndns.org.
I guess, though, that the host myhost.dyndns.org would be much
more vulnerable as for crackers there is no need to watch out
for a dynamic IP that changes every day (at least in Germany).

Background: Every now and then I do some administration on a
server of a friend via

(E-Mail Removed)

It would be nice to do this instead via

name@friends_host.dyndns.org

so there would be no need to let me know which dynamic IP his
router currently uses. This is what DYNDNS is supposed to do.
Nevertheless, if a cracker tries to crack into a host, he
would be happy not to care for dynamic IPs. Rather he would
be happy to rework on "friends_host.dyndns.org" without
caring for IP changes.

Am I correct or did I miss something?

If I were correct, weak login names and passwords would
be no problem, even with ssh - right?

Thanks and regards,
Frank

Fr@nk Stef@ni wrote:
> Hello all,
>
> it's convenient to use a DYNDNS domain name like myhost.dyndns.org.
> I guess, though, that the host myhost.dyndns.org would be much
> more vulnerable as for crackers there is no need to watch out
> for a dynamic IP that changes every day (at least in Germany).
>
> Background: Every now and then I do some administration on a
> server of a friend via
>
> (E-Mail Removed)
>
> It would be nice to do this instead via
>
> name@friends_host.dyndns.org
>
> so there would be no need to let me know which dynamic IP his
> router currently uses. This is what DYNDNS is supposed to do.
> Nevertheless, if a cracker tries to crack into a host, he
> would be happy not to care for dynamic IPs. Rather he would
> be happy to rework on "friends_host.dyndns.org" without
> caring for IP changes.
>
> Am I correct or did I miss something?
>
> If I were correct, weak login names and passwords would
> be no problem, even with ssh - right?
>
> Thanks and regards,
> Frank

What you're doing here is relying on security through obscurity - the
obscurity being that an attacker would be unable to follow your changing
IP from one day to the next, and hoping that he's unable to break in
during the 24hour timeframe until your IP changes.

Are you sure your IP will change once a day? Is it a policy set by the
ISP? It may change, if you're relying on a variable IP and it suddenly
becomes more or less static how long before you find out?

(My IP address is theoretically dynamic, but reading the documentation
available from my ISP it appears that the IP address is linked to my
router, I've had the same IP address for over six months now.)

Make sure your passwords are strong and your software is up to date,
monitor your log files. If your friend only needs to allow access now
and again it may be better to only run the ssh daemon when you need
access - a quick phone call to get him/her to start the ssh server.

--
Andy Ruddock
------------
andy_DOT_ruddock_AT_gmail_DOT_com (GPG Key ID 0x74F41E8F)

Andy Ruddock schrieb:
> Fr@nk Stef@ni wrote:
>> Hello all,
>>
>> it's convenient to use a DYNDNS domain name like myhost.dyndns.org.
>> I guess, though, that the host myhost.dyndns.org would be much
>> more vulnerable as for crackers there is no need to watch out
>> for a dynamic IP that changes every day (at least in Germany).
>>
>> Background: Every now and then I do some administration on a
>> server of a friend via
>>
>> (E-Mail Removed)
>>
>> It would be nice to do this instead via
>>
>> name@friends_host.dyndns.org
>>
>> so there would be no need to let me know which dynamic IP his
>> router currently uses. This is what DYNDNS is supposed to do.
>> Nevertheless, if a cracker tries to crack into a host, he
>> would be happy not to care for dynamic IPs. Rather he would
>> be happy to rework on "friends_host.dyndns.org" without
>> caring for IP changes.
>>
>> Am I correct or did I miss something?
>>
>> If I were correct, weak login names and passwords would
>> be no problem, even with ssh - right?
>>
>> Thanks and regards,
>> Frank
>
> What you're doing here is relying on security through obscurity - the
> obscurity being that an attacker would be unable to follow your changing
> IP from one day to the next, and hoping that he's unable to break in
> during the 24hour timeframe until your IP changes.
>
> Are you sure your IP will change once a day? Is it a policy set by the
> ISP? It may change, if you're relying on a variable IP and it suddenly
> becomes more or less static how long before you find out?
>
> (My IP address is theoretically dynamic, but reading the documentation
> available from my ISP it appears that the IP address is linked to my
> router, I've had the same IP address for over six months now.)
>
> Make sure your passwords are strong and your software is up to date,
> monitor your log files. If your friend only needs to allow access now
> and again it may be better to only run the ssh daemon when you need
> access - a quick phone call to get him/her to start the ssh server.

What we currently do, is exatly that. The routers firewall has all ports
closed and SSH port is always manually activation after a phone call.

My eyes opened up wide when I realized that the whole systems security
relies on a single strong password - though we have firewall and crypted SSH.
I guess, many systems worldwide are wide, wide open in this respect....

Frank

On Sat, 23 Feb 2008 00:16:36 +0100, Fr@nk Stef@ni rearranged some
electrons to say:

> Andy Ruddock schrieb:
>> Fr@nk Stef@ni wrote:
>>> Hello all,
>>>
>>> it's convenient to use a DYNDNS domain name like myhost.dyndns.org. I
>>> guess, though, that the host myhost.dyndns.org would be much more
>>> vulnerable as for crackers there is no need to watch out for a dynamic
>>> IP that changes every day (at least in Germany).
>>>
>>> Background: Every now and then I do some administration on a server of
>>> a friend via
>>>
>>> (E-Mail Removed)
>>>
>>> It would be nice to do this instead via
>>>
>>> name@friends_host.dyndns.org
>>>
>>> so there would be no need to let me know which dynamic IP his router
>>> currently uses. This is what DYNDNS is supposed to do. Nevertheless,
>>> if a cracker tries to crack into a host, he would be happy not to care
>>> for dynamic IPs. Rather he would be happy to rework on
>>> "friends_host.dyndns.org" without caring for IP changes.
>>>
>>> Am I correct or did I miss something?
>>>
>>> If I were correct, weak login names and passwords would be no problem,
>>> even with ssh - right?
>>>
>>> Thanks and regards,
>>> Frank
>>
>> What you're doing here is relying on security through obscurity - the
>> obscurity being that an attacker would be unable to follow your
>> changing IP from one day to the next, and hoping that he's unable to
>> break in during the 24hour timeframe until your IP changes.
>>
>> Are you sure your IP will change once a day? Is it a policy set by the
>> ISP? It may change, if you're relying on a variable IP and it suddenly
>> becomes more or less static how long before you find out?
>>
>> (My IP address is theoretically dynamic, but reading the documentation
>> available from my ISP it appears that the IP address is linked to my
>> router, I've had the same IP address for over six months now.)
>>
>> Make sure your passwords are strong and your software is up to date,
>> monitor your log files. If your friend only needs to allow access now
>> and again it may be better to only run the ssh daemon when you need
>> access - a quick phone call to get him/her to start the ssh server.
>
> What we currently do, is exatly that. The routers firewall has all ports
> closed and SSH port is always manually activation after a phone call.
>
> My eyes opened up wide when I realized that the whole systems security
> relies on a single strong password - though we have firewall and crypted
> SSH. I guess, many systems worldwide are wide, wide open in this
> respect....
>
> Frank

dyndns.org has nothing to do with the security of your system.

It's up to YOU to secure your system.

http://tldp.org/HOWTO/Security-Quick...WTO/index.html
http://tldp.org/HOWTO/Security-HOWTO/index.html

"Fr@nk Stef@ni" <(E-Mail Removed)> wrote:

>Andy Ruddock schrieb:
>> Fr@nk Stef@ni wrote:
>>> Hello all,
>>>
>>> it's convenient to use a DYNDNS domain name like myhost.dyndns.org.
>>> I guess, though, that the host myhost.dyndns.org would be much
>>> more vulnerable as for crackers there is no need to watch out
>>> for a dynamic IP that changes every day (at least in Germany).
>>>
>>> Background: Every now and then I do some administration on a
>>> server of a friend via
>>>
>>> (E-Mail Removed)
>>>
>>> It would be nice to do this instead via
>>>
>>> name@friends_host.dyndns.org
>>>
>>> so there would be no need to let me know which dynamic IP his
>>> router currently uses. This is what DYNDNS is supposed to do.
>>> Nevertheless, if a cracker tries to crack into a host, he
>>> would be happy not to care for dynamic IPs. Rather he would
>>> be happy to rework on "friends_host.dyndns.org" without
>>> caring for IP changes.
>>>
>>> Am I correct or did I miss something?
>>>
>>> If I were correct, weak login names and passwords would
>>> be no problem, even with ssh - right?
>>>
>>> Thanks and regards,
>>> Frank
>>
>> What you're doing here is relying on security through obscurity - the
>> obscurity being that an attacker would be unable to follow your changing
>> IP from one day to the next, and hoping that he's unable to break in
>> during the 24hour timeframe until your IP changes.

>My eyes opened up wide when I realized that the whole systems security
>relies on a single strong password - though we have firewall and crypted SSH.
>I guess, many systems worldwide are wide, wide open in this respect....
>
>Frank

Thats one of the reasons why it is recommended that you configure your
system to not allow "root" to log in remotely. Now, it is a matter of
guessing a valid user ID as well as a password, THEN trying to guess
"roots" password..

I also use non-standard ports for my admin services as well as
firewall rule to lockout multiple access attempts in a short period of
time.
--
------------------------------------------------
http://www3.sympatico.ca/dmitton
SPAM Reduction: Remove "x." from my domain.
------------------------------------------------

Doug Mitton wrote:

> Thats one of the reasons why it is recommended that you
> configure your system to not allow "root" to log in remotely.

The best thing is to use Public Key authentication with SSH and
disallow password access at all. That way there's simply no way
an intruder could get in, as long the SSHD itself has no
security leak. On the remote side you should put all the
programs you need for administrating things (but only those
programs) into sudoers so that your usual admin account can use
them w/o password. For everything else a password should be
required, or another account should be used.

> Now, it is a matter of guessing a valid user ID as well as a
> password, THEN trying to guess "roots" password..

And if you got pam_wheel, then only users in the wheel group
may "su".

> I also use non-standard ports for my admin services

Doesn't really aid in security. nmap tells you which ports are
open. And to see what deamon is behind it, you just do a trial
and error test of several protocols.

Port Knocking is here the better way to conceal things.

> as well as firewall rule to lockout multiple access attempts in
> a short period of time.

This is actually a good idea, but make the firewall rule so, that
only access attempts that failed to authenticate result in a
denial.

Wolfgang Draxinger
--
E-Mail address works, Jabber: (E-Mail Removed), ICQ: 134682867

Wolfgang Draxinger <(E-Mail Removed)> wrote:

>Doug Mitton wrote:
>
>> Thats one of the reasons why it is recommended that you
>> configure your system to not allow "root" to log in remotely.
>
>The best thing is to use Public Key authentication with SSH and
>disallow password access at all. That way there's simply no way
>an intruder could get in, as long the SSHD itself has no
>security leak. On the remote side you should put all the
>programs you need for administrating things (but only those
>programs) into sudoers so that your usual admin account can use
>them w/o password. For everything else a password should be
>required, or another account should be used.
>
>> Now, it is a matter of guessing a valid user ID as well as a
>> password, THEN trying to guess "roots" password..
>
>And if you got pam_wheel, then only users in the wheel group
>may "su".
>
>> I also use non-standard ports for my admin services
>
>Doesn't really aid in security. nmap tells you which ports are
>open. And to see what deamon is behind it, you just do a trial
>and error test of several protocols.
>
>Port Knocking is here the better way to conceal things.
>
>> as well as firewall rule to lockout multiple access attempts in
>> a short period of time.
>
>This is actually a good idea, but make the firewall rule so, that
>only access attempts that failed to authenticate result in a
>denial.
>
>Wolfgang Draxinger

All good ideas. The point being is that there are many solutions to
the problem and you just need to fix or implement those that are for
your specific requirements.

My system in particular has evolved over time due to situations which
have impacted me. The main reason for the 1) alternate server ports
and 2) lock-out after an excessive number of attempts per minute is to
cut down on the error logs generated by script-kiddies. Also, the
alternate server ports resolves issues with ISP's who block certain
ports getting into their address space.

To the OP ... good luck in your implementation. Also, if you "think"
you see a problem, do a search or post a message and you will get MANY
ideas!
--
------------------------------------------------
http://www3.sympatico.ca/dmitton
SPAM Reduction: Remove "x." from my domain.
------------------------------------------------

Doug Mitton wrote:

> All good ideas. Â*The point being is that there are many
> solutions to the problem and you just need to fix or implement
> those that are for your specific requirements.

At least Public Key authentication is easy to use. All you've to
do is generating a key pair, append the public key to the remote
site to $ACCOUNT_HOME/.ssh/authorized_keys2 and supply the
private key to ssh with the '-i'-option.

> cut down on the error logs generated by script-kiddies. Also,
> the alternate server ports resolves issues with ISP's who block
> certain ports getting into their address space.

Then get a better ISP. You got your own IP, when connected to the
Internet, all ports on that IP will only affect you. As long
your ISP doesn't share the IP with you (what it hopefully won't
do) there's simply no reason to block traffic on certain ports.
Technically you got a crippled Internet access, then.

Look up the contract with the ISP, if there's anything in it,
about letting ports x-y only through if "the moon is full and
venus in the house of scropio" or similair. If not, then demand
uncrippled access. If your ISP denies, due to demands by the
RIAA, MPAA, etc. to block P2P traffic, tell him, that protocols
are not bound to ports, especially P2P protocols. And if I'm not
totally wrong, it's illegal in democratic countries to filter by
the content (which in the case means also protocol), even if
nowadays many politicians tell you otherwise. Such filtering
would definitely be censorship.

Wolfgang Draxinger
--
E-Mail address works, Jabber: (E-Mail Removed), ICQ: 134682867

Wolfgang Draxinger <(E-Mail Removed)> wrote:

>Doug Mitton wrote:
>
>> cut down on the error logs generated by script-kiddies. Also,
>> the alternate server ports resolves issues with ISP's who block
>> certain ports getting into their address space.
>
>Then get a better ISP. You got your own IP, when connected to the
>Internet, all ports on that IP will only affect you. As long
>your ISP doesn't share the IP with you (what it hopefully won't
>do) there's simply no reason to block traffic on certain ports.
>Technically you got a crippled Internet access, then.
>
>Look up the contract with the ISP, if there's anything in it,
>about letting ports x-y only through if "the moon is full and
>venus in the house of scropio" or similair. If not, then demand
>uncrippled access. If your ISP denies, due to demands by the
>RIAA, MPAA, etc. to block P2P traffic, tell him, that protocols
>are not bound to ports, especially P2P protocols. And if I'm not
>totally wrong, it's illegal in democratic countries to filter by
>the content (which in the case means also protocol), even if
>nowadays many politicians tell you otherwise. Such filtering
>would definitely be censorship.
>
>Wolfgang Draxinger

If you do a search on my name for the last year or so you'll see I've
been posting to see if others on my ISP (one of Canada's largest) are
having the same issues ... and they are. I have a lot of problems
with my ISP ... all mainly just infrastructure connection issues.
But, they also change agreements right in the middle ... contract or
not.

And to complain ... the first issue is communication ... and not the
obvious one you'd expect for Canada ... Central Asia seems to be the
tech support supplier of choice.

<Now you've got me on a tangent :-) ><I could go on more here but I
won't! :-) >

Any way ... if the world were a perfect place ... what would we have
to gripe and have opinions about! :-)
--
------------------------------------------------
http://www3.sympatico.ca/dmitton
SPAM Reduction: Remove "x." from my domain.
------------------------------------------------

On Sat, 23 Feb 2008, in the Usenet newsgroup comp.os.linux.networking, in
article <(E-Mail Removed)>, Doug Mitton wrote:

>Wolfgang Draxinger <(E-Mail Removed)> wrote:

>>Doug Mitton wrote:
>>
>>> Also, the alternate server ports resolves issues with ISP's who block
>>> certain ports getting into their address space.
>>
>>Then get a better ISP. You got your own IP, when connected to the
>>Internet, all ports on that IP will only affect you. As long
>>your ISP doesn't share the IP with you (what it hopefully won't
>>do) there's simply no reason to block traffic on certain ports.

What planet/galaxy do you live on? It is very common for providers
to restrict access to/from ports and/or services based on the amount
of coin you are paying them. As for "no reason to block traffic on
certain ports" - how about the ISPs desire to stay off the various
block lists - or is spam and other net-abuse unknown in your world?

>>Technically you got a crippled Internet access, then.

Maybe that's what you are paying for.

>>Look up the contract with the ISP, if there's anything in it,
>>about letting ports x-y only through if "the moon is full and
>>venus in the house of scropio" or similair.

there's something about months with the letter 'r' in the name...

>>And if I'm not totally wrong, it's illegal in democratic countries
>>to filter by the content (which in the case means also protocol),
>>even if nowadays many politicians tell you otherwise. Such filtering
>>would definitely be censorship.

There are 246 countries listed in ISO-3166, some of which even have
the string "Democratic" in the English version of their name, but
rules, laws, and customs in one country do not always apply to all
or even any other country. In some countries, not only is some
filtering _allowed_ by law, but the right to filter is also protected
by law.

>If you do a search on my name for the last year or so you'll see I've
>been posting to see if others on my ISP (one of Canada's largest) are
>having the same issues ... and they are.

Obviously a lot depends on the type of contract/agreement you have with
your ISP. You may find it more useful to find a replacement, especially
if you are having problems with them.

>I have a lot of problems with my ISP ... all mainly just infrastructure
>connection issues. But, they also change agreements right in the
>middle ... contract or not.

Not enough details, but I'm in the US, and the usual solution here is
to unleash the legal types. Not that it is the ultimate solution
mind you, but changing agreements that are part of contract without
following all of the hoops is a no-no

>And to complain ... the first issue is communication ... and not the
>obvious one you'd expect for Canada ... Central Asia seems to be the
>tech support supplier of choice.

True - one of my ISPs (a Southwestern regional) has their support on
the other side of the globe - probably reduces the incidence of user
trying to shove a 4x4 up the fundamental of the "support" klown, but
I also have other ISPs, and two of them get support from Pittsburgh
for some bizarre reason.

>Any way ... if the world were a perfect place ... what would we have
>to gripe and have opinions about! :-)

I'm sure we'd find something. Your d4mn hockey team... ;-)

Old guy