Archive for January, 2011

The geek test you want to pass

Tuesday, January 25th, 2011

For developers and IT professionals alike, Microsoft certifications can provide a leg up, whether one is job hunting or simply ascending the slippery slope up the corporate IT heirarchy.  The dilemma is that there are hundreds of them at any given time, and selecting the simplest Windows 7 cert eligible to attain the  MCP designation may not be the optimal choice for your career path.  So how do you choose?

Fortunately, Microsoft has provided a certification geek test that will appeal to even the most immature among us.  Reminiscent of a popular TV trivia game show (sans the Canadian host), it also brings back a much-maligned Microsoft mascot you may recognize from previous versions of Office.

But what actually makes this particular test valuable is the option of trying out different career paths to see which test you may be best suited for.  IT generalists rejoice!  The odd amalgum of actual certification test questions, questions demanding ridiculous speculation, and games of skill and/or random chance is disturbingly fun.  Give it a try and see which certification path you should consider.

Microsoft Security Vulnerability Summary and Patches – January 2011

Tuesday, January 25th, 2011

Vulnerability in Windows Backup Manager Could Allow Remote Code Execution (2478935)

Bulletin ID Bulletin Title and Executive Summary

Maximum Severity Rating and Vulnerability Impact

 

Restart Requirement Affected Software

MS11-002

Vulnerabilities in Microsoft Data Access Components Could Allow Remote Code Execution (2451910)

This security update resolves two privately reported vulnerabilities in Microsoft Data Access Components. The vulnerabilities could allow remote code execution if a user views a specially crafted Web page. An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.

 

Critical
Remote Code Execution

May require restart

Microsoft Windows

MS11-001

Vulnerability in Windows Backup Manager Could Allow Remote Code Execution (2478935)

This security update resolves a publicly disclosed vulnerability in Windows Backup Manager. The vulnerability could allow remote code execution if a user opens a legitimate Windows Backup Manager file that is located in the same network directory as a specially crafted library file. For an attack to be successful, a user must visit an untrusted remote file system location or WebDAV share and open the legitimate file from that location, which in turn could cause Windows Backup Manager to load the specially crafted library file.

Important
Remote Code Execution

May require restart

Microsoft Windows

Source:  microsoft.com

Enabling the real administrator account in Windows Vista and Windows 7

Friday, January 21st, 2011

There will occasionally be times when you want unfettered administrative access to your machine without the risk inherent to simply disabling UAC. This can be accomplished quite easily by enabling the real administrator account which is disabled by default in Windows Vista and Windows 7. It is important to remember, however, that this account should not be used as your default account since it being compromised would be tantamount to allowing bad guys complete control of your PC.

The process is identical for both Vista and Windows 7 users.  First, open a command prompt. Type “compmgmt.msc” and hit enter. When the Computer Management console opens, expand Local Users and Groups and select Users as shown right.

Before you get all excited, right-click on the administrator account, uncheck the disabled box and start to celebrate your newly acquired administrative powers, you should set a password. Right-click on the account and input your desired password, selecting one as secure/obscure as possible. The warning that appears (see right) is due to the fact that you’re changing the password of the admin account from within another account. You can proceed without any worries because you will be enabling the real administrator account for the first time.

Finally, right click on the account again and select Properties. Now you can uncheck the “Account is disabled” box and activate your real administrator account. Hit OK, log out of the current account and log into your new administrator account with the password you just set. To disable the account, simply recheck the box to disable the account.

For those who prefer the simplicity of the command line UI, the same operation can be performed with the following command:

net user administrator /active:yes

The operation can be undone with this command:

net user administrator /active:no


Windows Server 2008 compatibility check

Tuesday, January 11th, 2011

Nothing is more frustrating than spending money on hardware or software, only to find it’s incompatible with your current OS.  When the OS in question is resident on a business server, the incompatibility moves beyond frustrating and becomes seriously problematic.

Microsoft has lessened the risk considerably by providing a fairly comprehensive listing of hardware, software, peripherals and server virtualization solutions that are designed for, known to work with, known not to work with, etc., Windows Server 2003, Server 2008, and Server 2008 R2 in the Windows Server Catalog.

Don’t let incompatible hardware/software derail your project, cause you to lose an important client, or otherwise result in lost time and money.  In the event you have questions regarding something not covered in the link above, Gyver Networks is always available to provide expert advice regarding compatibility and any other issues you might encounter.

Kill rogue processes with taskkill in Microsoft Windows

Tuesday, January 11th, 2011

There are times, regardless of your operating system, when you will need to manually kill a rogue process. Most of the time, this can easily be done with the help of the Microsoft Windows 7 Task Manager. There are times, however, when that tool doesn’t seem to have the ability to kill a rogue process. I have seen this plenty of times when trying to kill an Acronis process that has gone astray. When this happens, I have to employ a more powerful tool, taskkill, which is used from the command line.

Note: In order to run the taskkill command, you will have to open the command window. To do this, click Start | Run and type cmd in the text field or just enter cmd in the Run dialog box (access Run dialog box by clicking Win+R) (Figure A).

Figure A

