AtifKamal.com Blog

I’ve been using OpenVPN for a few years on Linux to establish site to site VPNs. It has never let me down, and i was always able to get the configuration working in the way I wanted it, without much effort and fiddling. Another nice ability of OpenVPN is that it can work it’s way through almost any firewall, which can be especially nice when working with restricted internet access.

A few days ago, i’ve got into a situation where I needed to get to a site to site VPN up as quickly as possible, behind a restrictive firewall. I’ve started with the obvious route, and found a few resources referring to OpenVPN on the net.

One of them is the OpenVPN GUI, which is mostly aimed at roadwarrior scenarios. The Windows installation notes and the Windows section in the howto are quite sparse. As such, my expectations weren’t high.

Installing OpenVPN results in the creation of a virtual ethernet adapter, that’s backed by the TAP driver (which is not signed). The install went fine, and configuration was the same as on Linux.

The Windows installer automatically installs as service that defaults to a disabled state, which when started launches OpenVPN for all *.ovpn files in %ProgramFiles%\OpenVPN\config. Simple, but efficient. Logs get written to %ProgramFiles%\OpenVPN\log.

After creating an appropriate configuration, i put it into the config dir, started the service, and everything just worked. Right out of the box. Without thinkering. Without error messages. It just worked.

As such, the application clearly shows it’s Linux/Unix origin, but it works nicely. Windows administrators that have never worked with a unix-like operating system might be put off by the application. I would still suggest everyone to take a look at OpenVPN for some low cost VPN improvisations.

The server I need to install Red Hat Enterprise Linux on does not have a floppy drive or CD-rom drive, but it has a USB port. What are the steps to configure a USB pen drive to boot and install Red Hat Enterprise Linux?

To configure a USB flash/pen drive perform the following steps:

1. Format the USB flash drive as one FAT partition.

   
   #mkdosfs /dev/
   

2. Copy the contents of /RedHat/isolinux/ from the first installation CD to the USB flash drive. NOTE: isolinux.bin, boot.cat and TRANS.TBL can be removed or deleted.

3. Rename isolinux.cfg to syslinux.cfg.

4. Copy /RedHat/images/pxeboot/initrd.img from the first installation CD to the USB flash drive.

5. OPTIONAL: To configure any boot settings, edit the syslinux.cfg on the USB flash drive. For example to configure the installation to use a kickstart file shared over NFS,specify the following:

   
   #linux ks=nfs:://ks.cfg
   

6. Make the USB flash drive bootable. Be sure to UNMOUNT the USB flash device.

   
   #umount /dev/
   #syslinux /dev/
   

7. Install GRUB on the USB flash drive.

   
   #mount /dev/ /path/to/local/USB/mount
   #grub-install --root-directory=/path/to/local/USB/mount /dev/
   

8. Verify that the USB flash drive has a /boot/grub directory. If it does not, create the directory manually.

   
   #cd /path/to/USB/local/mount
   #mkdir -p /boot/grub
   

9. Create the grub.conf file. Below is a sample grub.conf:

   
   default=0
   timeout=5
   root (hd1,0)
   title
   kernel /vmlinuz
   initrd /initrd.img
   

10. Copy or confirm the created grub.conf file is on the /boot/grub/ directory of the USB flash drive.

The 2009 Data Breach Investigation by Verizon is out, and I have to be honest, all I’ve had time to read so far has been pages 41-43. Why those pages? Because they’re the pages that specifically call out the statistics surrounding breaches affecting merchants who are (or should be) complying with the Payment Card Industry Data Security Standards (PCI DSS). Not at all surprising, at least to me, is that the study found that PCI compliance is important and that 81% of the companies researched in this report weren’t PCI compliant at the time of the breach. Of course, that also means that 19% of the companies breached had either self-assessed or been assessed by a QSA and were thought to be compliant at the time of the breach.

Read Full Article