• Home
• About
• Contact
• Applied Trust

The Barking Seal

• Applied Trust Schwag Brag

  31Oct
  Author: ned Categories: Green IT Comments: 0

  At Applied Trust, we’re often known as the company with the cool outdoorsy schwag. Has your Applied Trust schwag traveled to exciting and unique places with you, or does it otherwise have an interesting story to tell? If so, we’d love to hear about it!

  Send your “schwag brag” ideas (with photos) to schwagbrag@atrust.com. Whoever submits the most outrageous story and photo between now and December 31, 2008 wins a 3-day trip for two to beautiful Cozumel, Mexico!

  We’ve already received some great submissions – hurry up and get yours in the door!

  
  Tags: applied trust, contest, popular, schwag brag

• The front and back of application security

  22Oct
  Author: ben Categories: Security Comments: 0

  When we think about (or google) application security, most often we’re thinking about the common web application attack vectors – cross site scripting, injection vulnerabilities, and session management. With the prominence of the web as a new delivery platform, and the corresponding security standards and regulations developed around it, there’s no doubt that it needs a lot of attention.

  However, there’s a layer between the application’s internal security and the operating system that is less prominent in the eyes of the industry. For convenience, I’ll refer to it as the application platform here. The platform includes the nuts and bolts of integrating the application in to the environment, and includes things like:

  • File transfers between application components or servers
  • Log file location, centralization, and audit settings
  • Database server security (you’re not running SQL as a domain admin, right?)
  • Server role segregation at the network layer

  It’s a combined responsibility of the application and system administrators, along with a data security professional, to ensure that this layer isn’t ignored. Ideally, a full procedure should exist to make the implementation process efficient and tidy.

  If you’re hiring a vendor to deploy a fancy new proprietary application, they’re likely not going to be willing or able to ensure that it meets your strict internal security requirements. I’ve even met vendors that hadn’t planned to join their Windows servers to the domain, and tried to insist that it would be a support contract violation! Until we’re all enforcing certain security requirements on vendors, this attitude isn’t likely to change, but that’s a topic for another day.

  I cover background and a full process on this at length in the February 2008 issue [PDF] of INSECURE magazine (and in HTML format on the Applied Trust web site).

  
  Tags: hardening, platform security, vendors

• Keystroke dynamics: A practical web implementation

  20Oct
  Author: admin Categories: Security Comments: 13

  As I began down the dismal path of studying for my (ISC)² SSCP certification I ran across an interesting concept in my study guide called “keystroke dynamics.”  Basically it’s a form of 2-factor authentication that allows users to authenticate not only by password but also by the way in which they type their password.

  What’s interesting is it is one of the only forms of biometric authentication that can be implemented at little cost with currently available technology.  Of course there are cons to KSD (don’t get arthritis!) but if you give users the option to authenticate by KSD OR via a series of the usual what’s-you-mother’s-maiden-name questions, I believe this could be practically implemented.

  KSD relies on analyzing dwell time (the time a user keeps a key depressed) and flight time (time between typing one character and the next).  This data is recorded and then transmitted along with your password.  If there is too much delay between the valid dwell time or flight time access is denied.

  I thought I’d attempt a web implementation using PHP and JavaScript.  You can see the results of this endeavor by playing with the demo below.  It captures dwell and flight differences in milliseconds and if you are within the valid omega for each and posses the valid password you will be granted access.

  I was playing with the mathematics behind this the other day and it seems like this would make it exponentially harder for an attacker to brute force a user’s password.  If we take the dwell and flight omegas I use in the demo below (120ms and 100ms respectively) and let’s suppose from person to person dwell times deviate approximately 400ms and flight times can deviate 1000ms we can calculate how many more combination are possible in a standard 8 character password:

  (400ms / 120ms) * (1000ms/100ms) = ~33 unique ways you can type one character

  (400ms / 120ms)^8 * (1000ms/10)^7 = ~152,415,790,276 ways to type an eight character password

  This means, even if an attacker knew your password (ie. saw you type it or by means of keylogger) he would then in theory have to try all the 152 billion possible ways to type the password.

  
  Tags: biometrics, brute force, keyboard dynamics, popular, secure login, sscp certification, two-factor authentication

