Wednesday, December 21, 2011

How MX Records Work

What is an MX record?
An MX record tells senders how to send email for your domain.
When your domain is registered, it’s assigned several DNS records, which enable it to be located on the Internet. These include MX records, which direct the domain’s mail flow. Each MX record points to an email server that’s configured to process mail for that domain. There’s typically one record that points to a primary server, then additional records that point to one or more backup servers. For users to send and receive email, their domain's MX records must point to a server that can process their mail.
To filter email through the message security service, you must insert new records that point to the message security service's servers.
 
Where are my MX records?
Your authoritative MX records are on your DNS provider's server. When you change the MX record on your DNS provider, other servers will make copies of these updated MX records over time.
 
How can I see my MX records?
 To check your current MX records, follow these steps:
 
How do I update my MX records?
 
Why should I update MX records?
For the message security service to work, we need you to route your mail to us. When you update your MX records, we accept your mail, filter out the bad mail, and pass the good mail on to your server.
 
When should I update my MX records?
During activation, you'll receive a message telling you it's time to update your MX records.
If you're adding more domains later on, update your MX records after you've added the domain in the Administration Console. Until your domain is set up in the Administration Console, mail will bounce if you update your MX records.
 
What's the format of an MX record?
An MX record includes the following fields:
Name: The name of your domain.
Class: This is always set to IN, which stands for Internet.
Type: For MX records, this is always set to MX.
TTL: "Time to Live." How long it will take to update the record. This is measured in seconds. A TTL of 3600 seconds means records will take an hour to update. A TTL of 86400 means records will take a day to update. A higher TTL value means less traffic load for the DNS server, but it also means that changing the MX records will take longer.
Preference or Priority: The order of preference for mail delivery. Sending servers should try the lowest preference number first, then the next lowest, and so on.
Data: The host name of the mail server that handles mail for that domain.
For instance, if your domain is jumboinc.com, your MX records might look like this:
jumboinc.com. IN MX 86400 1 jumboinc.com.s7a1.psmtp.com.
jumboinc.com. IN MX 86400 2 jumboinc.com.s7a2.psmtp.com.
jumboinc.com. IN MX 86400 3 jumboinc.com.s7b1.psmtp.com.
jumboinc.com. IN MX 86400 4 jumboinc.com.s7b2.psmtp.com.
Every DNS host has a different user interface for MX records. Some use a trailing period and some don't. Some allow you to set your TTL and some won't. Our instructions include information for most common MX hosts, but yours may be different. If you're not sure what to enter, use the same format as your existing MX records. Be sure that the message security service MX records have the first priority; the exact numbers don't matter as long as the message security service MX records are the first. If your DNS server allows fewer than 4 records, enter as many as you can.
For detailed instructions on how to update your MX records, see Change Your MX Records.
 
Why do I need four separate MX records?
We use redundant MX records as a backup in case any problem occurs. They give our network more flexibility if any changes to architecture are necessary.
 
Should I update A records when routing mail to the message security service?
Do not update your A records. Since your MX records point to psmtp.com, you do not need to change any A records.
 
Can I keep MX records pointed directly to my mail server as a backup?
Yes. If you want to keep a direct MX record for your mail server as a backup, you can, but be sure to leave it at the lowest priority, after all four psmtp.com records. Leaving your own mail server in the MX records should be a temporary backup measure, because spammers sometimes try to bypass the service and connect directly to your mail server using your backup MX records. Once your mail is flowing through the message security service successfully, consider changing your MX records to remove this backup.
 
How long do MX record updates take?
MX record updates are not immediate. After you've updated your MX records, it will take a while for every sender to use the new MX records. Your original TTL setting determines how long (in seconds) this will take. Changing the TTL setting won't speed this up.
 
Will I lose mail after changing MX records?
No. As long as you enter the MX records correctly, you won't lose any MX records. While your MX records are changing over, some mail will be delivered using your old MX information, and some mail will be delivered using your new MX information, but all of it will be delivered.
 
What happens if I type the wrong information into the MX record?
If you type the incorrect delivery information in the MX record, some mail will bounce. The sender will receive a notice that the mail wasn't delivered. If this happens, correct the MX records as soon as possible. Some mail may still bounce for a period of time (up to the length of the new TTL setting), but the sooner you update the MX records to the correct setting, the fewer messages will bounce.
 
What happens when I update my MX records?
Once you update your MX records, mail will start flowing through the message security service. After your old previous TTL (in seconds) has expired, all your mail flows through the message security service. When your mail flows through the service, mail is bounced from IP addresses known to be a major source of spam attacks or viruses. Also, if you have Non-Account Virus Blocking, mail to users will be filtered for viruses as well. You'll get complete mail filtering after you've added your users.
 
How can I tell if the MX update worked?
Send a test message from an outside address, then view the full headers. The full headers are about 20-50 lines of text. If the headers include the word "psmtp.com" then the mail flowed through the message security service.
at No comments:

Thursday, December 15, 2011

Record Monitor Screen in VLC

This tool will record each mouse-click and save it as an image, then compile everything into HTML (more specifically, a Microsoft MHT file). However this is not a video capture tool. As far as I know, there isn't one built-in to Windows.
You may look into downloading the free VLC player. With VLC, you can use your desktop as a capture device:
  1. Click Media
  2. Click Open Capture Device
  3. Choose Capture Mode: Desktop (at this point, you may want to set a higher FPS)
..and then stream it to a file:
  1. Click icon to the left of play
  2. Stream
  3. Hit next, then click Add next to the dropdown (make sure File is selected)
  4. Choose a filename and click Stream
Hope this helps.
at No comments:

