<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments for cmdln.org (a sysadmin blog)</title>
	<atom:link href="http://www.cmdln.org/comments/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.cmdln.org</link>
	<description>a system administrators mutterings</description>
	<pubDate>Sat, 11 Oct 2008 20:32:52 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5</generator>
		<item>
		<title>Comment on Backdoor corporate sabotage with DNS by spenser</title>
		<link>http://www.cmdln.org/2008/07/09/backdoor-corporate-sabotage-with-dns/#comment-570</link>
		<dc:creator>spenser</dc:creator>
		<pubDate>Mon, 29 Sep 2008 07:15:00 +0000</pubDate>
		<guid isPermaLink="false">http://www.cmdln.org/?p=79#comment-570</guid>
		<description>At least one poster has said that the provider ought to be compensated for the bandwidth consumed in answering sudden increases in bogus requests. This is a real stretch because the bandwidth is on monthly commits, *and* dns takes *very* little bandwidth. 

While the overage charges are quite reasonable at dnsmadeeasy, the same is not true at ultradns/neustar. For the latter, overage rates could be termed punitive. So, the customer is stuck between buying a much larger subscription than normally required, or stand naked in the face of sudden surges.

For the particularly evil minded, it might even seem possible that a commissioned sales rep on his own, or an organised effort, might be behind such scenarios. Just imagine being able to bump current earnings as well as simultaneously driving the customer towards a bigger monthly commit through the simple exercise of a few cpu cycles.

As for the idea that a 1000 identical requests could come from a burst behind a firewall, that is just ludicrous. Client machines are pointed at dns caches. Often the one on the firewall. Well, that dns cache has it cached and does not need to get the record 999 extra times.

In the end, throttling is good business. It is one element in evading dns ddos. This means that *other* customers on the dns servers are affected less. This in turn means that they *stay* customers after the ddos has subsided.


Throttling cannot always be implemented without risk, but it has attractions to both the provider and customer. Never forget that the customer is not the only customer resident on the system. Collateral damage can be very expensive.

