The details of this security event are already well-documented (see the original security notification in Red Hat’s Portal or this 3-minute video providing a high-level overview). So, what can your IT organization do to be better prepared for the next security event? Here are four practical actions you can take now to improve your Security Lifecycle Program.

Read the rest of “Four practical steps to improve your Security Lifecycle Program”

http://www.meetup.com/GHGLUG/

Want to change the ownership of all files in a directory to a user named ‘foo’?  Think this is a good way to do it?

chown -R foo * .*

Yeah, don’t do that. In one of those awesomely awful “D’oh” moments, I did that.  Remember: “.*” matches “..”.  So that will traverse up one level, and then recursively back down.

And of course …. I ran this in /mnt .   It took me about 5 seconds to realize what I had just done, before hitting ^c.  Yeah, my system is b0rked.

Resolution provided by Simon Sekidde at Red Hat:

On Red Hat Enterprise Linux (and derivatives), there is an easy way to re-initialize the ownership and permissions of RPM-installed files:

for i in `rpm -qa`; do  rpm --setugids $i;  rpm --setperms $i; done

Make sure to use –setugids before –setperms; if the order is reversed, changing the ownership with –setugids will reset any suid/sgid bits set by –setperms.

I attended for the first time last night (2014-01-30), and will look to attend regularly (monthly).  Checkout the Meetup page: http://www.meetup.com/GHGLUG/

I do miss my team and other friends at UConn.  UConn gave me great opportunity, both to gain strong technical skills, and to experience leadership, both formally as management, and informally as a mentor and vocal innovator.  I place great value in those first 13 years of my professional career, and I look forward to achieving similar gains in my next 13 years!

I recently had the opportunity to join Gordon Haff ( Red Hat’s Cloud Evangelist ) and Ellen Newlands ( Red Hat’s Security and Identity Product Management) for a discussion about Identity Management and Cryptography.  Check out what we had to say (audio or text) on Gordon’s Cloudy Chat Podcast .

My preference is for ISO8601 time formatting, so I am using:

$> echo 'export HISTTIMEFORMAT="%F %T "' >> ~/.bash_profile

But of course, any ‘date’ formatting will work ( see “man date” for more information ).

So, I have just posted jasig-cas-quickdemo to GitHub.

jasig-cas-quickdemo is a Maven project that does the following:

• Downloads and builds the JASIG CAS project,
• Uses the Maven Tomcat plugin, download deploy Tomcat 7,
• Generates an SSL cert for HTTPS access, and exports the public cert in PEM format for use by CAS clients,
• Launch CAS on the local Tomcat 7 instance, with the default username=passwored authenticationHandler,
• Grants access to the ‘admin’ account for the Services Management interface.

Try the following on Fedora 19+:

$ yum install maven git
$ git clone https://github.com/forsetti/jasig-cas-quickdemo.git
$ cd jasig-cas-quickdemo
$ mvn integration-test

Then just point your browser to https://localhost:8443/cas , and you should see the default CAS login screen.

Check out the README for more information.

I am running a Lenovo Thinkpad T430s with Red Hat Enterprise Linux 6.4 Server.  I have a 256GB SSD, which has a 512M boot partition, and the rest is a LUKS encrypted PV, with several LVs for my filesystems.

I booted the laptop and received a black screen with only two words in white on it:

Error 17

Yep, that’s it, nothing more. Guessing that “Error 17” is a GRUB error (confirmed by Google),  I grab my trusty RHEL6.4 USB installer (created with livecd-tools), and boot into rescue mode.  A quick fdisk -l shows me a perfectly valid partition layout with a single ~5.5GB partition …. wait, that doesn’t seem right.

So, let me go check my partition table backup that I make periodically.  Heh, yeah right.

I vaguely recall my drive layout was as I described above in the second paragraph, but how the heck am I suppose to confirm if my data is still in place (please let this be just a corrupt partition table!!!), and then figure out the partition boundaries and reconstruct the table?