Open the command window.

Using taskkill

The general syntax of the command looks like this:

taskkill [OPTIONS] [PID]

As you might expect, there are plenty of options available for this command. Some of the more helpful options are:

  • /s COMPUTER — (Where COMPUTER is the IP or address of a remote computer). The default is the local computer, so if you’re working with a command on the local machine, you do not have to use this option.
  • /u DOMAIN\USER — (Where DOMAIN is the domain and USER is the username you authenticate to). This option allows you run taskkill with the account permissions of the specified USERNAME or DOMAIN\USERNAME.
  • /p — If you use the /u option, you will also need to include the /p option, which allows you to specify the user password.
  • /fi — Allows you to run the taskkill command with filters.
  • /f — Forces the command to be terminated.
  • /IM — Allows you to use an application name instead of the PID (Process ID number) of the application.

One of the most useful options is the help switch (Figure B):

taskkill /?

Figure B

Use the help switch for the taskkill command.

Killing with application name

The simplest way to kill a rogue application with taskkill is using the /IM option. This is done like so:

taskkill /IM APPLICATION_NAME

Where APPLICATION_NAME is the name of the application you want to kill. Say, for example, Outlook is refusing to close. To close this with taskkill, you would execute the command:

taskkill /IM outlook.exe

Killing with PID

Let’s say you do not know the name of the application, but instead you know the PID of the application. To kill a process with a PID of, say, 572, you would issue the command:

taskkill /PID 572

Killing all processes owned by a particular user

What if you want to kill all processes owned by a single user? This can come in handy if something has gone awry with a user account or if the user has logged out, but some of the processes owned by that user will not go away. To manage this you would issue the taskkill command like so:

taskkill /F /FI “USERNAME eq username”

In this case, the username is the actual username that owns the processes. Note: The USERNAME option must be used in order to tell the taskkill command a username will be specified.

Killing processes on a remote machine

This one is very handy. Say something has locked up your desktop and you know exactly what application is the culprit. Let’s stick with our Outlook example from earlier. You can hop onto another machine and remotely kill that application like so:

taskkill /s IP_ADDRESS /u DOMAIN\USERNAME /IM Outlook.exe

Where IP_ADDRESS is the address of the remote machine (Note: The hostname can be substituted if the machines are able to see one another by hostname), DOMAIN is the domain (if applicable), and USERNAME is the username used to authenticate to the remote machine.

Final thoughts

The ability and power that comes with the taskkill command can be a very valuable tool that might save you from having to forcibly reboot a machine. Having a solid grasp of this tool, in conjunction with using the Windows Task Manager, will help to keep your Windows machines enjoying longer uptime and, should the occasion strike, the ability to manage a task when a virus, rootkit, or trojan has taken over your machine.

 

Source:  techrepublic.com

Linux and FreeBSD hardware info

Tuesday, January 11th, 2011

Switching between open source OSs can sometimes be confusing, since they may have different ways of doing things. A common task that may confuse some users when switching systems is getting hardware information. In the case of Linux-based OSs and FreeBSD, the following cheat sheet for figuring out how to do the same things on two different systems can ease some of the pain.

CPU and memory information

Because Linux-based systems use the proc device filesystem to provide access to information about hardware devices in the system, getting specific information about the hardware sometimes involves finding it in files using the grep command. The same information is normally accessed on FreeBSD via the sysctl command.

To get information about your CPU model . . .

  • Linux:
    grep model /proc/cpuinfo
    
  • FreeBSD:
    sysctl hw.model
    

To get information about total system memory . . .

  • Linux:
    grep MemTotal /proc/meminfo
    
  • FreeBSD:
    sysctl hw.realmem
    

Device listings

Information about many other devices might be needed as well. For these, each system has tools designed to provide listings of devices connected to various system buses.

To get information about PCI devices . . .

  • Linux:
    lspci -v
    
  • FreeBSD:
    pciconf -lv
    

To get information about USB devices . . .

  • Linux:
    lsusb -v
    
  • FreeBSD:
    usbconfig
    

To get other connected device information . . .

  • Linux:
    dmidecode
    

    This command shows DMI/SMBIOS hardware information.

    lshal
    

    This command shows all devices managed by the HAL subsystem.

  • FreeBSD:
    atacontrol list
    

    This command shows all ATA devices.

    camcontrol devlist -v
    

Notes

Some of the above commands may work from a normal, unprivileged user account. Others may be restricted to root access.

On both of these OS types, a lot more information can be had by means similar to those described above. For instance, the /proc/cpuinfo and /proc/meminfo files contain a lot more information than just the CPU model and total memory. There is a sysctl command on Linux-based systems as well as on FreeBSD and other BSD Unix systems, but it is not as broadly useful as on FreeBSD, nor does it offer as comprehensive coverage of the system, because Linux-based systems default to other means of accessing and configuring system configuration values (such as the proc filesystem). On either system type, a picture of sysctl capabilities can be seen by viewing the utility’s manpage.

If you are feeling curious and have some time to spend exploring, sysctl -a outputs all information sysctl has to provide.

 

Source:  techrepublic.com