<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: 57 Simple Sys Admin Mistakes that Someday You’ll Regret</title>
	<atom:link href="http://www.gfi.com/blog/57-simple-sys-admin-mistakes-that-someday-you-will-regret/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.gfi.com/blog/57-simple-sys-admin-mistakes-that-someday-you-will-regret/?utm_source=rss&#038;utm_medium=rss&#038;utm_campaign=57-simple-sys-admin-mistakes-that-someday-you-will-regret</link>
	<description>Brought to you by GFI Software</description>
	<lastBuildDate>Fri, 13 Sep 2013 13:27:20 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	
	<item>
		<title>By: Rob</title>
		<link>http://www.gfi.com/blog/57-simple-sys-admin-mistakes-that-someday-you-will-regret/comment-page-1/#comment-32294</link>
		<dc:creator>Rob</dc:creator>
		<pubDate>Wed, 25 Apr 2012 17:15:38 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfi.com/blog/?p=8432#comment-32294</guid>
		<description><![CDATA[Nice list, thanks for compiling that! Here are a few other simple, but very, very useful ones:
*Never* use the &quot;root&quot; account when logging into a system remotely, not even when using SSH. SSh is secure and all, but the PermitRootLogin option should always be set to &quot;No&quot;. This way, if you do have someone sniffing on your network and exploiting SSH in some way, they&#039;re still not gonna be able to sniff your root password. Also, just logging in as root &quot;because it&#039;ll allow you to do anything with no trouble&quot; just isn&#039;t an excuse and should be considered very, very bad practice. Also, on my own server, I&#039;ve seen lots and lots of script kiddies establishing a connection to my sshd and trying to brute force my root password. Well, that&#039;s never gonna lead to success once remote root logins are disabled, even if the attacker would guess the correct password for root.
Another no-brainer that&#039;s caused lots of trouble in the past is not checking file permissions. If, say, you edit the config file of a daemon and then put it in its appropriate directory, you&#039;ll most likely want that file to belong to that daemon&#039;s service user. Otherwise, you&#039;ll end up with annoying &quot;permission denied&quot; errors and services not being able to launch directory. This can also be a huge pain when you set up a mail service, but forget to assign the right permissions / ownerships to the directory where mail should be saved... :-)
My last suggestion is especially related to apt-based systems, such as Debian and Ubuntu. The apt-packaging system is sweet and easy to use, and can save a lot of compiling and installation time. Another thing that makes apt so &quot;sweet&quot; is the fact that it makes it very easy to deploy updates and apply security patches. Thus, my simple suggestion is to take advantage of that! Install a tool such as Apticron, which can check your apt repositories for updates on a daily basis, and will conveniently send out an EMail whenever an update is available. Take the time to read through the (mostly brief) changelogs, then log in and install the updates. This will take you about 2 minutes. I do not, however, recommend using any software that will update your system automatically. It&#039;s never good to lose control of what is going on on your system.
Not sure if everyone will agree with me on these points, just my 2 cents really! :-)
Happy hacking everyone.]]></description>
		<content:encoded><![CDATA[<p>Nice list, thanks for compiling that! Here are a few other simple, but very, very useful ones:<br />
*Never* use the &#8220;root&#8221; account when logging into a system remotely, not even when using SSH. SSh is secure and all, but the PermitRootLogin option should always be set to &#8220;No&#8221;. This way, if you do have someone sniffing on your network and exploiting SSH in some way, they&#8217;re still not gonna be able to sniff your root password. Also, just logging in as root &#8220;because it&#8217;ll allow you to do anything with no trouble&#8221; just isn&#8217;t an excuse and should be considered very, very bad practice. Also, on my own server, I&#8217;ve seen lots and lots of script kiddies establishing a connection to my sshd and trying to brute force my root password. Well, that&#8217;s never gonna lead to success once remote root logins are disabled, even if the attacker would guess the correct password for root.<br />
Another no-brainer that&#8217;s caused lots of trouble in the past is not checking file permissions. If, say, you edit the config file of a daemon and then put it in its appropriate directory, you&#8217;ll most likely want that file to belong to that daemon&#8217;s service user. Otherwise, you&#8217;ll end up with annoying &#8220;permission denied&#8221; errors and services not being able to launch directory. This can also be a huge pain when you set up a mail service, but forget to assign the right permissions / ownerships to the directory where mail should be saved&#8230; <img src='http://www.gfi.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /><br />
My last suggestion is especially related to apt-based systems, such as Debian and Ubuntu. The apt-packaging system is sweet and easy to use, and can save a lot of compiling and installation time. Another thing that makes apt so &#8220;sweet&#8221; is the fact that it makes it very easy to deploy updates and apply security patches. Thus, my simple suggestion is to take advantage of that! Install a tool such as Apticron, which can check your apt repositories for updates on a daily basis, and will conveniently send out an EMail whenever an update is available. Take the time to read through the (mostly brief) changelogs, then log in and install the updates. This will take you about 2 minutes. I do not, however, recommend using any software that will update your system automatically. It&#8217;s never good to lose control of what is going on on your system.<br />
Not sure if everyone will agree with me on these points, just my 2 cents really! <img src='http://www.gfi.com/blog/wp-includes/images/smilies/icon_smile.gif' alt=':-)' class='wp-smiley' /><br />
Happy hacking everyone.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: lewax00</title>
		<link>http://www.gfi.com/blog/57-simple-sys-admin-mistakes-that-someday-you-will-regret/comment-page-1/#comment-32266</link>
		<dc:creator>lewax00</dc:creator>
		<pubDate>Mon, 23 Apr 2012 23:09:40 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfi.com/blog/?p=8432#comment-32266</guid>
		<description><![CDATA[And you think Bing doesn&#039;t? I have news for you: if a service is free, you aren&#039;t the customer, you&#039;re the product.]]></description>
		<content:encoded><![CDATA[<p>And you think Bing doesn&#8217;t? I have news for you: if a service is free, you aren&#8217;t the customer, you&#8217;re the product.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dave</title>
		<link>http://www.gfi.com/blog/57-simple-sys-admin-mistakes-that-someday-you-will-regret/comment-page-1/#comment-32264</link>
		<dc:creator>Dave</dc:creator>
		<pubDate>Mon, 23 Apr 2012 18:09:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfi.com/blog/?p=8432#comment-32264</guid>
		<description><![CDATA[These tips are great. However; if you work for more than a small  organization where you are the admin, engineer, help desk, and have employees who never receive any training you will break a lot of the rules. Unless of course you like working 16 hour days.]]></description>
		<content:encoded><![CDATA[<p>These tips are great. However; if you work for more than a small  organization where you are the admin, engineer, help desk, and have employees who never receive any training you will break a lot of the rules. Unless of course you like working 16 hour days.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Roberto</title>
		<link>http://www.gfi.com/blog/57-simple-sys-admin-mistakes-that-someday-you-will-regret/comment-page-1/#comment-32220</link>
		<dc:creator>Roberto</dc:creator>
		<pubDate>Thu, 19 Apr 2012 15:26:36 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfi.com/blog/?p=8432#comment-32220</guid>
		<description><![CDATA[The only reason to use Google, is to be phished and data mined.]]></description>
		<content:encoded><![CDATA[<p>The only reason to use Google, is to be phished and data mined.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Christina Goggi</title>
		<link>http://www.gfi.com/blog/57-simple-sys-admin-mistakes-that-someday-you-will-regret/comment-page-1/#comment-32217</link>
		<dc:creator>Christina Goggi</dc:creator>
		<pubDate>Thu, 19 Apr 2012 13:01:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfi.com/blog/?p=8432#comment-32217</guid>
		<description><![CDATA[Hi Dude, there are two schools of thought on this controversial topic, but my own experiences have taught me that it is less risky to apply an untested patch than to not patch at all. The vast majority of incidents I have worked came down to someone exploiting an unpatched vulnerability.
 
Often, when a patch does cause a problem, it causes that problem with third party software, or non-standard configs, so if your servers are fairly vanilla, the risk is pretty low. Even with testing, if there is a problem with a patch, it may not show up until someone performs a task you didn&#039;t test for, like a month end closing, or a full backup, or an alignment of the flux capacitor, or a future update of your antivirus software, so at the end of the day, testing may reduce the risk of a patch introducing a problem but it cannot eliminate it.]]></description>
		<content:encoded><![CDATA[<p>Hi Dude, there are two schools of thought on this controversial topic, but my own experiences have taught me that it is less risky to apply an untested patch than to not patch at all. The vast majority of incidents I have worked came down to someone exploiting an unpatched vulnerability.</p>
<p>Often, when a patch does cause a problem, it causes that problem with third party software, or non-standard configs, so if your servers are fairly vanilla, the risk is pretty low. Even with testing, if there is a problem with a patch, it may not show up until someone performs a task you didn&#8217;t test for, like a month end closing, or a full backup, or an alignment of the flux capacitor, or a future update of your antivirus software, so at the end of the day, testing may reduce the risk of a patch introducing a problem but it cannot eliminate it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Richard Hobbs</title>
		<link>http://www.gfi.com/blog/57-simple-sys-admin-mistakes-that-someday-you-will-regret/comment-page-1/#comment-32215</link>
		<dc:creator>Richard Hobbs</dc:creator>
		<pubDate>Thu, 19 Apr 2012 09:13:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfi.com/blog/?p=8432#comment-32215</guid>
		<description><![CDATA[Point 41 is very true. However I would be poorer as I spend a lot of time fixing virus attacks when a user has disabled the anti-virus.]]></description>
		<content:encoded><![CDATA[<p>Point 41 is very true. However I would be poorer as I spend a lot of time fixing virus attacks when a user has disabled the anti-virus.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dude</title>
		<link>http://www.gfi.com/blog/57-simple-sys-admin-mistakes-that-someday-you-will-regret/comment-page-1/#comment-32210</link>
		<dc:creator>Dude</dc:creator>
		<pubDate>Wed, 18 Apr 2012 18:45:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfi.com/blog/?p=8432#comment-32210</guid>
		<description><![CDATA[nice list!

50. Deploying an untested patch is only  fractionally worse than…

51. Skipping a patch.


I have heard just deploy all patches as soon as possible, because exploits are developed in record time now a days. Finding the time to test every patch for every software for every configuration is impossible. If you have good nightly backups you can roll back updates in most cases and issues with patches are few and far between, at least for major vendors.

Or am I way off?]]></description>
		<content:encoded><![CDATA[<p>nice list!</p>
<p>50. Deploying an untested patch is only  fractionally worse than…</p>
<p>51. Skipping a patch.</p>
<p>I have heard just deploy all patches as soon as possible, because exploits are developed in record time now a days. Finding the time to test every patch for every software for every configuration is impossible. If you have good nightly backups you can roll back updates in most cases and issues with patches are few and far between, at least for major vendors.</p>
<p>Or am I way off?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Bill Gates</title>
		<link>http://www.gfi.com/blog/57-simple-sys-admin-mistakes-that-someday-you-will-regret/comment-page-1/#comment-32208</link>
		<dc:creator>Bill Gates</dc:creator>
		<pubDate>Wed, 18 Apr 2012 16:27:53 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfi.com/blog/?p=8432#comment-32208</guid>
		<description><![CDATA[Writing all your passwords in a little book and then accidentally throwing it away with the junk mail on your desk.]]></description>
		<content:encoded><![CDATA[<p>Writing all your passwords in a little book and then accidentally throwing it away with the junk mail on your desk.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Erik</title>
		<link>http://www.gfi.com/blog/57-simple-sys-admin-mistakes-that-someday-you-will-regret/comment-page-1/#comment-32207</link>
		<dc:creator>Erik</dc:creator>
		<pubDate>Wed, 18 Apr 2012 16:19:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfi.com/blog/?p=8432#comment-32207</guid>
		<description><![CDATA[The only reason to use Bing, is to search for Google.  Much the same: the only reason to use IE is to download Firefox / Chrome.]]></description>
		<content:encoded><![CDATA[<p>The only reason to use Bing, is to search for Google.  Much the same: the only reason to use IE is to download Firefox / Chrome.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Christina Goggi</title>
		<link>http://www.gfi.com/blog/57-simple-sys-admin-mistakes-that-someday-you-will-regret/comment-page-1/#comment-32206</link>
		<dc:creator>Christina Goggi</dc:creator>
		<pubDate>Wed, 18 Apr 2012 15:23:30 +0000</pubDate>
		<guid isPermaLink="false">http://www.gfi.com/blog/?p=8432#comment-32206</guid>
		<description><![CDATA[Hah! Good one!]]></description>
		<content:encoded><![CDATA[<p>Hah! Good one!</p>
]]></content:encoded>
	</item>
</channel>
</rss>

<!-- Performance optimized by W3 Total Cache. Learn more: http://www.w3-edge.com/wordpress-plugins/

 Served from: www.gfi.com @ 2013-09-14 22:10:07 by W3 Total Cache --