Tip of the Day: Logbooks
Over the years I found the use of a logbook, either on paper or electronically an essential instrument in managing (security of) devices. They can be useful for more than just managing security but they shine during emergencies. Since most emergencies with devices involve loss of either Confidentiality, Integrity, or Availability, the use of these logbooks is highly related to security.
In some organizations the system or network administrators are the ones who are in the best position to keep them up to date and working properly, sometimes making it hard to coordinate with a different set of security people.
What should be in such a logbook ?
Hardware and configuration
The easiest is to print out the information from the OS. E.g.:
If activation keys are used they should be copied here as well or at least clearly indicated how they can be obtained in an emergency.
Raid procedures
As needed.
How do you store this information ? I've used various document formats, but if I were today to start with this again I'd seriously consider an internal wiki.
Things to look out for:
For additional inspiration refer to Security Consensus Operational Readiness Evaluation, there are check lists and incident forms available there.
--
Swa Frantzen -- Section 66
In some organizations the system or network administrators are the ones who are in the best position to keep them up to date and working properly, sometimes making it hard to coordinate with a different set of security people.
What should be in such a logbook ?
Hardware and configuration
Identification
You need to be able to identify a device should it get lost, stolen or otherwise compromised. I've found it useful for administrators who are less familiar with certain devices to still locate the right device and be able to power toggle a completely unresponsive system back to life. This information can be of great value and is easy to obtain during physical installation and initial staging.- Hostname
- Location
- Brand
- Model
- Options: CPUs, memory, disks ...
- Serial numbers
- Host ID
- ...
Network(s)
Information on the network connections.- Interface
- Connects to: device, port
- Speed/Duplex
- MAC address
- IP addresses (use CIDR, network and broadcasts written out, remember you'll use it in an emergency!)
- FQDN (DNS name)
Filtering
Filtering used by this device such as packet filters, their configuration, how to turn them on and off and how to get a closed emergency filter installed.Disk(s)
Detailed information on disks, partitions and slices. Make sure to add what they are used for and the information needed to select the right replacement drive.The easiest is to print out the information from the OS. E.g.:
$ sudo fdisk wd0
Disk: wd0 geometry: 24321/255/63 [390716865 Sectors]
Offset: 0 Signature: 0xAA55
Starting Ending LBA Info:
#: id C H S - C H S [ start: size ]
------------------------------------------------------------------------
0: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
1: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
2: 00 0 0 0 - 0 0 0 [ 0: 0 ] unused
*3: A6 0 1 1 - 24320 254 63 [ 63: 390716802 ] OpenBSD
$ sudo disklabel wd0a
# /dev/rwd0a:
type: ESDI
disk: ESDI/IDE disk
label: WDC WD2000JD-00G
flags:
bytes/sector: 512
sectors/track: 63
tracks/cylinder: 16
sectors/cylinder: 1008
cylinders: 16383
total sectors: 390721968
rpm: 3600
interleave: 1
trackskew: 0
cylinderskew: 0
headswitch: 0 # microseconds
track-to-track seek: 0 # microseconds
drivedata: 0
16 partitions:
# size offset fstype [fsize bsize cpg]
a: 4194225 63 4.2BSD 2048 16384 328 # (Cyl. 0*- 4160)
b: 1048320 4194288 swap # (Cyl. 4161 - 5200)
c: 390721968 0 unused 0 0 # (Cyl. 0 - 387620)
d: 4194288 5242608 4.2BSD 2048 16384 328 # (Cyl. 5201 - 9361)
e: 4194288 9436896 4.2BSD 2048 16384 328 # (Cyl. 9362 - 13522)
f: 377085681 13631184 4.2BSD 2048 16384 328 # (Cyl. 13523 - 387615*)
$ mount
/dev/wd0a on / type ffs (local)
/dev/wd0e on /home type ffs (local, nodev, nosuid)
/dev/wd0d on /var type ffs (local, nodev, nosuid)
/dev/wd0f on /var/www type ffs (local, nodev, nosuid)
...
RAID
Make sure you have all the information to deal with raid devices you might have. As most often this is proprietary in format, giving guidance is hard. But make sure you have all information needed to replace drives, use hotspares, rebuild partity and reconfigure them in the same way as they were should the configuration information get lost.Software
Operating System
This information changes with reinstallation but stays as a while fairly static- Brand
- Version
- Revision (if any)
- Installation time choices indicating installed components.
- ...
OS patches
This information changes a lot in modern OSes. An informational paragraph on how the patches are applied now and how they are done normally should suffice. Having a log of what was installed when is important.Applications
This section is what you installed as applications on the machine. It should include the important choices made during installation so that people coming after the installer could redo the installation in the same manner. This section must be expanded as time goes by and more applications are installed or removed.If activation keys are used they should be copied here as well or at least clearly indicated how they can be obtained in an emergency.
Service contracts
Information on all hardware and software or other service contracts related to this machine. It should include the needed procedures, contract numbers , FAX and phone numbers, and any reference the other party will demand before they will start their service execution.Dependencies
A tricky part in larger organization to get right and it might make use of automation if you have many. Basically you want to show:Services offered
Services the device offers. It should list what needs to be in place, how to test that the services are working, and a list of machines and/or other services depending on them. A prediction of what happens when the services are lost can be very valuable information when dealing with incidents and their needed communication.Services used
Devices typically need a bunch of services of other machines. Having such a list with simple test to see if those services perform their intended task can be a great timesaver.Incidents
Any incident this machine was involved in, should be documented in detail. Even simple hardware failures should be documented as they can lead to discover a trend that could indicate a problematic device and trigger a need for replacement.- operator
- date&time
- what was observed
- what was done
Procedures
Procedures can be either detailed procedures or pointers to specifics. Remember you'll need them under stressy conditions, so make them easy to find and execute. Make sure they list when and by whom they were last actually tested.Emergency access
How does an authorized person not having or remembering the passwords access the system in an emergency (e.g a sealed envelope in a safe).Check Backup status
How do you see what backups have been made, what they contain etc.Normal backup out of sequence
How do you make a backup use normal means for backing up ?Emergency backup
How do you make a backup in an emergency ?Restore of data
How do you restore a single file or directory ?Restore of full system
How do you restore a full system ?Raid procedures
As needed....
Add other emergency procedures that are usuful for the specific devices such as how to deny all traffic for a firewall. Also in the text above the procedures there are some links that say to document procedures, those coul dbe added here or pointed to at least.How do you store this information ? I've used various document formats, but if I were today to start with this again I'd seriously consider an internal wiki.
Things to look out for:
- Make sure it is easy to access and update by all your administrators.
- Make sure you have a copy ready in your Disaster Recovery site, you'll put it to good use inthe process of a recovery should you ever need to start it.
- Make sure it is easy enough to add additional information the administrator thinks might be good to know. So allow for a flexible format to store it in. Allowing for some flexinbility allows you to use this kind of logbook for devices you might not consider to be "computers" such as network elements, or even devices such as accurate clocks, environmental controls etc. (even if they aren't networked).
- You can link this in with change management. In fact you should ...
- While updatign remember that you are documenting it for a slightly less experienced administrator than yourself who knows the hardware/software a little bit but does not know the specifics of this machine.
- It's meant to be used during emergencies, keep it simple to read and understand.
For additional inspiration refer to Security Consensus Operational Readiness Evaluation, there are check lists and incident forms available there.
--
Swa Frantzen -- Section 66
Keywords: ToD
0 comment(s)
winsnort defaced - use caution
Website defacements are unfortunately common and mostly we'd rather not report about it as it only gives the bad guys exactly what they seek: fame and attention for them or their cause.
Having said that, the defacement of winsnort.com is a bit special to the security community as it is a site that's used for a security product. We advise extreme caution with the site and any of it's content till the extend of the hack becomes known.
--
Swa Frantzen -- Section 66
Having said that, the defacement of winsnort.com is a bit special to the security community as it is a site that's used for a security product. We advise extreme caution with the site and any of it's content till the extend of the hack becomes known.
--
Swa Frantzen -- Section 66
Keywords:
0 comment(s)
Unpatched exploit gets publicity
An exploit that got missed by the patches in MS06-035 is receiving public attention on mailing lists. The exploit itself has been public since July, and got reported on by Microsoft in their blog on July 28th.
Microsoft has confirmed in that blog that this is indeed a problem that results in a crash.
We also got confirmation from Microsoft that "this is a DoS only issue that was not addressed in MS06-040, but will be addressed in a bulletin."
We are looking forward to a patch from Microsoft, but have no indication of a timeline at this point.
In the mean time, seriously consider blocking ports 135-139 and 445 if you have not done so already. It is good advise to have them restricted on all but your fileservers at all times.
Block it in your perimeter using firewalls or routers (e.g. in SOHO setups) and block them in personal firewalls to help tightening it down (think about e.g laptops outside the perimeter).
--
Swa Frantzen -- Section 66
Microsoft has confirmed in that blog that this is indeed a problem that results in a crash.
We also got confirmation from Microsoft that "this is a DoS only issue that was not addressed in MS06-040, but will be addressed in a bulletin."
We are looking forward to a patch from Microsoft, but have no indication of a timeline at this point.
In the mean time, seriously consider blocking ports 135-139 and 445 if you have not done so already. It is good advise to have them restricted on all but your fileservers at all times.
Block it in your perimeter using firewalls or routers (e.g. in SOHO setups) and block them in personal firewalls to help tightening it down (think about e.g laptops outside the perimeter).
--
Swa Frantzen -- Section 66
Keywords:
0 comment(s)
MS06-040: BOLO -- Be On the LookOut
Over the weekend there was a botnet doing fairly wide scale scanning for hosts affected by the vulnerabilities in the MS06-040 advisory. While technically a botnet, it was spreading in a worm like fashion.
Be on the lookout for:
Swa Frantzen -- Section 66
Be on the lookout for:
- laptops that might have been infected returning to the inside of your perimeter.
- infected machines scanning the rest of the network
- infections flaring up due to the above
- If you have not done so yet:
- Roll out the MS06-040 patches ASAP.
- Do not forget to reboot those machines after patching!
- Check that all machines have been patched and rebooted, we have confirmations that the patches are effective in stopping the initial attack.
- Update anti-virus signatures: They might not be in the mainstream signature yet, so check manually what your vendor has to say.
- While at it, install filtering wherever possible for ports 135-139 and 445. E.g. enabling personal firewall on laptops is very smart in future-proofing your machines against this kind of attack.
- If you have an IDS, make sure you have signatures for the MS06-040 exploit
(best not aiming for the payload, but rather the exploit of the vulnerability) - For snort:
- BLEEDING-EDGE EXPLOIT NETBIOS SMB-DS DCERPC NetrpPathCanonicalize request (possible MS06-040)
[Bleedingsnort, free] - NETBIOS SMB-DS srvsvc NetrPathCanonicalize little endian overflow attempt
[Sourcefire VRT, subscription only till the 16th]
- Check for outgoing traffic to port 18067/TCP of the command and control (C&C) centers:
bniu.househot.com: (the main one)
61.189.243.240
202.121.199.200
210.75.211.111
211.154.135.30
218.61.146.86
58.81.137.157
61.163.231.115
ypgw.wallloan.com: (the fallback one)
58.81.137.157Please note these IP addresses can be changed quite easily by the controllers of the botnet, so checking (or even blocking) them in your DNS servers might be much more effective.
61.163.231.115
61.189.243.240
202.121.199.200
211.154.135.30
218.61.146.86
- Check for the presence of following files:
MD5 FILENAME
9928a1e6601cf00d0b7826d13fb556f0 wgareg.exe
9928a1e6601cf00d0b7826d13fb556f0 wgareg.exe
2bf2a4f0bdac42f4d6f8a062a7206797 wgavm.exe
- Check for the presence of the registry keys:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_WGAREG
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\Root\LEGACY_WGAVM
- Check for outgoing traffic scanning for others being vulnerable on port 445/TCP
- You really cannot and
- Even if you delete the keys that start the malware,
- your settings will be mangled. E.g.: a test infection with the wgareg.exe:
- created 17 new registry keys
- modified 77 other keys including keys used for firewalls, sharing of files, etc.
- That was just the infection itself, no follow up, no communications with the C&C
- Like any bot it is unpredictable in what the C&C caused the bot to do
- Wipe! (as in nuke from orbit)
- Backup data (if any) and keep these off-line
- Unplug the network
- Wipe the disk effectively (while booted from clean media)
- Reinstall software
- Install (personal) firewall, anti-virus, anti-spyware
- Apply patches & Update signatures
- Carefully restore needed data
For installing, see also our survival guide for XP
- Our initial write-up
- Update with a slight variant
- More infections
- LURHQ - Joe Stewart's analysis
- Symantec - W32.Wargbot
- TrendMicro - Worm.IRCBOT.JK and JL
- McAfee - IRC.Mocbot
- F-Secure - IRCBOT-ST
Swa Frantzen -- Section 66
Keywords:
0 comment(s)
×
![modal content]()
Diary Archives
Comments