• Walk, then run – thoughts about event value

  11Oct
  Author: trent Categories: Ramblings, Security Comments: 0

  In his post On the difficulties of event correlation, Ben talks about how hard event correlation is – and I couldn’t agree with him more.  In addition, I am often surprised about how many organizations blindly run down the path to adding more event collection to their environment before they understand the ones they already have.

  A great example is IDS deployment.  Along with the rest of the infosec establishment, I generally agree that enterprise-wide IDS can be an important part of a comprehensive infosec program.  However, I often see that such deployments don’t succeed in the long run.  Everyone is excited about it initially, but after a few months their interest wanes and the platform falls into a state of disrepair.  Why?  Is it because IDS data isn’t useful?  Not at all.   Instead, I think these are the drivers:

  1. Poor event correlation.  Ben makes some suggestions as to why, but the bottom line is that it’s really hard to use data that isn’t correlated with the rest of the environment.
  2. Failure to budget staff resources to maintain the platform — there is an additive staff cost of deploying IDS, even if 7×24 monitoring is outsourced.
  3. IDS events are not on the top of the list of “event value.”  By “event value,” I mean that eventually, folks realize that there are more important events that they’re not capturing.  Events like “server down,” “disk full,” or “network linked failed.”  If they’re not reporting/handling these higher value events already, adding a high quantity of lower value events results in them being perceived as noise.

  This last item is really important and apparently not obvious.  The bottom line is this: before deploying a platform like an IDS, first make sure that you’re already capturing and managing the interesting, high-value events that currently exist in the environment.  OS and infrastructure device logs are already easily available, take time to capture them centrally and use them.  One that’s been mastered, then it’s reasonable to take on the IDS event stream.

  
  Tags: rants, Security

• On the difficulties of event correlation

  10Oct
  Author: ben Categories: IT Management, Security Comments: 2

  
  You wouldn’t know it by the number of vendors and products on the market, but event management and log correlation is really, really hard. Despite the excellent work by folks like Anton Chuvakin, enlisting any support at all for log centralization, monitoring, auditing, and intrusion detection can be like pulling teeth.

  Indeed, who can blame leadership for hating event management?

  • It’s extremely time intensive to do well
  • It’s expensive, even if you go with an open source platform
  • Maintenance is a lot of work, requiring lots of hardware (particularly storage) and expertise
  • It’s woefully inaccurate, and stunningly misleading in some cases

  My biggest frustration? The lack of a standard format. Sure, the logging experts will point out that acronym-filled standards like the CEF (Common Event Format) or the WTEF (WebTrends Enhanced Format) are out there, but nobody uses them. Thus, it’s left as an exercise to the leader to normalize logs in to a universal format.

  Moving this in to the real world for a moment, let’s ponder the challenges that this brings to an enterprise of, say, 5,000 employees. This enterprise likely has a lot of Windows servers running Windows-y applications like Active Directory, Sharepoint, and Exchange. Said organize probably has a few Unix or Linux systems around, spewing out syslog data. Lots of network devices are around generating firewall rule matches and error data, and there’s probably several proprietary applications logging directly to a localized database.

  A “real” event correlation system would need to capture, centralize, normalize, audit, correlate, and alert on ALL of this data. It will require lots of maintenance as upgrades occur and storage requirements go. And don’t depend too much on the vendor – they’re probably too busy forgetting to install patches to worry about “centralized what”?

  But guess what? It doesn’t matter – you have to do it[PDF].

  That isn’t to say that it’s hopeless. The point is to find the strategy that works best for your organization. Maybe you just capture the critical event logs from Windows systems. Or perhaps you have a world class IDS with custom rules that capture log in events. Whatever the case, don’t try to bite off more than you can chew, or it’s bound to fail in the end.

  
  Tags: Event Correlation, logs, popular, rants

