Wednesday, April 20, 2011

XenServer "repair filesystem" prompt rescue

to get around a "repair filesystem" prompt at XenServer boot, I had to remount / as writable and edit /etc/fstab to change a mount parameter.

(Repair filesystem) 1 mount -n -o remount /
(Repair filesystem) 2 vi /etc/fstab
found the last entry I made for the USB drive and changed the fsck field (#6) from '2' to '0' to skip fsck on boot.
wrote, rebooted, and XenServer skipped the failing mount and booted.

I used an external USB drive as an ISO repository on a new XenServer 5.6 FP1 installation for a test environment. I wanted the mount to persist, so added it to /etc/fstab with an fsck pass number of 2, so it would be checked at startup. I didn't realize it, but apparently USB devices aren't discovered at boot, so fsck failed and init wanted me to do something to fix it.

I'm sure the correct solution is to add a script to mount the volume at a later init stage, but for now, at least XS boots and I can manually mount the volume and repair the ISO repository.

Tuesday, July 27, 2010

Exchange 2007 / 2010 mail encryption

TLS encryption is the default for Exchange 2007 / 2010. No configuration is required, not even a commercial certificate, because standard TLS encrypts, but doesn't authenticate.

(Exchange 2007 / 2010 install a self-generated SSL certificate at installation that is suitable for encryption. Exchange 2003 and earlier require manual configuration.)

The only requirement for TLS:
a) if Exchange is sending the message, the recipient mail server must respond to the EHLO greeting with a list that includes the verb STARTTLS;
b) if Exchange is receiving the message, the sender must issue the STARTTLS request to negotiate a TLS session

To determine whether the recipient mail server supports TLS:
find the mail server for the target domain
telnet to it and issue an EHLO, then examine the return list for STARTTLS

Scenario: we want to determine whether email exchanged with hud.gov will be encrypted.

a. find the mail server(s) for hud.gov
nslookup
set type=mx
hud.gov
quit

session transcript looks like:
>nslookup
Default Server: ns1.ncgi.com
Address: 192.168.1.375

> set type=mx
> hud.gov
Server: ns1.ncgi.com
Address: 192.168.1.375

Non-authoritative answer:
hud.gov MX preference = 0, mail exchanger = hlanuep001.hud.gov
hud.gov MX preference = 0, mail exchanger = hlanuep002.hud.gov
hud.gov MX preference = 0, mail exchanger = horluep003.hud.gov

hud.gov nameserver = hudgate.hud.gov
hud.gov nameserver = hudgater.hud.gov
hlanuep001.hud.gov internet address = 170.97.200.33
hlanuep002.hud.gov internet address = 170.97.200.34
horluep003.hud.gov internet address = 170.97.202.58
hudgate.hud.gov internet address = 170.97.67.16
hudgater.hud.gov internet address = 170.97.167.16
> exit


b. from the mail server console, telnet and issue EHLO
session transcript:
>telnet hlanuep001.hud.gov 25

220 HLANUEP001.hud.gov ESMTP
EHLO ncgi.com
250-HLANUEP001.hud.gov
250-8BITMIME
250 SIZE 15728640
quit
221 HLANUEP001.hud.gov


Connection to host lost.

so we see that hud.gov doesn’t support encryption (no STARTTLS in the response to EHLO)

Microsoft Corporation, however, does support encryption (returns STARTTLS in the EHLO response)
session transcript
>telnet mail.messaging.microsoft.com 25

220 TX2EHSMHS014.bigfish.com Microsoft ESMTP MAIL Service ready at Wed, 28 Jul 2010 03:10:23 +0000
EHLO ncgi.com
250-TX2EHSMHS014.bigfish.com Hello [1.1.1.1]
250-SIZE 157286400
250-PIPELINING
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-AUTH
250-8BITMIME
250-BINARYMIME
250 CHUNKING
quit
221 2.0.0 Service closing transmission channel


Connection to host lost.


Why always do this from the mail server console? because workstation or other machines may be using public IPs that aren't approved. this is the response trying to telnet to the Air Force Academy's mail server from a PC on a Qwest DSL connection:

>telnet usafamail.usafa.af.mil 25

220 xqpz-fwl-001.usafa.af.mil ESMTP Wed, 28 Jul 2010 02:55:10 GMT


Connection to host lost.

