<?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/"
		xmlns:itunes="http://www.itunes.com/dtds/podcast-1.0.dtd"
	xmlns:media="http://search.yahoo.com/mrss/"
	>
<channel>
	<title>Comments on: Tell me your Security or IT horror story and win a pass to CSI</title>
	<atom:link href="http://www.mckeay.net/2008/10/31/tell-me-your-security-or-it-horror-story-and-win-a-pass-to-csi/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.mckeay.net/2008/10/31/tell-me-your-security-or-it-horror-story-and-win-a-pass-to-csi/</link>
	<description>The views of one man on security, privacy and anything else that catches his attention.  The views expressed on this blog do not reflect the views of my employer or anyone other than myself.</description>
	<lastBuildDate>Thu, 02 Feb 2012 21:45:54 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=</generator>
	<item>
		<title>By: Room362.com</title>
		<link>http://www.mckeay.net/2008/10/31/tell-me-your-security-or-it-horror-story-and-win-a-pass-to-csi/comment-page-1/#comment-3718</link>
		<dc:creator>Room362.com</dc:creator>
		<pubDate>Fri, 07 Nov 2008 03:38:15 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2008/10/31/tell-me-your-security-or-it-horror-story-and-win-a-pass-to-csi/#comment-3718</guid>
		<description>&lt;strong&gt;Free Pass to CSI 2008...&lt;/strong&gt;

What is CSI? This is what CSI says about it:

Security is in transition. There is general agreement that security does not work, but not on how to fix it. CSI 2008 is the only event today that faces the challenge to reconsider security. This year at ...</description>
		<content:encoded><![CDATA[<p><strong>Free Pass to CSI 2008&#8230;</strong></p>
<p>What is CSI? This is what CSI says about it:</p>
<p>Security is in transition. There is general agreement that security does not work, but not on how to fix it. CSI 2008 is the only event today that faces the challenge to reconsider security. This year at &#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Matt</title>
		<link>http://www.mckeay.net/2008/10/31/tell-me-your-security-or-it-horror-story-and-win-a-pass-to-csi/comment-page-1/#comment-3691</link>
		<dc:creator>Matt</dc:creator>
		<pubDate>Mon, 03 Nov 2008 09:31:33 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2008/10/31/tell-me-your-security-or-it-horror-story-and-win-a-pass-to-csi/#comment-3691</guid>
		<description>I work as a pen tester. So far in my 8 years of testing...

1) Taken down a large water utilities company by DoS&#039;ing 2/3 of their Oracle Solaris hosted servers just by Nmap&#039;ing them - lessons learned.. Ask the customer about potentially flaky servers. total cost to customer - £2million in call centre downtime and lost debit and credit payments.

2) Taken down a insurance company + their call centres during a VOIP test. Took out 5 international call centres by attempting to sniff SIP traffic off a spanning port and then re-injecting on a trunk port. - lessons learned - ask the customer if they really want their international  live VOIP network tested in hours. - £5 million plus in call centre downtimes.

3) Locked out a UK bank and their entire domain due to 3 tries and your locked out - lessons learned... review with the customer what their lockout policy is first and make sure they have back up accounts. - £ several million in wasted time trying to restore the server and user&#039;id&#039;s (domain accounts ran multiple databases - norty!!)

4) Ran Oscanner with the wrong config file, locked out a large council from their own database - lessons learned.. Don&#039;t run Oscanner without it being configured properly.

5) Transferred $5k by accident to my own credit card as part of a bank&#039;s web application test and then attempted to try and send the money back. Bank wouldn&#039;t accept it as they didn&#039;t believe it was possible, then the police got involved and i was charged with fraud but later dropped. Lessons learned - We now have a company credit card.

