evilrouters.net

Yesterday, December 15th, Adobe posted APSA09-07, “Security Advisory for Adobe Reader and Acrobat”, which is summarized as follows:

Adobe has confirmed a critical vulnerability in Adobe Reader and Acrobat 9.2 and earlier versions that could cause a crash and potentially allow an attacker to take control of the affected system. There are reports that this vulnerability is being actively exploited in the wild. Adobe recommends customers follow the mitigation guidance below until a patch is available.

Furthermore, Adobe mentioned that they plan to release an update by January 12, 2010. That’s 28 days — a LONG time for a security vulnerability that is being actively exploited in the wild. Fortunately, there appears to be a simple way to mitigate this vulnerability: disable JavaScript.

For individual users or those not on a corporate network, the easiest way is to simply do the following:

• Launch Adobe Acrobat or Adobe Reader
• Select Edit, then Preferences
• Select the JavaScript category
• Uncheck the “Enable Acrobat JavaScript” option
• Click OK

This should mitigate the issue.

Unfortunately, some of us have hundreds or thousands of desktops and visiting each one to change this setting is not feasible. Luckily, I stumbled across an Administrative Template for a Group Policy Object that was created by Elazar Broad earlier this year, in reference to APSA09-01. For those who may not be completely familiar with creating a Group Policy Object using this Administrative Template to disable the JavaScript functionality domainwide, I have created a video demonstration of how to do so.

First, download the administrative template here, then click here to watch the video.

Quick video demonstration of a basic HSRP configuration on a pair of routers:

This is probably the shortest video I’ve ever made, but the task is really simple — configuring the Simple Network Time Protocol (SNTP) on an HP ProCurve switch.

For reference, here’s the “sntp” commands available in the software:

ProCurve Switch 2610-48(config)# sntp ?
 broadcast             Operate in broadcast mode
 <30-720>              The amount of time between updates of the system clock 
                       via SNTP
 server                Configure SNTP servers to poll time from.
 unicast               Operate in unicast mode
 <cr>

…and, of course, “timesync” takes an argument too…

ProCurve Switch 2610-48(config)# timesync ?
 sntp                  Set the time protocol to SNTP
 timep                 Set the time protocol to the TIME protocol

Pretty simple, huh? Here’s the video:

Nothing earth-shattering here, but back in February, I posted “Upgrading ProCurve firmware via TFTP”. Since that time, I’ve started posting video demos of some of the things I write about, so I thought I’d make up a quick one for this task as well. I happen to have a 5412zl switch sitting here next to me that I just powered up for the first time, and I know from the search terms people use to reach my site that this is one of the most popular HP-related posts, so perhaps seeing this in action will help understand it as well.

The first thing you’ll want to do is head over to ProCurve’s “Software for switches” page and grab the appropriate software for your switch. At the time of this writing, K.13.63 is the latest available on the web site, however I grabbed K.13.68 from HP’s FTP server. Unzip the file that you download, read the release notes, and copy the software over to your TFTP server.

After that, it’s just a matter of following the steps in the previous post.

Here’s an update in action (note that this switch shipped with K.12.57 and all software versions after K.13.61 include a BootROM update, so we’ll our switch reboot automatically in the middle of the update. Also, by default, the switch use DHCP will acquire an IP address on VLAN 1, so we don’t have to configure one (though it’s always a good idea, of course).

Note that this whole process takes quite a bit longer than shown in the video. When I was done recording, the video came in at 08:19 long. By removing a lot of the “waiting”, I was able to get it down to the 02:42 that you see here.

I wanted to follow-up to an earlier post, “Using BGP communities to influence routing”, and show some more ways we can use BGP communities to influence routing on the Internet. What we’re going to see today is very common in the real world, although it does take the cooperation of your service provider.

If you’re lucky, your service provider will have already published a listing of communities that they accept and what effect they have. The ones we’ll be using today come from an old XO Communications document that I found.

Here’s the topology we’re going to be working with today:

We’re going to be the customer, in AS 65001. To keep things simple, we’ll configure a single connection on one service provider, XO Communications in AS 2828. As you can see, XO peers with a number of other providers. We have three loopback interfaces that we’re going to create, and the IP addresses we assign to those will be the ones we’re advertising into BGP.

Under normal circumstances, XO would simply pass along our advertisements to its peers. We’re going to see how we change that, however, by applying some communities to our routes as we send them to XO.

Here we have a small example of the communities a service provider might accept. By tagging our routes with these values, we can control how XO handles those routes. For example, if we send community 2828:1003, XO won’t advertise that route to Sprint. Likewise, if we send community 2828:1308, XO will prepend its own AS number three times. The possibilities are endless.

The bottom half of that diagram shows what we’ll actually accomplish when we’re done. When advertising our routes, we’ll use communities to tell XO:

• don’t advertise 192.168.0.1/32 to Sprint (2828:1003),
• prepend twice when advertising 192.168.0.1/32 to Level3 (2828:1207),
• prepend once when advertising 192.168.0.1/32 to AT&T (2828:1108),
• prepend thrice when advertising 192.168.1.1/32 to Sprint (2828:1303),
• don’t advertise 192.168.1.1/32 to Level3 (2828:1007),
• prepend twice when advertising 192.168.1.1/32 to AT&T (2828:1208), and
• advertise 192.168.2.1 normally (no communities)

That’s a big list of demands, but it’s actually quite easy to do and — even better — it doesn’t require us to deal with another person at our service provider. By using these communities, we can do it ourselves (and change it whenever we want!).

For this lab, the XO, ATT, SPRINT, and LEVEL3 routers have already been configured. I’m intentionally not posting the configuration from XO, as it is out of the scope of this posting. While I may post it later, we’re only worried about how to configure things on the customer side.

Here we go…