&lt;a href="http://edgedirector.com/" rel="nofollow"&gt;edgedirector.com&lt;/a&gt; charges strictly on a pay for what you use basis at a single rate. And, query credits never expire, they just carry forward forever. You bought it, it's yours. Not like prepaid cell phones and vanishing minutes.</description>
		<content:encoded><![CDATA[<p>At least one poster has said that the provider ought to be compensated for the bandwidth consumed in answering sudden increases in bogus requests. This is a real stretch because the bandwidth is on monthly commits, *and* dns takes *very* little bandwidth. </p>
<p>While the overage charges are quite reasonable at dnsmadeeasy, the same is not true at ultradns/neustar. For the latter, overage rates could be termed punitive. So, the customer is stuck between buying a much larger subscription than normally required, or stand naked in the face of sudden surges.</p>
<p>For the particularly evil minded, it might even seem possible that a commissioned sales rep on his own, or an organised effort, might be behind such scenarios. Just imagine being able to bump current earnings as well as simultaneously driving the customer towards a bigger monthly commit through the simple exercise of a few cpu cycles.</p>
<p>As for the idea that a 1000 identical requests could come from a burst behind a firewall, that is just ludicrous. Client machines are pointed at dns caches. Often the one on the firewall. Well, that dns cache has it cached and does not need to get the record 999 extra times.</p>
<p>In the end, throttling is good business. It is one element in evading dns ddos. This means that *other* customers on the dns servers are affected less. This in turn means that they *stay* customers after the ddos has subsided.</p>
<p>Throttling cannot always be implemented without risk, but it has attractions to both the provider and customer. Never forget that the customer is not the only customer resident on the system. Collateral damage can be very expensive.</p>
<p><a href="http://edgedirector.com/" rel="nofollow">edgedirector.com</a> charges strictly on a pay for what you use basis at a single rate. And, query credits never expire, they just carry forward forever. You bought it, it&#8217;s yours. Not like prepaid cell phones and vanishing minutes.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Change KDE 4 panel clock to 12hr from 24hr military by me</title>
		<link>http://www.cmdln.org/2008/06/15/change-kde-4-panel-clock-to-12hr-from-24hr-military/#comment-548</link>
		<dc:creator>me</dc:creator>
		<pubDate>Wed, 17 Sep 2008 17:41:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.cmdln.org/?p=78#comment-548</guid>
		<description>thanks</description>
		<content:encoded><![CDATA[<p>thanks</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Reset mysql root password by Reset Forgotten MySQL Root Password &#187; mail to adi@kusumayadi.web.id</title>
		<link>http://www.cmdln.org/2008/02/09/reset-mysql-root-password/#comment-545</link>
		<dc:creator>Reset Forgotten MySQL Root Password &#187; mail to adi@kusumayadi.web.id</dc:creator>
		<pubDate>Tue, 16 Sep 2008 04:09:52 +0000</pubDate>
		<guid isPermaLink="false">http://www.cmdln.org/2008/02/09/reset-mysql-root-password/#comment-545</guid>
		<description>[...] Have you ever forgotten the root password on one of your MySQL servers? No? Well maybe I’m not as perfect as you. This is a quick h00tow (how to) reset your MySQL root password. It does require root access on your server. If you have forgotten that password wait for another article. Original article posted on  reset mysql root password. [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] Have you ever forgotten the root password on one of your MySQL servers? No? Well maybe I’m not as perfect as you. This is a quick h00tow (how to) reset your MySQL root password. It does require root access on your server. If you have forgotten that password wait for another article. Original article posted on  reset mysql root password. [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on 10 Traits of a Successful SysAdmin by Charles Hamilton</title>
		<link>http://www.cmdln.org/2008/08/29/10-traits-of-a-successful-sysadmin/#comment-539</link>
		<dc:creator>Charles Hamilton</dc:creator>
		<pubDate>Fri, 29 Aug 2008 15:50:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.cmdln.org/?p=82#comment-539</guid>
		<description>I really liked this post, and incidentally, these traits make a successful person in general.  Even the lazy part speaks to being proactive instead of reactive.</description>
		<content:encoded><![CDATA[<p>I really liked this post, and incidentally, these traits make a successful person in general.  Even the lazy part speaks to being proactive instead of reactive.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Backdoor corporate sabotage with DNS by cmdln</title>
		<link>http://www.cmdln.org/2008/07/09/backdoor-corporate-sabotage-with-dns/#comment-537</link>
		<dc:creator>cmdln</dc:creator>
		<pubDate>Fri, 29 Aug 2008 06:49:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.cmdln.org/?p=79#comment-537</guid>
		<description>Matt, 
Thanks for the comment. I do believe thats one of the best comments I have had yet. I do enjoy it when someone else validates one of my thoughts, but even more so when someone actually thinks and takes time to write a sensible reply.

Hope you stick around, i pop by standalone-sysadmin from time to time good work, keep it up. There definitely are not enough admins sharing info!</description>
		<content:encoded><![CDATA[<p>Matt,<br />
Thanks for the comment. I do believe thats one of the best comments I have had yet. I do enjoy it when someone else validates one of my thoughts, but even more so when someone actually thinks and takes time to write a sensible reply.</p>
<p>Hope you stick around, i pop by standalone-sysadmin from time to time good work, keep it up. There definitely are not enough admins sharing info!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Backdoor corporate sabotage with DNS by Matt Simmons</title>
		<link>http://www.cmdln.org/2008/07/09/backdoor-corporate-sabotage-with-dns/#comment-533</link>
		<dc:creator>Matt Simmons</dc:creator>
		<pubDate>Wed, 27 Aug 2008 23:29:46 +0000</pubDate>
		<guid isPermaLink="false">http://www.cmdln.org/?p=79#comment-533</guid>
		<description>Wow, Michael, a bit harsh, eh? 

Greg and Michael, this sort of attack is a valid concern, and should be considered tantamount to a DOS, since if you can't pay the bill, your service is gone. 

Every good IPS should have the ability to throttle service requests, especially ones that originate from the same IP. As CMDLN stated, there's no valid reason for the same IP to make hundreds of DNS requests a day, let alone in a second. He's right, TTL should be respected, and even in clients where it isn't, I've never even seen a setting for force recaching in shorter than 300 seconds (5 minutes). 

The most extreme case I can think of, a slashdotting, with fark, reddit, and digg all pointing to your site, still shouldn't generate that sort of traffic. The effects &lt;a href="http://standalone-sysadmin.blogspot.com/2008/07/effects-of-slashdot.html" rel="nofollow"&gt;are severe&lt;/a&gt;, but nothing like what CMDLN spoke of. 

The onus should be on the DNS providers to filter this sort of ridiculous traffic storm. Logging only tells you where the traffic came from; it won't get money back. It would probably be a good idea to select a DNS provider that will agree to filter suspicious traffic for you or not hold you liable for a DOS attack. 

Good article, CMDLN, I enjoyed it.</description>
		<content:encoded><![CDATA[<p>Wow, Michael, a bit harsh, eh? </p>
<p>Greg and Michael, this sort of attack is a valid concern, and should be considered tantamount to a DOS, since if you can&#8217;t pay the bill, your service is gone. </p>
<p>Every good IPS should have the ability to throttle service requests, especially ones that originate from the same IP. As CMDLN stated, there&#8217;s no valid reason for the same IP to make hundreds of DNS requests a day, let alone in a second. He&#8217;s right, TTL should be respected, and even in clients where it isn&#8217;t, I&#8217;ve never even seen a setting for force recaching in shorter than 300 seconds (5 minutes). </p>
<p>The most extreme case I can think of, a slashdotting, with fark, reddit, and digg all pointing to your site, still shouldn&#8217;t generate that sort of traffic. The effects <a href="http://standalone-sysadmin.blogspot.com/2008/07/effects-of-slashdot.html" rel="nofollow">are severe</a>, but nothing like what CMDLN spoke of. </p>
<p>The onus should be on the DNS providers to filter this sort of ridiculous traffic storm. Logging only tells you where the traffic came from; it won&#8217;t get money back. It would probably be a good idea to select a DNS provider that will agree to filter suspicious traffic for you or not hold you liable for a DOS attack. </p>
<p>Good article, CMDLN, I enjoyed it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Shared console sessions by Console sharing without setuid gnu screen &#124; cmdln.org (a sysadmin blog)</title>
		<link>http://www.cmdln.org/2008/08/13/shared-console-sessions/#comment-532</link>
		<dc:creator>Console sharing without setuid gnu screen &#124; cmdln.org (a sysadmin blog)</dc:creator>
		<pubDate>Mon, 25 Aug 2008 21:34:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.cmdln.org/?p=80#comment-532</guid>
		<description>[...] mentioned in my last post Shared console sessions that I would have an update to get near same functionality without setuid of the screen binary. [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] mentioned in my last post Shared console sessions that I would have an update to get near same functionality without setuid of the screen binary. [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Zabbix 1.4.4 from source on Debian Etch by Linux Family &#187; Blog Archive &#187; Zabbix 1.4.4 From Source On Debian Etch</title>
		<link>http://www.cmdln.org/2008/02/10/zabbix-144-from-source-on-debian-etch/#comment-529</link>
		<dc:creator>Linux Family &#187; Blog Archive &#187; Zabbix 1.4.4 From Source On Debian Etch</dc:creator>
		<pubDate>Tue, 19 Aug 2008 07:15:43 +0000</pubDate>
		<guid isPermaLink="false">http://www.cmdln.org/2008/02/10/zabbix-144-from-source-on-debian-etch/#comment-529</guid>
		<description>[...] posted on  Zabbix 1.4.4 from source on Debian Etch. This guide will walk you through installing Zabbix 1.4.4 from source on Debian Etch. 1.4.4 has [...]</description>
		<content:encoded><![CDATA[<p>[&#8230;] posted on  Zabbix 1.4.4 from source on Debian Etch. This guide will walk you through installing Zabbix 1.4.4 from source on Debian Etch. 1.4.4 has [&#8230;]</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Restricting SSH commands by Alex</title>
		<link>http://www.cmdln.org/2008/02/11/restricting-ssh-commands/#comment-528</link>
		<dc:creator>Alex</dc:creator>
		<pubDate>Sat, 16 Aug 2008 10:53:02 +0000</pubDate>
		<guid isPermaLink="false">http://www.cmdln.org/2008/02/11/restricting-ssh-commands/#comment-528</guid>
		<description>Your blog is interesting! 
 
Keep up the good work!</description>
		<content:encoded><![CDATA[<p>Your blog is interesting! </p>
<p>Keep up the good work!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on Testing Email Manually with Telnet (spoofing email) by aashiche</title>
		<link>http://www.cmdln.org/2008/04/06/testing-email-manually-with-telnet-spoofing-email/#comment-527</link>
		<dc:creator>aashiche</dc:creator>
		<pubDate>Fri, 15 Aug 2008 19:40:49 +0000</pubDate>
		<guid isPermaLink="false">http://www.cmdln.org/?p=50#comment-527</guid>
		<description>nice use of telnet but how can someone know the exact domain of his/her company.
would u send this on my email.
thanks.</description>
		<content:encoded><![CDATA[<p>nice use of telnet but how can someone know the exact domain of his/her company.<br />
would u send this on my email.<br />
thanks.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