Thursday, December 01, 2011

What Is Windows Server Update Services (WSUS)?

WSUS Overview

Windows Software Update Services (WSUS), is Microsoft's upcoming free patch management tool. WSUS is essentially the next version of Microsoft's free patch management tool, replacing Software Update Services or SUS. WSUS provides a number of new features including targeting of patches to specific groups of machines, support for more produts (e.g Office), and improved reporting.
In beta for over a year, RC of WSUS released on 22 March 2005. WSUS RTM is expected to be released during the first half of 2005 (e.g. by end June 2005).  Service Pack1 for WSUS, which provides support for Windows Vista, new versions of the database and performance increases was released at the beginning of June 2006. More details on this release are available here. For more information on the background to WSUS and Microsoft's approach to patch management see WSUS Background.
WSUS is a service you run inside your organisation - on one or more servers which you configure to serve software updates to one or more AU clients. You can configure a WSUS server to download updates either from Microsoft or from another WSUS server within your organisation. Once you approve an update for installation, WSUS downloads it from configured upstream partner, and can then issue these updates to clients that request it. You can approve any update for some, all, or none of your computers. Once an update is approved, the targeted WSUS clients download the update using the Windows AU client. WSUS also provides reports on which clients have, and have not, had which updates.
WSUS provides a capability that allows the Windows AU client to obtain and install updates. However, it does not provide an internal version of the Windows Update site, thus your users can not navigate to your WSUS server and obtain updates (as they can when they navigate to Microsoft's Windows Update site).
You administer WSUS from the WSUS administration console: http://<WSUSServerName>:<port number>/WsusAdmin/. On your WSUS server you can also click Start, point to All Programs, point to Administrative Tools, and then click Microsoft Windows Server Update Services. Note that if you do not add your WSUS administration Web site name to the list of sites in the Local Intranet zone in Internet Explorer, you might be prompted for credentials each time you open the WSUS administration console.
WSUS also supports the option to Allow local administrator to use the Automatic Updates control panel applet to select a configuration option of their choice. Note that Local Administrators are not allowed to disable Automatic Updates. The setting Allow local administrator to choose setting only appears if Automatic Updates has updated itself to the version compatible with WSUS.
Q: Where does this option appear?

 
WSUS Updates
As noted above, WSUS enables you to download updates from Microsoft and distribute these to your clients. There is no support in WSUS for adding additional updates, e.g. for updates to 3rd party or your own applications, etc.
For WSUS, Microsoft intent to provice several different levels of updates (from crticial security patches to updated drivers). Support is provided for some, but not all, Microsoft products. For details on what products and levels of update are supported see WSUS Supported Updates
WSUS Database
The WSUS service makes use use of an SQL database, which is either supported by SQL Server or by MSDE/WMSDE (see WSUS Database for more details on the WSUS Database). Each WSUS server requries a separate database, thus if you plan to suppor multiple WSUS servers in your environment, you need to support multiple WSUS databases. If you are installing WSUS on Windows Server 2003 operating system or later, you can install WMSDE included in WSUS Setup. If you are installing WSUS on Windows 2000 Server operating system, install the MSDE database software prior to installing WSUS. The WSUS database stores the following types of information:
  • WSUS server configuration information
  • Metadata that describes each update
  • Detailed Information about clients, updates, and client interaction with updates
The metadata for an update describes the update, lists the files required to install the update, and contains the relevant end user license agreement (EULA) for that update. Metadata is small, typically much smaller than the update itself, and is downloaded when you synchronise a WSUS server. An update, however, is only downloaded when it has been approved for installation.
Client Targeting

A key feature in WSUS is the ability to target updates to specific computers. WSUS enables you to create one or more target groups, to populate the target group with appropriate computers, and then approve updates for each target group independently. There are two default target groups All Computers and Unassigned Computers but you can add as many target groups as needed to support your approach to client targeting.
Update Approval
WSUS offers a number of features associated with approving updates, including setting deadlines for updates to be completed and uninstalling updates. A WSUS server first downloads download metadata, which allows the administrator to choose which updates to approve either for detection or installation. Updates can also be declined. The actual update is only downloaded to the WSUS server when you approve the update for installation.
Once you have approved update to members of one more Target group, computers belonging to the groups check in with the WSUS server and either check or deploy the approved updates. You can subsequently use WSUS reporting to determine the status of those updates.
For more informaiton on Update Approval, see Approve Updates.
Bandwidth Conservation
Updates distributed via WSUS can be very large (Windows XP SP2 for example is over 200 MB). WSUS attempts to be as bandwidth friendly as possible. First WSUS downloads update metadata. This is done independently of the update itself, which is downloaded only after it has been approved for installation.
And WSUS also provides supports servers that are not directly connected to the Internet. In this scenario, you first download updates to an Upstream server, then hand-carry media to disconnected servers running WSUS, and using the export/import feature to import the updates into your disconnected WSUS server.
For more information on how WSUS conserves bandwidth, see Bandwidth Considerations.
Firewall Considerations
If there is a firewall between the network you are running WSUS on and the Internet, you need to allow both HTTP and HTTPS traffic (port 80 for the HTTP protocol and port 443 for HTTPS) from your WSUS server to a limited set of sites, as follows:
Q: Where does this list come from? Is there a web link to this list that can be placed here to provide more authority?
A: see page 13 of Step-by-step guide to getting started with Microsoft Windows Update Services document from http://go.microsoft.com/fwlink?LinkId=39496

IIS Considerations
By default, WSUS installs into the default Web site in IIS (i.e on port 80). WSUS Setup gives you the option of creating a Web site on a custom port, the default being 8530. This allows you to run all WSUS traffic on a separate port, which may be helpful for internal firewalls.

During installation, WSUS stops, then starts the relevant web site. This includes the default default Web site if that was used. If you already have a Web site on the computer where you intend to install WSUS, use the setup option for creating a custom Web site. Note that if you install WSUS to port 8530, you have to manually set up the folder structure like, selfupdate virtual directory on port 80 to enable client self update using InstallSelfupdateOnPort80.vbs from installation folder.

Finally, ensure that the IWAM_ account is added to the Domain Administrators account on the WSUS Server. The IWAM account contains the ASPNET account used to start the WSUS service.
Mobile Clients
You can deploy an "internet facting" WSUS server outside your corporate firewall in order to distribute updates to mobile clients which are licensed to the same party as the WSUS server.  See Implementing WSUS with ISA Server 2004 to manage remote clients white paper on Microsoft's WSUS TechNet site.

You can, of course, enable the clients to create a VPN into the corporate network, and once connected use your WSUS server to receive update approvals that are then downloaded either from your WSUS server for from Micrososft's servers.
Migration From SUS to WSUSIf you have already deployed SUS in your network, WSUS has a migration tool, Working with WSUSUTIL, that you can use to migrate approvals and updates from SUS to your WSUS server. This avoids re-downloading the patch content.

You cannot migrate any of the WSUS Service settings or IIS settings. Additionally, migration is a one-way process - you cannot migrate from WSUS to SUS. If you plan to install the WSUS server on a server already running SUS, then the WSUS installation process sets up WSUS to use an alternate port.>
at No comments:

what is patch management in windows?

Patch management is an area of systems management that involves acquiring, testing, and installing multiple patches (code changes) to an administered computer system. Patch management tasks include: maintaining current knowledge of available patches, deciding what patches are appropriate for particular systems, ensuring that patches are installed properly, testing systems after installation, and documenting all associated procedures, such as specific configurations required. A number of products are available to automate patch management tasks, including RingMaster's Automated Patch Management, PatchLink Update, and Gibraltar's Everguard.
Like its real world counterpart, a patch is a "make-do" fix rather than an elegant solution. Patches are sometimes ineffective, and can sometimes cause more problems than they fix. Patch management experts, such as Mark Allen, CTO of Gibraltar Software, suggest that system administrators take simple steps to avoid problems, such as performing backups and testing patches on non-critical systems prior to installations.

Summary: This How To explains patch management, including how to keep single or multiple servers up to date. Additional software is not required, except for the tools available for download from Microsoft.
Operations and security policy should adopt a patch management process. This How To defines the processes required to create a sound patch management system. The patch management process can be automated using the guidance in this How To.

Contents

This How To shows you how to implement each phase of the patch management process. These phases include:
What You Must Know Before You Begin Detecting Assessing Acquiring Testing Deploying Maintaining Additional Resources

What You Must Know

Before using this How To, you should be aware of the following issues and considerations.

The Patch Management Process

Patch management is a circular process and must be ongoing. The unfortunate reality about software vulnerabilities is that, after you apply a patch today, a new vulnerability must be addressed tomorrow.
Develop and automate a patch management process that includes each of the following:
  • Detect. Use tools to scan your systems for missing security patches. The detection should be automated and will trigger the patch management process.
  • Assess. If necessary updates are not installed, determine the severity of the issue(s) addressed by the patch and the mitigating factors that may influence your decision. By balancing the severity of the issue and mitigating factors, you can determine if the vulnerabilities are a threat to your current environment.
  • Acquire. If the vulnerability is not addressed by the security measures already in place, download the patch for testing.
  • Test. Install the patch on a test system to verify the ramifications of the update against your production configuration.
  • Deploy. Deploy the patch to production computers. Make sure your applications are not affected. Employ your rollback or backup restore plan if needed.
  • Maintain. Subscribe to notifications that alert you to vulnerabilities as they are reported. Begin the patch management process again.

The Role of MBSA in Patch Management

The Microsoft Baseline Security Analyzer (MBSA) is a tool that is designed for two purposes: first, to scan a computer against vulnerable configurations; and second, to detect the availability of security updates that are released by Microsoft.
In this How To, you use MBSA without scanning for vulnerable configurations. When using the graphical user interface (GUI), specify this by unchecking the options in Figure 1 and only choosing Check for security updates.
Ff647981.fz2thcm01(en-us,PandP.10).gif
Figure 1
MBSA scan options
When using the command line interface (Mbsacli.exe), you can use the following command to scan only missing security updates.
Mbsacli.exe /n OS+IIS+SQL+PASSWORD
The option /n specifies the checks to skip. The selection (OS+IIS+SQL+PASSWORD) skips the checks for vulnerabilities and weak passwords.
For more details about using MBSA, including the security configuration scan, see "How To: Use MBSA" in the How To section of this guide.

Backups and Patch Management

You should perform backups prior to deploying an update on production servers. Regularly test backups as well as your backup process. Discovering that your backup process is broken during restoration can be devastating.

Before You Begin

This section provides information about downloads and documentation that are needed before you walk through the steps in this How To.

Tools You Will Need

You need the following tools in order to be able to perform the steps in this How To:
  • Microsoft Baseline Security Analyzer (MBSA) Download MBSA from the MBSA Home Page: http://www.microsoft.com/technet/security/tools/Tools/mbsahome.asp
  • Latest Mssecure.cab By default, MBSA downloads the latest update list (Mssecure.cab) from Microsoft.com. If you do not have Internet access from the computer running MBSA, you must download the file and copy it to the MBSA installation directory. You can download the update file from: http://technet.microsoft.com/en-us/security/cc184923.aspx
  • Microsoft Software Update Service (SUS) Microsoft Software Update Services (SUS) Server 1.0 Service Pack 1 (SP1) enables administrators to deploy critical updates to Windows 2000-based, Windows XP, and Windows Server 2003 computers. You can download it from: [Content link no longer available, original URL:"http://www.microsoft.com/downloads/details.aspx?FamilyId=A7AA96E4-6E41-4F54-972C-AE66A4E4BF6C&displaylang=en"]

Detecting

Use MBSA to detect missing security patches for Windows 2000, Windows XP, and Windows Server 2003. You can use MBSA in two modes; GUI and command line. Both modes are used to scan single or multiple computers. The command line can be scripted to run on a schedule.
Note   The login used to run MBSA must be a member of the Administrators group on the target computer(s). To verify adequate access and privilege, use the command net use \\computername\c$ where computername is the network name of a machine which you are going to scan for missing patches. Resolve any issues accessing the administrative share before using MBSA to scan the remote computer.
To manually detect missing updates using the MBSA graphical interface
  1. Run MBSA by double-clicking the desktop icon or by selecting it from the Programs menu.
  2. Click Scan a computer. MBSA defaults to the local computer. To scan multiple computers, select Scan more than one computer and select either a range of computers to scan or an IP address range.
  3. Clear all check boxes except Check for security updates. This option detects uninstalled patches and updates.
  4. Click Start scan. Your server is now analyzed. When the scan is complete, MBSA displays a security report and also writes the report to the %userprofile%\SecurityScans directory.
  5. Download and install the missing updates. Click the Result details link next to each failed check to view the list of uninstalled security updates. A dialog box displays the Microsoft security bulletin reference number. Click the reference to find out more about the bulletin and to download the update.
To detect missing updates using the MBSA command line interface
  • From a command window, change directory to the MBSA installation directory, and type the following command: 
    mbsacli /i 127.0.0.1 /n OS+IIS+SQL+PASSWORD
    You can also specify a computer name. For example: 
    mbsacli /c domain\machinename /n OS+IIS+SQL+PASSWORD
    You can also specify a range of computers by using the /r option. For example: 
    mbsacli /r 192.168.0.1-192.168.0.254 /n OS+IIS+SQL+PASSWORD
    Finally, you can scan a domain by using the /d option. For example: 
    mbsacli /d NameOfMyDomain /n OS+IIS+SQL+PASSWORD
To analyze the generated report
  1. Run MBSA by double-clicking the desktop icon or by selecting it from the Programs menu.
  2. Click Pick a security report to view and open the report or reports, if you scanned multiple computers.
  3. To view the results of a scan against the target machine, mouse over the computer name listed. Individual reports are sorted by the timestamp of the report.
As previously described, the advantage of the command line method is that it may be scripted and scheduled to execute. This schedule is determined by the exposure of your systems to hostile networks, and by your security policy.

MBSA Output Explained

The following example was taken using the MBSA version 1.1.
Ff647981.fz2thcm02(en-us,PandP.10).gif
Figure 2
Screenshot of the report details for a scanned machine
The top portion of the MBSA screenshot shown in Figure 2 is self explanatory.
Red crosses indicate that a critical issue has been found. To view the list of missing patches, click the associated Result details link.
The results of a security update scan might show two types of issues:
  • Missing patches
  • Patch cannot be confirmed
Both types include links to the relevant Hotfix and security bulletin pages that provide details about the patch together with download instructions.
Missing patches are indicated by a red cross. An example is shown in Figure 3.
Ff647981.fz2thcm03(en-us,PandP.10).gif
Figure 3
Missing patch indication
When a patch cannot be confirmed, it is indicated by a blue asterisk. This occurs when your system has a file that is newer than the file provided with a security bulletin. This might occur if you install a new version of a product that updates a common file.
Ff647981.fz2thcm04(en-us,PandP.10).gif
Figure 4
Patch cannot be confirmed indication
For updates that cannot be confirmed, review the information in the bulletin and follow the instructions. This may include installing a patch or making configuration changes. For more information on patches that cannot be verified by MBSA, see Microsoft Knowledge Base article, 306460, "HFNetChk Returns Note Messages for Installed Patches."

Assessing

With the list of missing patches identified by MBSA, you must determine if the vulnerabilities pose a significant risk. Microsoft Security Bulletins provide technical details to help you determine the level of threat the vulnerability poses to your systems.
The details from security bulletins that help you assess the risk of attack are:
  • Technical details of requirements an attacker needs to exploit the vulnerability addressed by the bulletin. For example, an attack may require physical access or the user must open a malicious email attachment.
  • Mitigating factors that you need to compare against your security policy to determine your level of exposure to the vulnerability. It may be that your security policy mitigates the need to apply a patch. For example, if you do not have the Indexing Service running on your server, you do not need to install patches to address vulnerabilities in the service.
  • Severity rating that assists in determining priority. The severity rating is based on multiple factors including the role of the machines that may be vulnerable, and the level of exposure to the vulnerability. For more information about the severity rating system used by the security bulletins, see the TechNet article, "Microsoft Security Response Center Security Bulletin Severity Rating System" at http://www.microsoft.com/technet/security/bulletin/rating.mspx
    Note   If you use an affected product, you should almost always apply patches that address vulnerabilities rated critical or important. Patches rated critical should be applied as soon as possible.

Acquiring

There are several ways you can obtain patches, including:
  • Using MBSA report details. MBSA links to the security bulletin that contains the patch, or instructions about obtaining the patch. You can use the link to download the patch and save it on your local network. You can then apply the patch to multiple computers.
  • Windows Update. With a list of the updates you want to install, use Internet Explorer on the server that requires the patch, and access http://windowsupdate.microsoft.com/. Then select the required updates for installation. The updates are installed from the site and cannot be downloaded for installation on another computer. Windows Update requires that an ActiveX control is installed on the server (you will be prompted when you visit the site if the control is not found.) This method works well for standalone workstations or where a small number of servers are involved.
  • HotFix & Security Bulletin Search. MBSA includes the Microsoft Knowledge Base article ID of the corresponding article for a given security bulletin. You can use the article ID at the HotFix and Security Bulletin Search site to reach the matching security bulletin. The search page is located at http://www.microsoft.com/technet/security/current.aspx. The bulletin contains the details to acquire the patch.

Testing

If the results of your assessment determine that a patch must be installed, you should test that patch against your system to ensure that no breaking changes are introduced or, if a breaking change is expected, how to work around the change.

Methods for Testing Security Patches

Methods used to test the installation of security patches against your systems include:
  • Testing security patches against a test mirror of your live server configuration and scenario. This method allows you to both test the installation offline, without disrupting service, and the freedom to test workarounds if a breaking change is introduced, again without disrupting service.
  • Testing the patch on a few select production systems prior to fully deploying the update. If a test network that matches your live configuration is not available, this is the safest method to introduce the security patch. If this method is employed, you must perform a backup prior to installing the update.

Confirming the Installation of a Patch

Before deploying a patch to production servers, confirm that the tested patch has made the appropriate changes on the test servers. Each security bulletin includes the information you need to confirm that the patch has been installed. In each bulletin, the Additional information about this patch section contains the entry Verifying patch installation. It includes registry values, file versions, or similar configuration changes that you can use to verify that the patch is installed.

Uninstalling a Security Patch

If you need to uninstall a patch, use Add/Remove Programs in the Control Panel. If an uninstall routine is not an option for the patch and its installation introduces breaking changes, you must restore your system from backup. Make sure that your testing process also covers the patch uninstall routine.
The security bulletin lists the availability of an uninstall routine in the Additonal information about this patch section.

Deploying

If you decide that the patch is safe to install, you must deploy the update to your production servers in a reliable and efficient way. You have a number of options for deploying patches throughout the enterprise. These include:
  • Using Windows Server Update Services (WSUS)
  • Using Systems Management Server (SMS)

Using Windows Server Update Services (WSUS)

WSUS provides a way to automatically deploy crucial updates and security rollups to computers throughout a network, without requiring you to visit each computer or write script. For more information about WSUS, see "Windows Server Update Services Product Information" at http://technet.microsoft.com/en-us/wsus/bb466202.aspx.

Using Systems Management Server (SMS)

SMS is an enterprise management tool for delivering configuration and change management of Microsoft Windows server and workstation operating systems. For more information about using SMS to deploy updates, see TechNet article, "Patch Management Using Microsoft Systems Management Server" at http://technet.microsoft.com/en-us/solutionaccelerators/default.aspx.

Maintaining

Bringing your servers up to date with the latest patches is part of the patch management cycle. The patch management cycle begins again by knowing when new security vulnerabilities are found and missing security updates become available.
Keeping your servers up to date with the latest security patches involves this entire cycle. You start the cycle again by:
  • Performing security assessments
  • Using security notification services

Performing Security Assessments

Use MBSA to regularly check for security vulnerabilities and to identify missing patches and updates. Schedule MBSA to run daily and analyze the results to take action as needed. For more information about automating MBSA, see "How To: Use MBSA" in the How To section of this guide.

Using Security Notification Services

Register to receive notifications of security bulletins released by Microsoft. Use the following services:

Additional Considerations

When bringing a new service online on an existing server, run MBSA to verify the patches for the service have been applied prior to having the server and service listening on the network. For example, disconnect the network cable or apply network based rules that block the newly added service's ports.
at No comments:

Know Your UNIX System Administrator: A Field Guide

There are four major species of Unix sysad:
The TECHNICAL THUG.
Usually a systems programmer who has been forced into system administration; writes scripts in a polyglot of the Bourne shell, sed, C, awk, perl, and APL.
The ADMINISTRATIVE FASCIST.
Usually a retentive drone (or rarely, a harridan ex-secretary) who has been forced into system administration.
The MANIAC.
Usually an aging cracker who discovered that neither the Mossad nor Cuba are willing to pay a living wage for computer espionage. Fell into system administration; occasionally approaches major competitors with indesp schemes.
The IDIOT.
Usually a cretin, morpohodite, or old COBOL programmer selected to be the system administrator by a committee of cretins, morphodites, and old COBOL programmers.

HOW TO IDENTIFY YOUR SYSTEM ADMINISTRATOR:

SITUATION: Low disk space.
TECHNICAL THUG:
Writes a suite of scripts to monitor disk usage, maintain a database of historic disk usage, predict future disk usage via least squares regression analysis, identify users who are more than a standard deviation over the mean, and send mail to the offending parties. Places script in cron. Disk usage does not change, since disk-hogs, by nature, either ignore script-generated mail, or file it away in triplicate.
ADMINISTRATIVE FASCIST:
Puts disk usage policy in motd. Uses disk quotas. Allows no exceptions, thus crippling development work. Locks accounts that go over quota.
MANIAC: 
# cd /home
# rm -rf `du -s * | sort -rn | head -1 | awk '{print $2}'`;
IDIOT: 
# cd /home
# cat `du -s * | sort -rn | head -1 | awk '{ printf "%s/*\n", $2}'` |  
compress
SITUATION: Excessive CPU usage
TECHNICAL THUG:
Writes a suite of scripts to monitor processes, maintain a database of CPU usage, identify processes more than a standard deviation over the norm, and renice offending processes. Places script in cron. Ends up renicing the production database into oblivion, bringing operations to a grinding halt, much to the delight of the xtrek freaks.
ADMINISTRATIVE FASCIST:
Puts CPU usage policy in motd. Uses CPU quotas. Locks accounts that go over quota. Allows no exceptions, thus crippling development work, much to the delight of the xtrek freaks.
MANIAC:
# kill -9 `ps -augxww | sort -rn +8 -9 | head -1 | awk '{print $2}'`
IDIOT:
# compress -f `ps -augxww | sort -rn +8 -9 | head -1 | awk '{print $2}'`
SITUATION: New account creation
TECHNICAL THUG:
Writes perl script that creates home directory, copies in incomprehensible default environment, and places entries in /etc/passwd, /etc/shadow, and /etc/group. (By hand, NOT with passmgmt.) Slaps on setuid bit; tells a nearby secretary to handle new accounts. Usually, said secretary is still dithering over the difference between 'enter' and 'return'; and so, no new accounts are ever created.
ADMINISTRATIVE FASCIST:
Puts new account policy in motd. Since people without accounts cannot read the motd, nobody ever fulfills the bureaucratic requirements; and so, no new accounts are ever created.
MANIAC:
"If you're too stupid to break in and create your own account, I don't want you on the system. We've got too many goddamn sh*t-for-brains a**holes on this box anyway."
IDIOT: 
# cd /home; mkdir "Bob's home directory"
# echo "Bob Simon:gandalf:0:0::/dev/tty:compress -f" > /etc/passwd
SITUATION: Root disk fails
TECHNICAL THUG:
Repairs drive. Usually is able to repair filesystem from boot monitor. Failing that, front-panel toggles microkernel in and starts script on neighboring machine to load binary boot code into broken machine, reformat and reinstall OS. Lets it run over the weekend while he goes mountain climbing.
ADMINISTRATIVE FASCIST:
Begins investigation to determine who broke the drive. Refuses to fix system until culprit is identified and charged for the equipment.
MANIAC, LARGE SYSTEM:
Rips drive from system, uses sledgehammer to smash same to flinders. Calls manufacturer, threatens pets. Abuses field engineer while they put in a new drive and reinstall the OS.
MANIAC, SMALL SYSTEM:
Rips drive from system, uses ball-peen hammer to smash same to flinders. Calls Requisitions, threatens pets. Abuses bystanders while putting in new drive and reinstalling OS.
IDIOT:
Doesn't notice anything wrong.
SITUATION: Poor network response.
TECHNICAL THUG:
Writes scripts to monitor network, then rewires entire machine room, improving response time by 2%. Shrugs shoulders, says, "I've done all I can do," and goes mountain climbing.
ADMINISTRATIVE FASCIST:
Puts network usage policy in motd. Calls up Berkeley and AT&T, badgers whoever answers for network quotas. Tries to get xtrek freaks fired.
MANIAC:
Every two hours, pulls ethernet cable from wall and waits for connections to time out.
IDIOT:
# compress -f /dev/en0
SITUATION: User questions
TECHNICAL THUG:
Hacks the code of emacs' doctor-mode to answer new users questions. Doesn't bother to tell people how to start the new "guru-mode", or for that matter, emacs.
ADMINISTRATIVE FASCIST:
Puts user support policy in motd. Maintains queue of questions. Answers them when he gets a chance, often within two weeks of receipt of the proper form.
MANIAC:
Screams at users until they go away. Sometimes barters knowledge for powerful drink and/or sycophantic adulation.
IDIOT:
Answers all questions to best of his knowledge until the user realizes few UNIX systems support punched cards or JCL.
SITUATION: *Stupid* user questions
TECHNICAL THUG:
Answers question in hex, binary, postfix, and/or French until user gives up and goes away.
ADMINISTRATIVE FASCIST:
Locks user's account until user can present documentation demonstrating their qualification to use the machine.
MANIAC: 
# cat >> luser/.cshrc
alias vi 'rm \!*;unalias vi;grep -v BoZo ~/.cshrc > ~/.z; mv -f ~/.z 
^D
IDIOT:
Answers all questions to best of his knowledge. Recruits user to system administration team.
SITUATION: Process accounting management
TECHNICAL THUG:
Ignores packaged accounting software; trusts scripts to sniff out any problems & compute charges.
ADMINISTRATIVE FASCIST:
Devotes 75% of disk space to accounting records owned by root and chmod'ed 000.
MANIAC:
Laughs fool head off at very mention of accounting.
IDIOT:
# lpr /etc/wtmp /usr/adm/paact
SITUATION: Religious war, BSD vs. System V
TECHNICAL THUG: BSD. Crippled on System V boxes.
ADMINISTRATIVE FASCIST:
System V. Horrified by the people who use BSD. Places frequent calls to DEA.
MANIAC:
Prefers BSD, but doesn't care as long as HIS processes run quickly.
IDIOT:
# cd c:
SITUATION: Religious war, System V vs. AIX
TECHNICAL THUG:
Weeps.
ADMINISTRATIVE FASCIST:
AIX-- doesn't much care for the OS, but loves the jackboots.
MANIAC:
System V, but keeps AIX skills up, knowing full well how much Big Financial Institutions love IBM...
IDIOT:
AIX.
SITUATION: Balky printer daemons.
TECHNICAL THUG:
Rewrites lpd in FORTH.
ADMINISTRATIVE FASCIST:
Puts printer use policy in motd. Calls customer support every time the printer freezes. Tries to get user who submitted the most recent job fired.
MANIAC:
Writes script that kills all the daemons, clears all the print queues, and maybe restarts the daemons. Runs it once a hour from cron.
IDIOT:
# kill -9 /dev/lp ; /dev/lp &
SITUATION: OS upgrade.
TECHNICAL THUG:
Reads source code of new release, takes only what he likes.
ADMINISTRATIVE FASCIST:
Instigates lawsuit against the vendor for having shipped a product with bugs in it in the first place.
MANIAC:
# uptime 1:33pm up 19 days, 22:49, 167 users, load average: 6.49, 6.45, 6.31 # wall Well, it's upgrade time. Should take a few hours. And good luck on that 5:00 deadline, guys! We're all pulling for you! ^D
IDIOT:
# dd if=/dev/rmt8 of=/vmunix
SITUATION: Balky mail.
TECHNICAL THUG:
Rewrites sendmail.cf from scratch. Rewrites sendmail in SNOBOL. Hacks kernel to implement file locking. Hacks kernel to implement "better" semaphores. Rewrites sendmail in assembly. Hacks kernel to . . .
ADMINISTRATIVE FASCIST:
Puts mail use policy in motd. Locks accounts that go over mail use quota. Keeps quota low enough that people go back to interoffice mail, thus solving problem.
MANIAC: 
# kill -9 `ps -augxww | grep sendmail | awk '{print $2}'`
# rm -f /usr/spool/mail/*
# wall
Mail is down.  Please use interoffice mail until we have it back up.
^D
# write max
I've got my boots and backpack.  Ready to leave for Mount Tam?
^D
IDIOT: 
# echo "HELP!" | mail  
tech_support.AT.vendor.com%kremvax%bitnet!BIFF!!!
SITUATION: Users want phone list application.
TECHNICAL THUG:
Writes RDBMS in perl and Smalltalk. Users give up and go back to post-it notes.
ADMINISTRATIVE FASCIST:
Oracle. Users give up and go back to post-it notes.
MANIAC:
Tells the users to use flat files and grep, the way God meant man to keep track of phone numbers. Users give up and go back to post-it notes.
IDIOT:
% dd ibs=80 if=/dev/rdisk001s7 | grep "Fred"

OTHER GUIDELINES:

TYPICAL ROOT .cshrc FILE:
TECHNICAL THUG:
Longer than eight kilobytes. Sources the output of a perl script, rewrites itself.
ADMINISTRATIVE FASCIST:
Typical lines include:
umask 777
alias cd 'cd \!*; rm -rf ching *hack mille omega rogue xtrek >& /dev/null &'
MANIAC:
Typical lines include:
alias rm 'rm -rf \!*'
alias hose kill -9 '`ps -augxww | grep \!* | awk \'{print $2}\'`'
alias kill 'kill -9 \!* ; kill -9 \!* ; kill -9 \!*'
alias renice 'echo Renice\?  You must mean kill -9.; kill -9 \!*'
IDIOT:
Typical lines include:
alias dir ls
alias era rm
alias kitty cat
alias process_table ps
setenv DISPLAY vt100

HOBBIES, TECHNICAL:

TECHNICAL THUG:
Writes entries for Obsfuscated C contest. Optimizes INTERCAL scripts. Maintains ENIAC emulator. Virtual reality .
ADMINISTRATIVE FASCIST:
Bugs office. Audits card-key logs. Modifies old TVs to listen in on cellular phone conversations. Listens to police band.
MANIAC:
Volunteers at Survival Research Labs. Bugs office. Edits card-key logs. Modifies old TVs to listen in on cellular phone conversations. Jams police band.
IDIOT:
Ties shoes. Maintains COBOL decimal to roman numeral converter. Rereads flowcharts from his salad days at Rand.

HOBBIES, NONTECHNICAL:

TECHNICAL THUG:
Drinks "Smart Drinks." Attends raves. Hangs out at poetry readings and Whole Earth Review events and tries to pick up Birkenstock MOTAS.
ADMINISTRATIVE FASCIST:
Reads _Readers Digest_ and _Mein Kampf_. Sometimes turns up car radio and sings along to John Denver. Golfs. Drinks gin martinis. Hangs out in yuppie bars and tries to pick up dominatrixes.
MANIAC:
Reads _Utne Reader_ and _Mein Kampf_. Faithfully attends Dickies and Ramones concerts. Punches out people who say "virtual reality." Drinks damn near anything, but favors Wild Turkey, Black Bush, and grain alcohol. Hangs out in neighborhood bars and tries to pick up MOTAS by drinking longshoremen under the table .
IDIOT:
Reads _Time_ and _Newsweek_-- and *believes* them. Drinks Jagermeister. Tries to pick up close blood relations-- often succeeds, producting next generation of idiots.

1992 PRESIDENTIAL ELECTION:

TECHNICAL THUG:
Clinton, but only because he liked Gore's book.
ADMINISTRATIVE FASCIST:
Bush. Possibly Clinton, but only because he liked Tipper.
MANIAC:
Frank Zappa.
IDIOT:
Perot.

1996 PRESIDENTIAL ELECTION:

TECHNICAL THUG:
Richard Stallman - Larry Wall.
ADMINISTRATIVE FASCIST:
Nixon - Buchanan.
MANIAC:
Frank Zappa.
IDIOT:
Quayle.

COMPOUND SYSTEM ADMINISTRATORS:

TECHNICAL FASCIST:
Hacks kernel & writes a horde of scripts to prevent folk from ever using more than their fair share of system resources. Resulting overhead and load brings system to its knees.
TECHNICAL MANIAC:
Writes scripts that SEEM to be monitoring the system, but are actually encrypting large lists of passwords. Uses nearby nodes as beta test sites for worms.
TECHNICAL IDIOT:
Writes superuser-run scripts that sooner or later do an "rm -rf /".
FASCISTIC MANIAC:
At first hint of cracker incursions, whether real or imagined, shuts down system by triggering water-on-the-brain detectors and Halon system.
FASCISTIC IDIOT:
# cp /dev/null /etc/passwd
MANIACAL IDIOT:
Napalms the CPU.
at No comments:

Friday, November 11, 2011

Gmail Certificate error

Certificate errors are typically caused by an incorrect date or time in your operating system's calendar.
To set your Date and Time Properties in Windows, please follow these steps:
  1. Double-click the time in your taskbar to open the Date & Time Properties menu.
  2. From the Date & Time tab, verify that the appropriate month, day, and year are selected.
  3. Click Apply to save any changes you make.
  4. From the Time Zone tab, verify that your time zone is selected. If the time zone in which you are located is not displayed, select your time zone from the drop-down menu.
  5. Verify that the box beside Automatically adjust clock for daylight savings changes is checked.
  6. Click OK.
  7. Close all your browser1 windows, restart your browser and try logging in again.
at No comments:

Tuesday, November 01, 2011

Error when attempting to disable Out of Office Assistant.

 

Summary

Occasionally, when someone is attempting to disable their Out of Office Assistant in Microsoft Outlook, they will receive the error...
"This command is not available. See the program documentation about how to use this extension."
Contents

Issue

For one reason or another, the extension was disabled the last time they shut down outlook.

Solution

1) Go to the Help menu
2) Drop down to About Microsoft Outlook.
3) Click on Disabled Items in the bottom right.
4) Select the "outex.dll (outex.dll)" file out of the listing and click Enable.
5) Close and re-open outlook.