indicating that the mail server dropped the connection because it originated from an address known to be in a problematic block. (The blacklist check at mxtoolbox.com is great for troubleshooting delivery failures due to blacklisting http://mxtoolbox.com/blacklists.aspx )

Sunday, March 14, 2010

Why new hard disks might not be much fun for XP users

Why new hard disks might not be much fun for XP users
XP and Server 2003 will run slower with new-new hard disks that use 4K blocks because of partition alignment boundaries in the OS (unless you were fortunate enough to have taken a class years ago where the instructor advised creating partitions manually before installing the OS and using the parameter "align=64")

Friday, March 12, 2010

Too many arguments in command line.

Too many arguments in command line.

The magic is in the help, more /?, which contains the (oddly) helpful line "Switches can be present in the MORE environment variable."

Apparently Windows' default is to add the '/e' switch to more.com somewhere in the registry. I don't know what I did, but suddenly the command
more mytextfile.txt
produced the complaint "Too many arguments in command line."

I restored the behavior to which I was accustomed by adding the environment variable MORE with the parameters
/e

I also tossed in /c and /s for good measure:
/c - clear screen before displaying page
/s - squeeze multiple blank lines into a single line

Tuesday, November 10, 2009

FortiAnalyzer and traffic monitoring with an HP ProCurve

A client has been seeing unusual traffic volumes on the Internet side of their Fortinet firewall, FortiGate FG-80C.

We connected a FortiAnalyzer to perform traffic analysis.

Scenario:
FA port 1 is the management port, connected to the HP ProCurve in VLAN 1.
FA port 2 is the traffic collection port, connected to the same ProCurve on port 26.
ProCurve ports 21 and 22 are configured as VLAN 2.
The inside port of the router is connected to port 21.
The WAN1 port of the FG is connected to port 22.

configure the ProCurve:
conf t
no ip routing
mirror-port 26
vlan 2
name "external"
untagged 21-22
ip address
exit
int 21
monitor
exit
int 22
monitor
exit
write mem


Then enable Network Analyzer on the FortiAnalyzer and set Port2 as the mirror port:
config log settings
set analyzer enable
set analyzer-gui enable
set analyzer-quota 10240
set analyzer-interface "port2"
end

(Logoff the GUI and logon to see Network Analyzer under the 'Tools' menu.)

Configure the Fortigate to log to the FortiAnalyzer
config log fortianalyzer setting
set status enable
set server 192.168.1.99
end


Start the monitor from the FortiAnalyzer
Tools -> Network Analyzer -> Real-Time -> Start

The easy part is done. Now *you* have to figure out what to make out of the logs ;o)




Fix .pdf file association

Windows Explorer has its own file associations, independent of HKCR.

A client needed to replace Foxit Reader with Acrobat Reader on their Citrix servers because some third party software required the Adobe rendering engine. After removing Foxit and installing Acrobat Reader, users couldn't open any .pdf documents from Explorer or Outlook.

First thought was the file type association. FTYPE and ASSOC showed the correct associations,but I reset them anyway:

ftype AcroExch.Document="C:\Program Files\Adobe\Reader 9.0\Reader\AcroRd32.exe" "%1"
assoc .pdf=AcroExch.Document

to no avail.

Then I lucked out and realized that on one of the servers, I'd failed to remove Foxit, had installed Acrobat Reader alongside. Users on that server were still able to open .pdf files and they were getting Foxit.

A quick registry search for "Foxit" returned several values, including one under the "Progid" value beneath HKCU\Software\Microsoft\Windows\Currentversion\Explorer\FileExts\.pdf

I don't know why Explorer needs a different file association, but deleting it solved the problem and after logoff and logon, users were blissfully (and silently) opening .pdfs with Acrobat Reader.

To delete the key for each user, I added this line to %SystemRoot%\system32\usrlogn1.cmd (it may wrap in this post, but it's all one line):

reg delete "HKCU\Software\Microsoft\Windows\Currentversion\Explorer\FileExts\.pdf" /f

The line could also be added to a domain logon script.

(I initially changed the file type in the registry to point to Acrobat Reader, but then decided to try deleting it altogether. I prefer the deletion, since it appears to force Explorer to lookup the HKCR association. If you need the Explorer FileExt entry, this works:

reg add "HKCU\Software\Microsoft\Windows\Currentversion\Explorer\FileExts\.pdf" /v Progid /t REG_SZ /d AcroExch.Document /f
)

Monday, March 30, 2009

Conficker scanner - using Bonn University's scs in a Windows environment

This post is based on information in ZD Net's article this morning
http://blogs.zdnet.com/security/?p=3043&tag=nl.e589

I followed these steps successfully on two machines, a Windows XP SP3 workstation and Windows 2003 SP2 server, and scanned three subnets in a few minutes.

Overview of steps:
  • download and install ActiveState Win32 Python
  • download python Crypto module
  • download and install python Impacket module
  • download, extract and run scs.py

create a working directory for downloads and builds. I used
c:\Download\ConfickerTools

ActiveState python
- download the .msi into the working directory
http://downloads.activestate.com/ActivePython/windows/2.6/ActivePython-2.6.1.1-win32-x86.msi
- install the .msi
- accept the defaults (it will install in C:\Python26)

python Crypto module
- make sure Python is installed first
- download into the working directory
http://www.voidspace.org.uk/downloads/pycrypto-2.0.1.win32-py2.6.exe
- run the executable. it should find the Python26 installation and install there

python Impacket module
- download into the working directory
http://oss.coresecurity.com/repo/Impacket-0.9.6.0.zip
- extract the .zip file, preserving the directory structure
- open a command prompt
- change into the extracted directory,
e.g., cd C:\Download\ConfickerTools\Impacket-0.9.6.0
- at the prompt enter
python setup.py install
python will build the module and install it into its library directory

simple conficker scanner (scs)
download from Bonn university, Germany, into the working directory
http://iv.cs.uni-bonn.de/uploads/media/scs.zip
extract
run the tool using the start and end addresses on your LAN, and redirect the output to a text file
e.g.
scs.py 192.168.1.1 192.168.1.254 > scs-out_192-168-1-0.txt

examine the output file for any infected machines