• The myriad uses of SSH

  05Oct
  Author: ben Categories: Infrastructure Comments: 0

  Linux users are blessed with a plethora of useful network administration tools, not the least of which is the flexible and powerful OpenSSH suite. Most Linux admins consider using ssh to securely hop from system to system, but some of the other features are less widely known.

  File Transfers
  OpenSSH includes two tools, scp and sftp, to copy files over the network, and can be used in place of FTP in most cases. For example, to copy a file from the local system to a host called serverb, use:

  % scp file serverb:

  Similarly, to copy a file from serverb to the /tmp directory, use:

  % scp serverb:file /tmp
  ben@serverb's password:
  file                                    100%    0     0.0KB/s   00:00

  Use sftp to get or put multiple files and navigate the directory structure, much like ftp:

  % sftp serverb
  Connecting to harp...
  ben@serverb's password:
  sftp> ls
  boulder
  file
  foo
  bar
  depts.txt
  sftp> get file
  Fetching /home/ben/file to file
  sftp> put anotherfile
  Uploading anotherfile to /home/ben/anotherfile
  anotherfile                                    100%    0     0.0KB/s   00:00
  sftp>

  Public Key authentication
  Public key authentication is an underused tool that is great for convenience AND security. Public key auth is a form of two-factor authentication, requiring something you have (a key file), and something you know (a passphrase).

  In a nutshell, an OpenSSH tool called ssh-keygen is used to generate two files – a public and a private key file. The public key is distributed to all the hosts you log in TO, and the private key is on the host you log in FROM. Don’t share the private key with anybody! When the key pair is generated, a passphrase is provided to protect the file. Note that the passphrase is optional, but is strongly encouraged.

  Creating and distributing the key pair is covered widely elsewhere on the web, so I won’t repeat it here. However, a few troubleshooting steps will go along way – setting up a key pair the first few times can be frustrating! Here’s some tips if it isn’t working:

  • By default, the public key file needs to be called authorized_keys2 and live in the .ssh directory of the user.
  • The permissions of the .ssh directory must be 700, and the authorized_keys2 file should be 600.
  • By default, the permissions of the private key file must also be 600
  • Public key authentication will not work if the user’s password is not set
  • By far, the most common configuration issue is a permission problem!

  SSH Tunneling
  SSH tunneling can help with remote access to systems and ports that are typically hidden by a firewall. If, for example, you can SSH from your home to a server at work, but you cannot use remote desktop to log in to your windows system at your desk, SSH tunneling can help. Since the server running SSH is on the internal network, you can “tunnel” a connection through the SSH server to access the Windows server. In the following example, the SSH server is called serverA, and the Windows desktop is desktopA. The command connects port 4389 on the local system to port 3389 on desktopA.

  % ssh -L 4389:desktopA.yourdomain.com:3389 username@serverA.yourdomain.com

  To access desktopA, open the remote desktop program and use “localhost:4389″ for the host name. To forward multiple ports, simple add additional -L flags to the command line.

  Running port forward commands manually from the command line can be tricky, and certainly isn’t very useful for Windows clients without Cygwin. Most modern SSH clients, such as PuTTY and SecureCRT, include a graphical interface for SSH tunneling.

  Hopefully these SSH tips simplify your daily administration activities!

  
  Tags: linux