A user of Outlook 2003 reported that when she wanted to turn off an out-of-office message she had previously set, she received the message below.

Microsoft Office Outlook
The command is not available. See the program documentation about how to use this extension.
[ OK ]

When I sent test messages to her I didn't see any out-of-office replies.
Microsoft has a Knowledge Base article on the problem "You receive an error message when you try to start the Out of Office Assistant in Outlook 2003". That article recommends ensuring that no Outlook process is running and then checking the HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\Outlook registry key for a Resiliency subkey and, if it exists renaming it to Resiliency.old. A similar Knowledge Base article, Article ID 327353 recommends the same procedure if the problem occurs under Outlook 2002, though the registry key references 10.0 rather than 11.0 as the Outlook version. I don't know why Microsoft recommends renaming the Resiliency key rather than deleting it. There is no statement about restoring the orginal name afterwards. Perhaps Microsoft is suggesting renaming it in case deleting it doesn't resolve the problem or creates some other problem. There doesn't seem to be any reason for retaining the renamed subkey if renaming it removes the problem and Outlook works fine afterwards.
I did see a Resiliency subkey in the registry on the user's system. But in trying to understand the function of that subkey, I found another solution based on comments at Outlook / Disabled Items / Resiliency. The solution I employed was based on the information provided at that webpage. Since the solution doesn't involve editing the registry it is a procedure that can be employed by a user without risk of inadvertent damage to the registry.
To resolve the problem, you can take the following steps:
  1. Open Outlook.
  2. Click on Tools.
  3. Click on About Microsoft Outlook.
  4. Click on the Disabled Items entry.
  5. You will see a Disabled Items window open, with the following information within it:

    The items below were disabled because they prevented Outlook from functioning correctly.

    Please note that you may have to restart Outlook for these changes to take place.

    Select the ones you wish to re-enable.

    If you see "Addin: outex.dll (outex.dll)" listed, click on it to highlight it and then click on the Enable button. Then click on the Close button. Then click on the OK button to close the About Microsoft Office Outlook window.