Googling brought me to a posting on Dedoimedo, which pointed me to the awesome TestDisk utility by CGSecurity.  I grabbed the Linux x86_64 binary package provided by the site, and followed the CGSecurity TestDisk instructions to analyze my disk.  Sure enough, it found the first partition 512MB, and then a second 2MB partition.  I read a little about how TestDisk works, looking for signatures for ext2,ext3,ext4,FAT, btrfs, etc., so I understood that it found my first partition which was ext4, but it didn’t know what to do with my LUKS partition.  I was pretty sure that the first one was correct, though, so I went ahead and let TestDisk write a new partition table.

Then I fired up fdisk -cu , and deleted the 2nd partition, then recreated it starting at the sector following the first partition, and extending to the last sector on the disk.  I was pretty certain that I had used the rest of the disk …. but still added a healthy dose of finger-crossing.

I wrote the disk partition out, rebooted into rescue mode again, found my way to a shell, and attempted to mount the first partition – success!

Next, I proceeded stepwise to access the second partition:

#> cryptsetup isLuks /dev/sda2           #First, test to make sure this is recognized as a LUKS device -- it was!
#> cryptsetup luksOpen /dev/sda2 foo     #Open the LUKS encrypted device as new device "foo"
#> pvs                                   #Scan for LVM PVs, which foo should be -- and it was found!
#> vgchange -ay                          #Activate all LVM VGs on discovered PVs -- and my VG was found!
#> lvs                                   #Scan for LVM LVs -- and mine were found

At this point, I mounted my home LV, and was able to take a backup. Feeling brave, I gave the laptop a reboot, and everything is running as before.

So, thank you to Dedoimedo for pointing me towards TestDisk, and thank you to CGSecurity for the great tool!

The extension starts by issuing an SSDP request from a local ephemeral UDP port to 239.255.255.250 port 1900.  The Chromecast will respond from its IP and another ephemeral UDP port, back to your source UDP port.

IPTables cannot track this simply as “RELATED”, given that the target of the first packet is the multicast address, while the source of the response packet is the Chromecast’s IP.  And unfortunately, there is no SSDP conntrack module (at least, not that I am aware of, at the time of writing this post).

Therefore, the best we can do for now is to open the ephemeral port range on the client machine.  The list of ephemeral ports, as defined by your Linux machine, can be found by:

cat /proc/sys/net/ipv4/ip_local_port_range

Fedora19 uses firewalld, so you will want to use the following:

firewall-cmd --permanent --add-port=32768-61000/udp
firewall-cmd --reload

Given the wide range of ports being opened, you may want to restrict access to just your local network. Consider using Network Manager to associate your NIC (eth0,wlan0, whatever) with your “home” zone, and use the following command instead of the above:

firewall-cmd --permanent --zone=home --add-port=32768-61000/udp

On non-firewalld systems, use this IPTables one-liner (modifying 192.168.0.0/24 as appropriate for your home network):

iptables -A INPUT -s 192.168.0.0/24 -p udp -m udp --dport 32768:61000 -j ACCEPT

Launch Chrome, click the Cast extensions, and it should now “Just Work”.  And if it doesn’t …. please let me know in the comments on this post.

UPDATE 20150803 – A few additional notes inspired by the great comment from mauriciograciag:

Note the use of the “–zone=home” parameter in the second firewall-cmd example above.  This can be a more secure option, but does require ensuring that you have a zone named “home”, and that Network Manager associates your active network profile with this zone.  If the Network Manager configuration is in place, I do recommend using that option for those working from systems (laptops) that might also find themselves on alternate networks.  However, for desktops that will not be connected to other networks, use of a zone will likely not add any tangible benefits.

If you set these rules via firewall-cmd and wish to revert them, the following should do the trick:

firewall-cmd –permanent –remove-port=32768-61000/udp
firewall-cmd –permanent –zone=home –remove-port=32768-61000/udp
firewall-cmd –reload

And lastly, note that the iptables rule must be run as root. Typically, this will be done by updating the iptables startup configuration for your favorite Linux distribution (e.g., you may need to add that line to /etc/iptables); but you might also want to run this a single time, non-persistently, from the command line.  If you have configured sudo appropriately on your Linux systems, preceding the iptables command with “sudo” would work as follows:

sudo iptables -A INPUT -s 192.168.0.0/24 -p udp -m udp --dport 32768:61000 -j ACCEPT