• Adding a second SCSI adapter at boot on RHEL 4

  05Oct
  Author: ben Categories: Infrastructure Comments: 0

  At Applied Trust one of our servers has a built-in SCSI disk with a single LVM volume group and several logical volumes. It also has an Apple Xserve array attached via an LSI Logic fibre channel card. The Xserve array has a second volume group with only a single logical volume. The filesystems on all the logical volumes need to be mounted at boot for the system to work properly. Unfortunately, there seems to be some bug in RHEL4 that prevents the second volume group from being detected at boot unless the SCSI adapter module (mptscsih in this case) is inserted with initrd. The Red Hat installation did not support this configuration.

  To fix it, I added a second SCSI adapter to /etc/modprobe.conf:

  alias scsi_hostadapter1 mptscsih

  then I rebuilt initrd for the kernel we’re using:

  % sudo /sbin/mkinitrd ./initrd.img 2.6.9-5.ELsmp

  I inspected the new initrd manually to make sure the module would be loaded:

  % mkdir initrd
  % cp initrd.img initrd
  % cd !$
  % cd initrd
  % gunzip -S .img initrd.img
  % cpio -i < initrd
  cpio: dev/ram: Operation not permitted
  cpio: dev/console: Operation not permitted
  cpio: dev/tty3: Operation not permitted
  cpio: dev/null: Operation not permitted
  cpio: dev/tty1: Operation not permitted
  cpio: dev/tty4: Operation not permitted
  cpio: dev/systty: Operation not permitted
  cpio: dev/tty2: Operation not permitted
  4742 blocks
  % cat init
  #!/bin/nash
  
  mount -t proc /proc /proc
  setquiet
  echo Mounted /proc filesystem
  echo Mounting sysfs
  mount -t sysfs none /sys
  echo Creating /dev
  mount -o mode=0755 -t tmpfs none /dev
  mknod /dev/console c 5 1
  mknod /dev/null c 1 3
  mknod /dev/zero c 1 5
  mkdir /dev/pts
  mkdir /dev/shm
  echo Starting udev
  /sbin/udevstart
  echo -n "/sbin/hotplug" > /proc/sys/kernel/hotplug
  echo "Loading scsi_mod.ko module"
  insmod /lib/scsi_mod.ko
  echo "Loading sd_mod.ko module"
  insmod /lib/sd_mod.ko
  echo "Loading megaraid_mm.ko module"
  insmod /lib/megaraid_mm.ko
  echo "Loading megaraid_mbox.ko module"
  insmod /lib/megaraid_mbox.ko
  echo "Loading mptbase.ko module"
  insmod /lib/mptbase.ko
  echo "Loading mptscsih.ko module"
  insmod /lib/mptscsih.ko 
  echo "Loading dm-mod.ko module"
  insmod /lib/dm-mod.ko
  echo "Loading jbd.ko module"
  insmod /lib/jbd.ko
  echo "Loading ext3.ko module"
  insmod /lib/ext3.ko
  echo "Loading dm-mirror.ko module"
  insmod /lib/dm-mirror.ko
  echo "Loading dm-zero.ko module"
  insmod /lib/dm-zero.ko
  echo "Loading dm-snapshot.ko module"
  insmod /lib/dm-snapshot.ko
  /sbin/udevstart
  echo Making device-mapper control node
  mkdmnod
  echo Scanning logical volumes
  lvm vgscan --ignorelockingfailure
  echo Activating logical volumes
  lvm vgchange -ay --ignorelockingfailure VolGroup00
  echo Creating root device
  mkrootdev /dev/root
  umount /sys
  echo Mounting root filesystem
  mount -o defaults --ro -t ext3 /dev/root /sysroot
  mount -t tmpfs --bind /dev /sysroot/dev
  echo Switching to new root
  switchroot /sysroot
  umount /initrd/dev

  The bold section indicates that the mptscsih (and it’s dependency, mptbase) will be loaded by initrd.

  I moved the updated initrd to /boot:

  % sudo mv initrd.img /boot/initrd-2.6.9-5.ELsmp.atrust.img

  … then modified /boot/grub/grub.conf appropriately:

  # grub.conf generated by anaconda
  #
  # Note that you do not have to rerun grub after making changes to this file
  # NOTICE:  You have a /boot partition.  This means that
  #          all kernel and initrd paths are relative to /boot/, eg.
  #          root (hd0,0)
  #          kernel /vmlinuz-version ro root=/dev/VolGroup00/LogVol00
  #          initrd /initrd-version.img
  #boot=/dev/sda
  default=0
  timeout=5
  splashimage=(hd0,0)/grub/splash.xpm.gz
  hiddenmenu
  title Red Hat Enterprise Linux WS Atrust (2.6.9-5.ELsmp)
          root (hd0,0)
          kernel /vmlinuz-2.6.9-5.ELsmp ro root=/dev/VolGroup00/LogVol00 rhgb quiet
          initrd /initrd-2.6.9-5.ELsmp.atrust.img
  title Red Hat Enterprise Linux WS (2.6.9-5.ELsmp)
          root (hd0,0)
          kernel /vmlinuz-2.6.9-5.ELsmp ro root=/dev/VolGroup00/LogVol00 rhgb quiet
          initrd /initrd-2.6.9-5.ELsmp.img
  title Red Hat Enterprise Linux WS-up (2.6.9-5.EL)
          root (hd0,0)
          kernel /vmlinuz-2.6.9-5.EL ro root=/dev/VolGroup00/LogVol00 rhgb quiet
          initrd /initrd-2.6.9-5.EL.img

  Reboot for settings to take effect.

  
  Tags: linux