The six dumbest ways to secure a wireless LAN

Summary: [Updated 4/2/2007 – follow-up article here] For the last three years, I’ve been meaning to put to rest once and for all the urban legends and myths on wireless LAN security. Every time I write an article or blog on wireless LAN security, someone has to come along and regurgitate one of these myths. If […]

via The six dumbest ways to secure a wireless LAN | ZDNet.

pfSense Open Source Firewall Distribution

pfSense Open Source Firewall Distribution – Home.

pfSense is a free, open source customized distribution of FreeBSD tailored for use as a firewall and router. In addition to being a powerful, flexible firewalling and routing platform, it includes a long list of related features and a package system allowing further expandability without adding bloat and potential security vulnerabilities to the base distribution. pfSense is a popular project with more than 1 million downloads since its inception, and proven in countless installations ranging from small home networks protecting a PC and an Xbox to large corporations, universities and other organizations protecting thousands of network devices.

BIND 9.7.2 and automatic DNSSEC signing

BIND 9.7.0 introduced automatic in-server signature re-freshing and automatic key rollover. This allows BIND 9.7, if provided with the DNSSEC private key files, to sign records as they are added to the zone, or as the signatures need to be refreshed. This refresh happens periodically to spread out the load on the server and to even out zone transfer load.

via BIND 9.7.2 and automatic DNSSEC signing | Internet Systems Consortium.

Knock Knock Knockin’ on Bridges’ Doors

In October 2011, ticket #4185 was filed in the Tor bug tracker by a user in China who found that their connections to US-based Tor bridge relays were being regularly cut off after a very short period of time. At the time we performed some basic experimentation and discovered that Chinese IPs (presumably at the behest of the Great Firewall of China, or GFW) would reach out to the US-based bridge and connect to it shortly after the Tor user in China connected, and, if successful, shortly thereafter the connection would be blocked by the GFW. There wasn’t time for a detailed investigation and analysis at the time, but that kernel eventually grew into the investigation detailed below. We were, however, able to determine that limiting connections to the bridge relay to only the single IP expected to be its client would, in fact, block the probes and allow the connection to remain open for an extended period (>48 hours in our testing).

via Knock Knock Knockin’ on Bridges’ Doors | The Tor Blog.

How the Great Firewall of China Blocks Tor

Wilde was able to find that the method the firewall was using to identify which sessions to go after had something to do with the list of SSL ciphers contained in the SSL packet the client sends at the beginning of a session. By changing that list, he was able to evade the blocking of the Chinese firewall. More long-term solutions are in the works, as well, including password protection for bridge relays and the establishment of another layer on top of the session that simply looks like binary data.

via How the Great Firewall of China Blocks Tor | threatpost.