Bogus emails: Amazon.com - Your Cancellation
There are bogus order cancellation emails going around claiming to be from Amazon like this:
Dear Customer,
Your order has been successfully canceled. For your reference, here's a summary of your order:
You just canceled order 15-6698-2492 placed on May 9, 2012.Status: CANCELED
_____________________________________________________________________
1 "Mulberry"; 2006, Special Edition
By: Sorcha Stewart
Sold by: Amazon.com LLC
_____________________________________________________________________
Thank you for visiting Amazon.com!
---------------------------------------------------------------------
Amazon.com
Earth's Biggest Selection
http://www.amazon.com
---------------------------------------------------------------------
The 15-6698-2492 in the copy I received linked to the URL http://repdesign.pt/requires.html which contains this is in the body:
<script type="text/javascript">window.location="http://leibypharmacylevitra.com";</script>
the web server seems to be down:
--2012-05-09 13:43:19-- (try: 7) http://leibypharmacylevitra.com/Connecting to leibypharmacylevitra.com|37.157.249.2|:80...
The day after patch Tuesday; sometimes called Wednesday
This is my first diary entry in several years. I am returning as a handler after a lengthy hiatus. I joined an organization which took too much time and did not permit this kind of interaction. It was worth it. That ride is coming to a close and I am happy to be able to return to this fine organization.
Today many of us are working through the monthly onslaught of patches and updates. Between the Microsoft May 2012 updates, PHP, ESX, and some Adobe updates there is quite a bit to think about. This is a monthly occurrence though. There are a number of steps organizations can take to prepare for this recurring event. A simple one is to mark the second Tuesday on a team calendar. Start to clear the deck on the Friday before and make sure that test systems on ready to go following the Tuesday release.
I have seen a number of approaches to patch preparation. At one extreme all critical systems are replicated in a lab, patches applied and a QA team validates key functions. At the other extreme, patches are just applied and then organization deals with the fall out. Not being an extremist I like to somewhere in the middle depending on organization size, mission, and capability.
There is also the triage effort for reviewing updates and determining how long to wait to get updates applied. I have seen one organization which waited 10 days after the MSFT release then applied all release patches counting on the forums and general buzz about the updates to call out any problems with them. This of course can leave the organization open to many other risks if an exploit is in the wild.
I advocate a more hands on approach especially with key systems. The organization just mentioned ran into a problem recently where two RADIUS (IAS) servers were taken offline by a patch which modified the CA cert. This brought the IAS servers down impacting wireless access for several hours while the problem was identified and investigated and resolved. Testing or patching one system at a time could have prevented or mitigated this outage.
What are some that work and some that don’t work? Care to share?
--
Dan
MADJiC.net
Comments