You should then be able to click on Tools and then Out of Office Assistant to modify the out of office setting.
When I employed the procedure and then checked the registry afterwords, there was no longer a Resiliency subkey. The outex.dll DLL, which is apparently used by the Out of Office Assistant, was the only disabled item. The key that had been in the registry is listed below:

The source of the problem is suggested on Josh Einstein's Web Log as being due to Outlook permanently disabling an addin:
If the AddIn experiences a problem during initialization, Outlook will prompt the user that the AddIn caused a problem and would you like to disable it. The user will of course always choose “yes” and this is where the problem starts.

Outlook creates a new item in HKCU\Software\Microsoft\Office\11.0\Outlook\Resiliency\DisabledItems that contains some cryptic hashed value of your AddIn. If your AddIn is listed here, forget about it! Outlook will not load it again. You can remove and reinstall the application as much as you like but that key never gets overwritten so the AddIn never gets loaded. 

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\outlook\Resiliency]

[HKEY_CURRENT_USER\Software\Microsoft\Office\11.0\outlook\Resiliency\DisabledItems]
"437C9368"=hex:01,00,00,00,14,00,00,00,14,00,00,00,6f,00,75,00,74,00,65,00,78,\
  00,2e,00,64,00,6c,00,6c,00,00,00,6f,00,75,00,74,00,65,00,78,00,2e,00,64,00,\
  6c,00,6c,00,00,00
at 1 comment:
Subscribe to: Posts (Atom)

Explaining DNS Concepts - DNS Servers-DNS Queries-DNS Records

3 types of DNS queries— recursive, iterative, and non-recursive 3 types of DNS servers— DNS Resolver, DNS Root Server and Authoritative Name...