Title

Autem vel eum iriure dolor in hendrerit in vulputate velit esse molestie consequat, vel illum dolore eu feugiat nulla facilisis at vero eros et dolore feugait

Monthly Archives: February 2017

Fix Home Directory Permissions for SSH Logins on AWS Instance

Fix Home Directory Permissions for SSH Logins on AWS Instance

What happens when you accidentally change the permissions on the ec2-user’s home directory in an AWS instance?  You get locked out – no more SSH access!

Before you panic (like I did at first), there is a solution.

  1. Shutdown the instance that is affected
  2. Make a note of the root (/) volume name and detach it (hopefully you chose an EBS backed volume for your root partition) from the instance. This is most likely attached as /dev/sda1 (this is VERY important later)
  3. Attach the volume to another instance (if you don’t have another one, just launch one) and name it something or accept the one chosen for you. In this case, we’ll assume /dev/sdd (you can add 1 to the end of it if you’re picky, but I just stuck with the default – it DOES matter in the next step)
  4. Mount the volume you just attached:
    1. As root on the other volume type:
      1. “mkdir /aws-root” (to create the mount point
      2. “mount /dev/xvdd /aws-root” (Linux renames the device by changing the ‘s’ to an ‘xv’ – most likely a Xen thing. NOTE: the device has to have the same name you gave it when you attached it – taking into consideration the Xen device name change.  In other words, /dev/sdd becomes /dev/xvdd; /dev/sde becomes /dev/xvde; and so on.
    2. Now you have the volume mounted and can change the home directory permissions. Using our mount point, they would be located in /aws-root/home/ec2-user:
      1. “chmod 700 /aws-root/home/ec2-user”
    3. Unmount the volume (make sure you’re not in the directory by doing a quick pwd first):
      1. “umount /aws-root”
    4. Detach the volume from the instance
    5. Attach the volume to the original instance. This time, BE SURE to name it /dev/sda1 <– the 1 is IMPORTANT – otherwise your instance won’t boot because the kernel won’t be able to find your root partition!!

Start your instance up again and you should now be able to login again with SSH.

How to Capture Traffic on Cisco ASA / PIX (sniffer)

How to Capture Traffic on Cisco ASA / PIX (sniffer)
 

To capture traffic on a Cisco ASA or PIX firewall the capture command can be used.

Example: Capturing traffic on ASA/PIX

You want to capture traffic from/to host 10.100.100.1 located behind the dmz interface.

The access-list is optional and is used to filter to interesting traffic
pix(config)# access-list interesting_traffic permit ip host 10.100.100.1 any
pix(config)# access-list interesting_traffic permit ip any host 10.100.100.1
pix(config)# capture cap1 access- interesting_traffic interface dmz

pix1(config)# show capture
capture cap1 access-list access-interesting interface dmz

Commands to show capturing results:
show capture cap1
show capture cap1 detail
show capture cap1 dump

Command to clear captured traffic:
clear capture cap1

Command to save results to tftp server:

copy capture:cap1 tftp://10.1.1.1/dmzhost.txt

To save results in pcap format:
copy capture:cap1 tftp://10.1.1.1/dmzhost.txt pcap

Command to disable capturing:

pix(config)# no capture cap1

 

This can be very helpful in troubleshooting connectivity issues.  I most recently used this to troubleshoot VoIP issues for a customer.

Houston Airport System Selects Zenoss to Monitor Cisco Switches, Routers, and Firewalls

I recently implemented the Zenoss Enterprise appliance for the City of Houston Airport System to monitor over 250 Cisco network devices located at George Bush Intercontinental (IAH), William P. Hobby (HOU), and Ellington Airport (EFD).

Why Zenoss? According to the CTO of the Houston Airport System, Matt Hyde, the implementation of Zenoss “will give us greater visibility and control over our network devices and reduce our current monitoring costs”. He goes on to say that “within sixty days, we were able to make the switch to [Zenoss] and will pay for the cost of the new system with just two months of network monitoring savings. Total annual cost reductions are over 500%. Rarely do we ever get an ROI of that magnitude and we would not have achieved these savings without the help of Pate Consulting [implementing Zenoss].”
The appliance was nicely assembled in a 1U rack-mountable server. After plugging in the necessary keyboard, mouse, monitor, power, and network cables I powered it on and watched it proceed to boot CentOS 5.3

 

Aside from the necessary ‘yum update’, all I had to do was configure the correct time, time zone, assign a valid IP address, and setup an SMTP server (if you want Zenoss alerts sent via email, of course). As usual, I recommend Postfix.

 

Install and configure Postfix:

[root@host]# yum install postfix

[root@host]# vi /etc/postfix/main.cf

 

Change myhostname to a valid hostname in your environment

Make postfix startup on boot

 

[root@host]# chkconfig –level 2345 postfix on

[root@host]# service postfix start

 

Make sure that Postfix and Zenoss are running:

 

[root@host]# service postfix status

[root@host]# service zenoss status

 

Once we do that, then its on to the easy part – Zenoss Web Interface.

 

After adding all 5 networks, Zenoss automatically scanned them flawlessly.

 

As should be the case, the Cisco SNMP community string was not the Zenoss default ‘public’. This would cause problems if not corrected.

 

To solve this problem, I edited the SNMP community string in the /Network/Router/Cisco and /Network/Cisco class templates so that any device added to these classes would automatically inherit the correct community string.

 

Click on “Devices” on the left side menu then select the device class Network. Now, select the device class Router, then Cisco. At this point, the breadcrumb navigation should be “/Devices/Network/Router/Cisco”. This can be found just below the Zenoss logo. Click on the zProperties tab for this class. Change zSnmpCommunity to the new value. Just for good measure, go ahead and put your new community string in the zSnmpCommunities text area as well and save changes. From now on, every device you add to the /Network/Router/Cisco device class will inherit the new snmp community string. This is a lot of work for a few devices, but if you’re adding 250 devices this “feature” is a time-saver!

 

Overall, I was impressed with the Zenoss appliance and the City of Houston benefited from the power and flexibility of Zenoss.