Oh man.. I could go on... 

 ; )</description>
		<content:encoded><![CDATA[<p>I work as a pen tester. So far in my 8 years of testing&#8230;</p>
<p>1) Taken down a large water utilities company by DoS&#8217;ing 2/3 of their Oracle Solaris hosted servers just by Nmap&#8217;ing them &#8211; lessons learned.. Ask the customer about potentially flaky servers. total cost to customer &#8211; £2million in call centre downtime and lost debit and credit payments.</p>
<p>2) Taken down a insurance company + their call centres during a VOIP test. Took out 5 international call centres by attempting to sniff SIP traffic off a spanning port and then re-injecting on a trunk port. &#8211; lessons learned &#8211; ask the customer if they really want their international  live VOIP network tested in hours. &#8211; £5 million plus in call centre downtimes.</p>
<p>3) Locked out a UK bank and their entire domain due to 3 tries and your locked out &#8211; lessons learned&#8230; review with the customer what their lockout policy is first and make sure they have back up accounts. &#8211; £ several million in wasted time trying to restore the server and user&#8217;id&#8217;s (domain accounts ran multiple databases &#8211; norty!!)</p>
<p>4) Ran Oscanner with the wrong config file, locked out a large council from their own database &#8211; lessons learned.. Don&#8217;t run Oscanner without it being configured properly.</p>
<p>5) Transferred $5k by accident to my own credit card as part of a bank&#8217;s web application test and then attempted to try and send the money back. Bank wouldn&#8217;t accept it as they didn&#8217;t believe it was possible, then the police got involved and i was charged with fraud but later dropped. Lessons learned &#8211; We now have a company credit card.</p>
<p>Oh man.. I could go on&#8230; </p>
<p> ; )</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: ax0n</title>
		<link>http://www.mckeay.net/2008/10/31/tell-me-your-security-or-it-horror-story-and-win-a-pass-to-csi/comment-page-1/#comment-3671</link>
		<dc:creator>ax0n</dc:creator>
		<pubDate>Sat, 01 Nov 2008 02:36:37 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2008/10/31/tell-me-your-security-or-it-horror-story-and-win-a-pass-to-csi/#comment-3671</guid>
		<description>Working as a part-time sysadmin at a community college, I was put in charge of pretty much all things security related for my group, mostly due to my background as a pen-tester for a consulting company.  One of those duties that fell into &quot;security&quot; was maintaining the backups. I can already see plenty of you putting your face in your palm.

The director had our microcomputer techs inventory everything, and when they were done scanning the bar-codes of every piece of technology in the labs, classrooms and offices, they went to... the data center... 

Most of the rack-mounted hardware had conspicuously-placed inventory labels. One piece of hardware, a Dell PowerVault 220S, did not. Eventually, the techs decided to see if the sticker was on the bottom, and withdrew it from the rack. This pulled one of the SCSI cable off and destroyed the backplane in the 220. Oh, yeah. The RAID freaked out, and about 800GB of student data (assignments, term papers, and porn) was lost.

CA ArcServe could not read the catalogs on the backup tapes I&#039;d been making. Attempts to re-build them failed. I wasn&#039;t too popular that day.

What I learned:
1) Never trust an entire team of desktop techs in your data center
2) Never trust that backup software is working until you test bare-metal restores from those archives regularly.
3) A huge failure like this is one way (but not the best) to get your boss to splurge for a test environment for patching, Disaster recovery exercises and the like.</description>
		<content:encoded><![CDATA[<p>Working as a part-time sysadmin at a community college, I was put in charge of pretty much all things security related for my group, mostly due to my background as a pen-tester for a consulting company.  One of those duties that fell into &#8220;security&#8221; was maintaining the backups. I can already see plenty of you putting your face in your palm.</p>
<p>The director had our microcomputer techs inventory everything, and when they were done scanning the bar-codes of every piece of technology in the labs, classrooms and offices, they went to&#8230; the data center&#8230; </p>
<p>Most of the rack-mounted hardware had conspicuously-placed inventory labels. One piece of hardware, a Dell PowerVault 220S, did not. Eventually, the techs decided to see if the sticker was on the bottom, and withdrew it from the rack. This pulled one of the SCSI cable off and destroyed the backplane in the 220. Oh, yeah. The RAID freaked out, and about 800GB of student data (assignments, term papers, and porn) was lost.</p>
<p>CA ArcServe could not read the catalogs on the backup tapes I&#8217;d been making. Attempts to re-build them failed. I wasn&#8217;t too popular that day.</p>
<p>What I learned:<br />
1) Never trust an entire team of desktop techs in your data center<br />
2) Never trust that backup software is working until you test bare-metal restores from those archives regularly.<br />
3) A huge failure like this is one way (but not the best) to get your boss to splurge for a test environment for patching, Disaster recovery exercises and the like.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: bob El Bob</title>
		<link>http://www.mckeay.net/2008/10/31/tell-me-your-security-or-it-horror-story-and-win-a-pass-to-csi/comment-page-1/#comment-3670</link>
		<dc:creator>bob El Bob</dc:creator>
		<pubDate>Fri, 31 Oct 2008 19:33:56 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2008/10/31/tell-me-your-security-or-it-horror-story-and-win-a-pass-to-csi/#comment-3670</guid>
		<description>Hi there,

