Updating to iOS 7.0.5 Turned Ugly

During the update of my iPhone it got stuck in the so-called recovery mode. This means that everything on the iPhone is lost, and that you need to restore everything from a backup. Thankfully, the last backup was made 10 minutes before the upgrade process began. So no worries there.

The panic started to kick in when the actual recovery process terminated with an unknown error (17).

An unknown error occurred (17)

No matter what I tried, the error kept re-occurring

Searching the Interwebs,  I founds several forums mentioning modifying the hosts file on your computer. Any entries referring to the apple.com domain should be removed.

Checking the hosts file out (located @ /etc/hosts on a Mac), I found a reference to a gs.apple.com with a specific IP address. At that point things started to dawn on me....

A couple of years ago I started to experiment with creating your own MobileMe thing (so I would have no need to purchase a MobileMe account back then). In that process you needed to fake some Apple web-servers. One of those servers was gs.apple.com.

After removing the entry from my hosts file and rebooting my iMac, the recovery process went flawlessly.

This 'experience' made me wonder; Did the 'crash' of the iPhone happen because of the hosts file entry? If so, this could be disastrous if someone made these servers unresponsive (e.g. DNS hack, or whatever), since the iPhone would become a brick. At least for as long as these servers are not accessible....

Expired SSL Certificates

When I'm doing my thing on customer projects, and there's some SSL stuff involved, I always keep reminding them to make sure that they renew their certificates in time. Why, because they almost always forget it the renew them in time, and after the expire stuff stops working, and they call us.

Guess what? My certificates expired this evening, so I got numerous warnings and errors in several applications that use those SSL certificates. Thankfully I run my own CA (XCA), and I documented where I use them, and how to replace them, so I was back in business in 10 minutes.

Lesson(s) learned: make a notification in my calendar to replace them ahead of time.

Quick And Dirty Juniper SRX IDP Test Config

When implementing a SRX IDP (Intrusion Detection and Prevention) configuration, you may want to check if everything is working properly. The 'default' templates supplied by Juniper can't be tested easily, since they protect your network from very specific attacks. Chances are small that you'll see one while you're testing. 

I usually use a simple ICMP-TEST policy which will drop all ICMP traffic, and logs the event to a local file (for basic testing, but you'll want to forward these events to a syslog server).

IDP Config: 

set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match from-zone any
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match source-address any
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match to-zone any
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match destination-address any
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match application default
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match attacks predefined-attacks ICMP:INFO:ECHO-REPLY
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 match attacks predefined-attacks ICMP:INFO:ECHO-REQUEST
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 then action drop-packet
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 then notification log-attacks alert
set security idp idp-policy ICMP-TEST rulebase-ips rule 1 then severity critical
set security idp active-policy ICMP-TEST

Add the IDP to the appropriate firewall rules and verify that your ICMP (ping) packets are being dropped.

Firewall rule example: 

set security policies from-zone trust to-zone untrust policy trust-to-untrust then permit application-services idp

If your ICMP packets aren't being dropped while 'pinging' to Google DNS (8.8.8.8), you dit something wrong :-)

View fullsize

Verification of IDP functionality in Splunk. 

I'm Published (sort of...)

Someone mentioned that they found a link to my website in a Juniper exam training PDF. Looks like I did a good job on describing the implementation of the Application Firewall feature in the Juniper SRX.

Here is the link to the actual article.

Capture Network Traffic With Wireshark Under Ubuntu

When you install Wireshark on Ubuntu Linux you need to be root to be able to capture traffic. The standard user doesn't have enough privileges to do this. 

A workaround for this is to add the user to a wireshark group and give the group special permissions. Afterwards, you're able to cpature traffic in Ubuntu with Wireshark, without needing root access. 

The complete list of commands: 

sudo groupadd wireshark

sudo usermod -a -G wireshark <YOUR-USER-NAME>

sudo chgrp wireshark /usr/bin/dumpcap

sudo chmod 750 /usr/bin/dumpcap

sudo setcap cap_net_raw,cap_net_admin=eip /usr/bin/dumpcap

sudo getcap /usr/bin/dumpcap

Just reboot, or log out and back in, and you're finished. 

HAPPY CAPTURING

Choose Your Password (Language) With Care

When you want to use words / sentences in a password, it pays to use a non-English dictionary. Just check the Kaspersky blog on strong passwords., and try it for yourself.

View fullsize

The English word combination 'horse' and 'toad' are considered weaker than the Dutch equivalent ('paard' and 'pad'). 

View fullsize

View fullsize