Five years ago, i was new in the unix world like a 6 months old :)
I had a debian machine...
That machine was used to backup the data of about 30 users... about 500 gigs of data ...

I had a web site on that machine to monitor and call backup ... we were also able to restore them from the web interface ... A great piece of code...

The backups was running during the night... and it sends a report by mail...
I was on my computer that nite... and i decided to connect to the office and correct a little settings... One share was mispelled in the configuration... 
I then played around, checking the logs, checking file size, directory size etc...

Then, i noticed we had a www/ directory with some stupid contents we put for testing in the /usr or /usr/local ( i do not remember all the details )... It wasn,t our apache root directory anymore... and we didn,t even need that stuff anymore...

I decided to delete the content of www ... but to be sure i didn,t want to delete the directory www/ ... ( in case a service somewhere needs to refer to that directory )

so i run without even thinking:
rm -rf *
...
hrm... too much time before i get back my prompt ... like 2 or 3 seconds ... and it still not over... wtf ?

OHHHHH!!!! NO!!! ctrl-c ctrl-c damn damn!

I just noticed that i was in /usr and my stupid rm -rf * was deleting the whole /usr...

DOH!</description>
		<content:encoded><![CDATA[<p>Hi there,</p>
<p>Five years ago, i was new in the unix world like a 6 months old <img src='http://mckeay.net/wp-includes/images/smilies/icon_smile.gif' alt=':)' class='wp-smiley' /><br />
I had a debian machine&#8230;<br />
That machine was used to backup the data of about 30 users&#8230; about 500 gigs of data &#8230;</p>
<p>I had a web site on that machine to monitor and call backup &#8230; we were also able to restore them from the web interface &#8230; A great piece of code&#8230;</p>
<p>The backups was running during the night&#8230; and it sends a report by mail&#8230;<br />
I was on my computer that nite&#8230; and i decided to connect to the office and correct a little settings&#8230; One share was mispelled in the configuration&#8230;<br />
I then played around, checking the logs, checking file size, directory size etc&#8230;</p>
<p>Then, i noticed we had a www/ directory with some stupid contents we put for testing in the /usr or /usr/local ( i do not remember all the details )&#8230; It wasn,t our apache root directory anymore&#8230; and we didn,t even need that stuff anymore&#8230;</p>
<p>I decided to delete the content of www &#8230; but to be sure i didn,t want to delete the directory www/ &#8230; ( in case a service somewhere needs to refer to that directory )</p>
<p>so i run without even thinking:<br />
rm -rf *<br />
&#8230;<br />
hrm&#8230; too much time before i get back my prompt &#8230; like 2 or 3 seconds &#8230; and it still not over&#8230; wtf ?</p>
<p>OHHHHH!!!! NO!!! ctrl-c ctrl-c damn damn!</p>
<p>I just noticed that i was in /usr and my stupid rm -rf * was deleting the whole /usr&#8230;</p>
<p>DOH!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jason</title>
		<link>http://www.mckeay.net/2008/10/31/tell-me-your-security-or-it-horror-story-and-win-a-pass-to-csi/comment-page-1/#comment-3668</link>
		<dc:creator>Jason</dc:creator>
		<pubDate>Fri, 31 Oct 2008 19:02:09 +0000</pubDate>
		<guid isPermaLink="false">http://www.mckeay.net/2008/10/31/tell-me-your-security-or-it-horror-story-and-win-a-pass-to-csi/#comment-3668</guid>
		<description>I won&#039;t be able to make it to CSI one way or another, but I figured I&#039;d pass along my horror story.

This happened when I was first learning to admin UNIX boxes.  Another SysAdmin and I were working on a shell script to lowercase the file names of 30-40 million image files.  They were on an NFS mount that was used by several servers.  These images were part of detail listings of a relatively busy web site and we were right in the middle of the day.  

Now that the background of the mess are fully explained, the story gets going.  We went through several revisions and were testing against a directory on a desktop system.  Nothing destructive happened during testing and we were getting fairly comfortable with the &quot;safety&quot; of the script.  

We finally thought we had a working script, so we moved it to the prod server.  Then we noticed a &quot;minor&quot; change that needed to be made on it.  We made the change then decided that since this was a such a small, little tweak we could run it on the live NFS mount without any further testing.  Fire in the hole!

The script took off and we watched it run.  All was well.  Then my phone rang from the NOC.  A panicked operator was on the phone saying, &quot;Hey what&#039;s happening with listing images from xyz.com?  They are all coming up as 404s!&quot;  I killed the script while thinking some thing like &quot;oh crap, oh crap, oh crap!&quot;  Sure enough the script had wiped out about 50% of the images.  Amazing how fast a shell script can delete when it goes haywire.  

We pointed the web servers to a backup copy of the images, then started to recover to the production mount.  The backup was a couple days old, so our image processing guys had to re-upload the missing work.  I was lucky that the online backup was there.  I had taken it for reasons unrelated to this event.  The next day I got to explain to the CIO what had happened.

The moral of the story was backup first and test your script until it is golden before going live.  Then test it again and again and again.  Make sure you are doing at the proper time, then go to production.  We didn&#039;t have change control, so I&#039;d add get all the approvals now too.  Cover your butt.

It was a good lesson.  I&#039;ve never done anything like that again in the last 7 years.</description>
		<content:encoded><![CDATA[<p>I won&#8217;t be able to make it to CSI one way or another, but I figured I&#8217;d pass along my horror story.</p>
<p>This happened when I was first learning to admin UNIX boxes.  Another SysAdmin and I were working on a shell script to lowercase the file names of 30-40 million image files.  They were on an NFS mount that was used by several servers.  These images were part of detail listings of a relatively busy web site and we were right in the middle of the day.  </p>
<p>Now that the background of the mess are fully explained, the story gets going.  We went through several revisions and were testing against a directory on a desktop system.  Nothing destructive happened during testing and we were getting fairly comfortable with the &#8220;safety&#8221; of the script.  </p>
<p>We finally thought we had a working script, so we moved it to the prod server.  Then we noticed a &#8220;minor&#8221; change that needed to be made on it.  We made the change then decided that since this was a such a small, little tweak we could run it on the live NFS mount without any further testing.  Fire in the hole!</p>
<p>The script took off and we watched it run.  All was well.  Then my phone rang from the NOC.  A panicked operator was on the phone saying, &#8220;Hey what&#8217;s happening with listing images from xyz.com?  They are all coming up as 404s!&#8221;  I killed the script while thinking some thing like &#8220;oh crap, oh crap, oh crap!&#8221;  Sure enough the script had wiped out about 50% of the images.  Amazing how fast a shell script can delete when it goes haywire.  </p>
<p>We pointed the web servers to a backup copy of the images, then started to recover to the production mount.  The backup was a couple days old, so our image processing guys had to re-upload the missing work.  I was lucky that the online backup was there.  I had taken it for reasons unrelated to this event.  The next day I got to explain to the CIO what had happened.</p>
<p>The moral of the story was backup first and test your script until it is golden before going live.  Then test it again and again and again.  Make sure you are doing at the proper time, then go to production.  We didn&#8217;t have change control, so I&#8217;d add get all the approvals now too.  Cover your butt.</p>
<p>It was a good lesson.  I&#8217;ve never done anything like that again in the last 7 years.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

