forkb0mb.org

The nerd-net

nospam@example.com (TJE) — Fri, 03 Feb 2012 18:58:19 -0500

The nerd-net

Notice:

I do not yet have all of the hardware and networking gear set up on my network; so this is merely a description of what I'm looking to do, to gather some ideas and feedback, and then figure out how to proceed. If, after reading the details below, you want to join, or have suggestions, please let me know!

History / Ideas

I've been thinking about starting a "nerd net" for quite some time. I have many friends that use a Linux/*BSD machine at their border, and typically have some kind of services running inside the network. I'd like to link these networks together and share access to services. This opens up all kinds of possibilities...

Network

To avoid a single point of failure, and saturation of any one network's bandwidth, we would avoid linking in a hub-and-spoke fashion. Instead, I propose that we maintain a list of active nodes (essentially, each person's gateway box) and try to maintain at least 3 active VPN connections at a time. In other words, each node on the network would have a VPN tunnel to at least 3 other nodes. It would be very useful to have control of a DNS zone for maintaining this list. Each node would have it's own A record; say, mynode.domain.com. Each time a node wants to connect to the network, it would request the A record for something like connect.domain.com, which would hand out A records of each of the registered nodes in a round-robin fashion.

Authentication will be central in this; so some knowledge of SSL will be beneficial. I, and possibly a few key others, would maintain access to a CA signing key and the nodes would be authenticated to the network via certificates signed by that CA key. Any node that you attempt to connect to should trust you based on that certificate; and, based on the certificate presented, you should trust any connection attempt with a valid, signed certificate. I, and possibly others, can assist with any certificate-based configuration issues that you might have.

Routing

To allow for a private network that's going to be potentially changing topology on a regular basis, we'll need a routing protocol, such as RIPv2. For simplicity, each network would receive it's own /24 of RFC1918 space, with the gateway box running the VPN software being the "node" on the network. Most likely, you'd want to set up split-tunneling on the gateway box so that any requests going to the private network route over the VPN and the rest of your traffic (web surfing, email, etc) goes out your normal internet connection.

With each node on the network being connected to at least 3 other nodes at any given time, that requires us to keep track of the various routes from one network to another. Instead of trying to keep track of this by hand, we could easily set up RIPv2 and announce the routes we "know". I imagine using netblocks in the 172.16.0.0/12 range, with each network having a /24 and being multi-homed (connected to 3+ other nodes), there could potentially be several routes from one network to the other. A light-weight, distance-vector routing protocol like RIPv2 seems to be a good fit; open-source implementations, simple, and proven. The route to any network from yours would be the one with the least intermittent hops.

Another, more complex, possibility would be using OSPF and OpenBSD's open-source implementation. Given that each node will have different bandwidth, this may be a good idea to try.

Services and other ideas

This would be the whole reason for the network!

I would be interested in providing several services to the network, but not publicly. For one, a Linux- or FreeBSD-based shell server with access to the internet, compilers/development tools, documentation, email (anyone remember pine+procmail?), etc. A (small-ish) public web space to let people know that you're part of the network; something like Apache's mod_userdir. A blog application accessible only from within the nerd-net.

I would also maintain the internal network's intranet site. This could be a site used to post updates of system maintenance, new services being offered/tested, and a way to maintain an up-to-date list of all of the nodes.

A private IRC server is definitely on the TODO list. Any and all bots would be allowed; if anyone would be interested in linking the IRC daemons, I'll likely be using the Blackened or UltimateIRCd.

I could provide SMTP services for the network. If we find a zone to use, I can provide email services for that zone. Technically, unlimited user@zone email addresses. I would also be willing to host DNS services for the internal network; providing dynamic DNS and a "view" for those coming in via the network.

Another service I'd consider offering would be your own PostgreSQL database for development and testing. A big part of what I envision for this network is that it'll be a big collection of computer-savvy geeks; what better place to deploy and test code than on a network inhabited solely by those with the clue to help you in debugging, vuln testing, etc.

Other possibilities include shared-CPU time using tools like distcc(1). Maybe remote storage (NFS/iSCSI)?

Requirements

a public IP address to allow for incoming VPN connection requests

a Unix-like machine (Linux, Solaris, *BSD, MacOS/X)

OpenSWAN, FreeSWAN, OpenVPN, etc for creating the VPN

Zebra for RIPv2, OpenBSD OpenOSPFd for routing

Benefits

The benefits of a private network are many, and extend beyond just the sharing of services. This is a chance to build a real-world, potentially large-scale network with changing topology. Any member wishing to add/configure new services or features is welcomed to; and the services could be advertised/listed on the internal network's intranet site.

Other benefits include the ability to policy-route certain traffic. For instance, I would be interested in routing my DNS traffic over the VPN to be routed out someone else's connection; it's low traffic, but my ISP mangles my DNS traffic to route to their servers regardless of what server I point to. Such configuration could even be set up where my DNS traffic goes out through a different VPN's node each time (i.e., a type of load-balancing).

Responsibilities

As the network uses a VPN to set up, exactly what it is, a Virtual Private Network, we should seek to keep the network private. Configuring an Apache reverse-proxy, or some type of port-forward from your external IP address into the network would be frowned upon. Any need to create such accesses for the outside should be discussed with the entire group, and hopefully some sort of consensus reached.

It would also be the responsibility of each node's owner to keep the machine secure and up-to-date. Any breach of one of the nodes would lead to an open route to the network.

Users/Networks

I will create the CA key used to sign all certificates used to access the VPN; but, as I do not wish to be the sole decider in who is allowed on the network and who is not, I plan to create a handful of sub-CA certificates to be distributed to trusted associates who may also sign certificates for potential users. If you've been given a sub-CA certificate, you're being trusted to know who you're letting into our private little clubhouse. :) Using multiple sub-CA certificates will also allow for anyone to validate who provided access for this particular user/network; and the ability to revoke access as necessary (hoping that it wouldn't ever become necessary).

Conclusion

A "nerd net" would be a fun project to gather a bunch of us geeks together and share services. This is the first time I'm really throwing the idea out there (beyond mentioning it to a few people here and there), so if anyone else thinks it would be fun, get ahold of me!

PostgreSQL 9.1 Released

nospam@example.com (TJE) — Fri, 16 Sep 2011 22:40:27 -0400

PostgreSQL 9.1 Released

/*
Among the many new features, here's a snippet from the News page:
*/

Advancing the State of the Art
Our community of contributors innovates with cutting-edge features. Version 9.1 includes several which are new to the database industry, such as:

K-Nearest-Neighbor Indexing: index on "distance" for faster location and text-search queries

Serializable Snapshot Isolation: keeps concurrent transactions consistent without blocking, using "true serializability"

Writeable Common Table Expressions: execute complex multi-stage data updates in a single query

Security-Enhanced Postgres: deploy military-grade security and Mandatory Access Control

/*
The SE-Postgres looks to be particularly interesting. It allows you to use SELinux Mandatory Access Controls on the PostgreSQL users and data. Neat. Particularly the SECURITY LABEL.
*/

/*
Beware, however, that there are some incompatibilities with previous releases!

From the 9.1 Release Notes:
*/

Change the default value of standard_conforming_strings to on (Robert Haas)

By default, backslashes are now ordinary characters in string literals, not escape characters. This change removes a long-standing incompatibility with the SQL standard. escape_string_warning has produced warnings about this usage for years. E'' strings are the proper way to embed backslash escapes in strings and are unaffected by this change.

/*
Also from the Release Notes, it mentions the addition of synchronous replication.
*/

PostgreSQL streaming replication is asynchronous by default. If the primary server crashes then some transactions that were committed may not have been replicated to the standby server, causing data loss. The amount of data loss is proportional to the replication delay at the time of failover.

Synchronous replication offers the ability to confirm that all changes made by a transaction have been transferred to one synchronous standby server. This extends the standard level of durability offered by a transaction commit. This level of protection is referred to as 2-safe replication in computer science theory.

When requesting synchronous replication, each commit of a write transaction will wait until confirmation is received that the commit has been written to the transaction log on disk of both the primary and standby server. The only possibility that data can be lost is if both the primary and the standby suffer crashes at the same time. [...] ...it also necessarily increases the response time for the requesting transaction. The minimum wait time is the roundtrip time between primary to standby.

/*
There's also a What's New in PostgreSQL 9.1 wiki page that explains much of these new features in detail.
*/

CRTC Tells Rogers to Stop Slowing Down the Speed of Online Games

nospam@example.com (TJE) — Fri, 16 Sep 2011 21:56:41 -0400

CRTC Tells Rogers to Stop Slowing Down the Speed of Online Games

Canada's telecommunications regulator on Friday gave Rogers Communications Inc., mere days to come up with a plan to solve a problem that could be unfairly slowing down the speed of online games.

[...]

Rogers now has until Sept. 27 to present a plan to the regulator to deal with the issue.

[...]

While Internet service providers have said they need to manage online traffic to deal with network congestion during peak hours, the CRTC has instituted a policy stipulating that the noticeable degradation of time-sensitive Internet traffic requires prior commission approval under Canada's Telecommunications Act.

/*
Emphasis is my own. This is my entire point:

If they're having bandwidth issues during peak-usage, then they are over-subscribing their bandwith ( and/or maxing out the capabilities of their network infrastructure ) and customers notice. Customers also tend to vote with their dollars.
*/

Opa

nospam@example.com (TJE) — Sun, 28 Aug 2011 00:34:01 -0400

Opa

Opa is a new member in the family of languages aiming to make web programming transparent by automatically generating client-side Javascript and handling communication and session control. Opa is written in OCaml. A hierarchical database and web server are integrated with the language. The distribution model is based on a notion of a session, a construct roughly comparable to process definitions in the join-calculus or to concurrent objects in a number of formalisms.

A good place to start is here. And here you can find several example programs with accompanying source code.

/*
This looks interesting. Although I don't know OCaml, it might be worth learning it to use this. The automatic creation of the client-side JavaScript for maintaining sessions and communication sounds pretty slick.

Here is the link to the documentation, which looks to be pretty decent.
*/

Coordinated ATM Heist Nets Thieves $13M

nospam@example.com (TJE) — Sat, 27 Aug 2011 23:42:18 -0400

Coordinated ATM Heist Nets Thieves $13M

An international cybercrime gang stole $13 million from a Florida-based financial institution earlier this year, by executing a highly-coordinated heist in which thieves used ATMs around the globe to cash out stolen prepaid debit cards, KrebsOnSecurity has learned.

Jacksonville based Fidelity National Information Services Inc. (FIS) bills itself as the world’s largest processor of prepaid debit cards; FIS claims to process more than 775 million transactions annually. The company disclosed the breach in its first quarter earnings statement issued May 3, 2011. But details of the attack remained shrouded in secrecy as the FBI and forensic investigators probed one of the biggest and most complex banking heists of its kind.

/*
Ed. Note: Emphasis and links are from original article.

This sounds a lot like the attack on RBS WorldPay back in 2008. What I can't seem to figure is how they increase/remove the daily withdrawal limits.
*/

FIS said it had incurred a loss of approximately $13 million related to unauthorized activities involving one client and 22 prepaid cards on its Sunrise, Fla. based eFunds Prepaid Solutions, formerly WildCard Systems Inc., which was acquired by FIS in 2007.

FIS stated: “The Company has identified that 7,170 prepaid accounts may have been at risk and that three individual cardholders’ non-public information may have been disclosed as a result of the unauthorized activities. FIS worked with the impacted clients to take appropriate action, including blocking and reissuing cards for the affected accounts. The Company has taken steps to further enhance security and continues to work with Federal law enforcement officials on this matter.” The disclosure was scarcely noted by news media.

/*
So, approximately $13,000,000 on 22 cards. That works out to over $590,000 per card.
*/

Apparently, the crooks were able to drastically increase or eliminate the withdrawal limits for 22 prepaid cards that they had obtained. The fraudsters then cloned the prepaid cards, and distributed them to co-conspirators in several major cities across Europe, Russia and Ukraine.

Sources say the thieves waited until the close of business in the United States on Saturday, March 5, 2011, to launch their attack. Working into Sunday evening, conspirators in Greece, Russia, Spain, Sweden, Ukraine and the United Kingdom used the cloned cards to withdraw cash from dozens of ATMs. Armed with unauthorized access to FIS’s card platform, the crooks were able to reload the cards remotely when the cash withdrawals brought their balances close to zero.

/*
This explains how they were able to pull this off in such a short amount of time. With cloned cards in at least 6 different countries, the totals could add up rather quickly. It appears that they obtained the cash over about 36 hours.

$13,000,000 / 36 hours = $361,111/hour
*/

It’s still not clear who was responsible for this attack on FIS. The company declined comment. The FBI would neither confirm nor deny that it is investigating. But the breach is eerily similar to an intricate 2008 attack against RBS WorldPay, an Atlanta-based unit of the Royal Bank of Scotland. In that heist, crooks obtained remote access to RBS’s systems and used 44 counterfeit prepaid cards to withdraw more than $9 million from at least 2,100 ATM terminals in 280 cities worldwide. The attack was so sophisticated and alarming that President Obama referred to it in a landmark cybersecurity speech.

/*
Considering that these "cloned" cards have to be inserted into an ATM to obtain cash, I would figure that there are ATM images of the (guilty) people withdrawing money. It's likely only a matter of time before some/all of these guys are identified.
*/

How Linux mastered Wall Street

nospam@example.com (TJE) — Tue, 16 Aug 2011 23:06:09 -0400

How Linux mastered Wall Street

When it comes to the fast-moving business of trading stocks, bonds and derivatives, the world's financial exchanges are finding an ally in Linux, at least according to one Linux kernel developer working in that industry.

...

As an alternative to traditional Unix, Linux has become a dominant player in finance, thanks to the operating-system kernel's ability to pass messages very quickly, Lameter said in an interview with IDG. In fact, the emerging field of high-frequency trading (HFT) would not be possible without the open-source operating system, he argued. Lameter himself was hired as a consultant by one exchange -- he won't say which one -- based on his work in assembling large-scale Linux clusters.

/*
An interesting read regarding the use of Linux in high-frequency trading applications.
*/

Survey: Most Enterprises Will be on IPv6 by 2013

nospam@example.com (TJE) — Thu, 28 Jul 2011 12:21:02 -0400

Survey: Most Enterprises Will be on IPv6 by 2013

IT professionals overwhelmingly say they want their companies to be leaders not laggards in IPv6 adoption, Network World survey finds.

/*
Warning: This article contains a slideshow.

Otherwise, it's pretty interesting to see how important IPv6 adoption has become in the networking world now that it's starting to sink-in that IPv4-space is quickly dwindling. See here. The last /8's were allocated in early February 2011.
*/

Tunneling nmap through Tor

nospam@example.com (TJE) — Thu, 28 Jul 2011 12:11:34 -0400

Tunneling nmap through Tor

I looked at how to reduce your exposure using Tor earlier in the week. We installed Tor and Privoxy and configured our system to browse the Internet anonymously. We can use Tor and another great program called proxychains to Torify our network scans with nmap.

/*
I checked this out and it seems to work well. Other than the fact that Tor doesn't seem to carry UDP traffic (other than DNS) or ICMP traffic, you're limited to TCP traffic alone, which isn't too much of a limitation.

It is a little slow getting your scan results back - especially if you don't pass -p<port1>,<port2> to nmap(1), but it's certainly more secure than just trying to use an open proxy server out on the 'net.

All in all, a neat trick.
*/

AppleCrate II

nospam@example.com (TJE) — Wed, 04 May 2011 17:26:50 -0400

AppleCrate II: A New Apple II-Based Parallel Computer

The AppleCrate II is made from 17 Enhanced Apple //e main boards. (Fifteen of these boards were obtained in the same eBay auction that netted the eight unenhanced boards for the original AppleCrate.) Because they are enhanced ROMs, the original NadaNet boot ROM code would not fit and a new boot protocol had to be developed, as described below.

Instead of mounting the cards vertically in a frame, as in the original, I decided to mount them horizontally in a stack secured with standoffs—3/4" long hexagonal rods, each with a screw protruding from one end and a tapped hole in the other. The AppleCrate II has nine "columns" of these standoffs—six metal columns at the back and corners of the boards and three nylon columns interior to the boards to add stiffness[...]

/*
This has got to be one of the coolest hacks I've seen in a very long time. I will always have a fondness for the Apple II series; not the least of which because it's based on the MOS Technologies 6502 microprocessor.

It's well worth hitting the link just to see a picture of this rig. It's really cool looking.
*/

The boards are powered by a PC AT power supply. The average power consumed by an Apple //e board is about 4.2 watts, so the whole 17-board crate consumes only about 70 watts in total, and both the AppleCrate and the power supply run only a few degrees above ambient temperature.

Ubuntu SecurityTeam/Roadmap/KernelHardening

nospam@example.com (TJE) — Tue, 05 Apr 2011 00:01:30 -0400

Ubuntu SecurityTeam/Roadmap/KernelHardening

There are several kernel hardening features that have appeared in other hardened operating systems that would improve the security of Ubuntu, and Linux in general. They have been controversial, so this page attempts to describe them, including their controversy and discussion over the years, so as much information is available to make an educated decision about potential implementations.

/*
This page describes various means of securing the Linux kernel on Ubuntu Linux systems. This includes symlink protection; ptrace protection; and NX emulation, among others.
*/

Two /8s allocated to APNIC from IANA

nospam@example.com (TJE) — Thu, 10 Feb 2011 08:26:53 -0500

Two /8s allocated to APNIC from IANA

APNIC received the following IPv4 address blocks from IANA in February 2011 and will be making allocations from these ranges in the near future:

39/8

106/8

/*
The allocation of these blocks left the IANA with 5 /8 blocks left; which triggers a clause saying that when the pool gets down to 5 remaining blocks, each of the 5 *NICs get one of the remaining blocks. It's just unfortunate that 2 of the last 6 or 7 blocks are completely wasted by being routed to what essentially amounts to an Internet cesspool (APNIC). I regularly pull down the IANA assignments, parse out the netblocks assigned to APNIC, and then null-route them all.

Note: The aforementioned clause is stated in the "Global policy for the allocation of the remaining IPv4 address space."

*/

/*
Here's a ticker, from Hurricane Electric, that estimates the eventual exhaustion of IPv4 addresses from the regional registries.

You might take this time to register for a block of IPv6 addresses - It's free!

*/

Common Threads: OpenSSH Key Management, part One

nospam@example.com (TJE) — Sun, 16 Jan 2011 16:03:46 -0500

Common Threads: OpenSSH Key Management, part One

Many of us use the excellent OpenSSH [...] as a secure, encrypted replacement for the venerable telnet and rsh commands. One of OpenSSH's more intriguing features is its ability to authenticate users using the RSA and DSA authentication protocols, which are based on a pair of complementary numerical keys. As one of its main appeals, RSA and DSA authentication promise the capability of establishing connections to remote systems without supplying a password. While this is appealing, new OpenSSH users often configure RSA/DSA the quick and dirty way, resulting in passwordless logins, but opening up a big security hole in the process.

/*
Yet another of the DeveloperWorks! series. I love these articles.

The vulnerability in question has to do with pub-key (RSA/DSA) authentication and leaving a null/blank passphrase on the keypair. This article describes how to configure ssh-agent to cache the decrypted private keys so you only have to type the passphrase once per session. This has the benefit of allowing you to use scripted SSH logins without being prompted for a password, but also means that the keypair is still relatively secure even if someone else manages to compromise them via the filesystem.
*/

OpenSSH's RSA and DSA authentication protocols are based on a pair of specially generated cryptographic keys, called the private key and the public key. The advantage of using these key-based authentication systems is that in many cases, it's possible to establish secure connections without having to manually type in a password.

While the key-based authentication protocols are relatively secure, problems arise when users take certain shortcuts in the name of convenience, without fully understanding their security implications. In this article, we'll take a good look at how to correctly use RSA and DSA authentication protocols without exposing ourselves to any unnecessary security risks. In my next article, I'll show you how to use ssh-agent to cache decrypted private keys, and introduce keychain, an ssh-agent front-end that offers a number of convenience advantages without sacrificing security.

/*
A more in-depth description of what I mentioned above.

Highlights include:

What is RSA/DSA authentication?

How RSA/DSA keys work

Two observations

ssh-keygen up close

The quick compromise

RSA key pair generation

RSA public key install

DSA key generation

DSA public key install

For those already familiar with ssh-agent(1) - which you should be - then you can skip ahead to Part Two and Part Three.
*/

Linux Software RAID 1 Setup

nospam@example.com (TJE) — Sun, 31 Oct 2010 06:27:03 -0400

Linux Software RAID 1 Setup

/*
This is the article I used in creating my 2-device (2 x 250 GB SATA) RAID1 in my desktop.

The documentation is fairly straight-forward and easy to follow. One thing this article assumes is that you're going to boot off a soft-RAID. This was not the case in my scenario; I just wanted a redundant storage slice.

Now, to enable crypto on the slice.
*/

Much Ado About NULL: Exploiting a Kernel NULL Dereference

nospam@example.com (TJE) — Thu, 17 Jun 2010 23:11:53 -0400

Much Ado About NULL: Exploiting a Kernel NULL Dereference

Last time, we took a brief look at virtual memory and what a NULL pointer really means, as well as how we can use the mmap(2) function to map the NULL page so that we can safely use a NULL pointer. We think that it’s important for developers and system administrators to be more knowledgeable about the attacks that black hats regularly use to take control of systems, and so, today, we’re going to start from where we left off and go all the way to a working exploit for a NULL pointer dereference in a toy kernel module.

/*
The article then goes on to provide a hand's on example of how to exploit a NULL pointer dereference to execute arbitrary code. Pretty good read.
*/

Secret Forum Reveals Oz Firewall Backroom Dealing

nospam@example.com (TJE) — Mon, 17 May 2010 00:56:52 -0400

Secret Forum Reveals Oz Firewall Backroom Dealing

Circumvention legal, but you can't tell anyone how[.]

/*
Emphasis is theirs.

Now say what? It will be legal to circumvent (technical details at the bottom), but illegal to explain to someone else how to perform this perfectly legal configuration. I wonder how this might affect a corporate or ISP helpdesk perform VPN connectivity setup?
*/

Australia’s plans for a firewall to protect its population from smut on the internet are rapidly evolving from farce to total chaos. Weekly revelations on bulletin boards suggest that Stephen Conroy, the man behind the big idea, does not know what forthcoming legislation on the topic will say, when it will be introduced or how the firewall will work in practice.

/*
This time, emphasis is mine. I want to continue to point out how big of an asshat this particular Australian politician is. He is the "Minister for Broadband, Communications and the Digital Economy." He's the one that floated the idea of this nation-wide "firewall" (which is technically a proxy since it will be filtering at layer 7 - hence the technical problems) to "protect" citizens from illegal, immoral, or "dangerous" content. This is nearly the same thing the Chinese and Iranians are doing, just using layer 7 proxy devices instead of what's assumed to be basic layer 3 IP filtering of destination hosts. Skip to the very end of the post for the technical details behind this.

To say this whole thing began as a farce is hitting the nail right on the head.
*/

Meanwhile, it turns out that the Minister’s own Department of Broadband, Communications and the Digital Economy (DBCDE) has been hosting a secret forum for discussions with ISPs likely to be affected by proposals. Along the way it floated the idea of making it a crime to advise surfers on how to do things that are perfectly legal to do. Confused? You will be.

First up is the time scale for plans to introduce the new firewall. As already reported, the question of when legislation will be introduced has now been bouncing between the offices of Prime Minister Kevin Rudd and Communications Minister Stephen Conroy. Severe wriggling from Conroy’s office suggests that plans for an early introduction of legislation have been put on the back burner for now.

/*
Conroy wants to shelve the legislation until after the elections. He's technically incompetent, but he's smart enough to realize that this is going to be a screw-up of biblical proportions and it will likely cost him the election. It's "on the back burner for now," but it's by no means dead.
*/

Meanwhile further digging inside this forum revealed that departmental officials appear to have been discussing the possibility of making it a criminal offen[s]e to advise individuals of means that would enable them to circumvent the filter – even where the means themselves were perfectly legal.

/*
I would say that this equates to information being illegal. In a way, that's in the same league as banning books.
*/

As the EFA suggests, this answer raises more issues than it addresses, and relies on the degradation of the Australian network being gradual, rather than catastrophic. It does appear, however, that the government has no plans to deal with a possible overload of its firewall bringing the Australian internet to its knees – beyond setting up a review when such an event actually happens.

/*
Why should there be any degradation of bandwidth at all? I suspect that if this goes through, there's going to be a noticeable difference in download speeds and initial access to websites.
*/

/*
Details:

Circumvention:
Circumvention of these filters will be trivial; you can wrap your request in SSL (such as https:// if the website supports it), by using a VPN provider outside Australia (many more found on the link for the word "using"), by using Tor (which uses a technique known as Onion Routing), or even by viewing blocked pages via the Google cache.

Technical Considerations:
This filtering is to take place with proxies (at the Application [7] layer) as opposed to the traditional large-scale deployments of firewalls (at the Network [3] and Transport [4]) layers). The deeper you have to inspect a packet, the more CPU and memory required to process the filters. It costs - in many ways, from actual dollars for the hardware and software, to performance impact, to configuration complexity to man-hours of maintenance - considerably more to filter at layer 7 with a proxy than layers 3/4 with a firewall.

The one benefit to filtering at layer 7 is that you block only what is intended to be blocked. In today's world (where we've been running out of IPv4 space for a dacade now) a lot of websites are configured using virtual hosts. This allows web hosting providers to host a virtually unlimited number of websites on a single IP address. Let's say there are two websites, both hosted on the same virtual host IP address, where one is banned and the other is not:

www.bannedwebsite.co.au (banned)
www.momsrecipies.co.au (allowed)

With a layer 7 proxy, when the user attempts to reach a website, the proxy intercepts the request, checks the request (including hostname and URI), and then either blocks the request, or requests the page on behalf of the end-user and returns her the requested webpage. So your mom can still access www.momsrecipes.co.au while nobody can access www.bannedwebsite.co.au. With a proxy, you can return HTML to the end-user explaining why access to this particular website is blocked and possibly a method of contact to dispute the denial of access.

Pros:
() Finer-grained control of what's filtered
() Less "false positives"
Cons:
() Expensive in many aspects (mentioned above)
() Complex configuration
() Considerable service impact due to use of DPI at Application [7] layer
() Slightly easier to circumvent; using https is the only circumvention measure mentioned that does not tend to work with the firewall approach - the rest should work against both types

With a layer 3/4 firewall, access to the virtual host IP address (or even the subnet it's part of) will be blocked. When anyone tries to go to www.bannedwebsite.co.au, they are unable to, which is the intended result. They will get a different error; the browser will just report that website was unreachable. End of explanation. If anyone tries to go to www.momsrecipies.co.au, they will also be denied with the same uninformative unreachable error. Since both websites are on the same IP address, the firewall has no way of knowing which website you're looking for, so it blocks everything.

Pros:
() Cheaper to deploy
() Simpler configuration - hundreds of hosts/subnets vs. thousands of hostnames
() Can often be implemented on existing hardware - edge or core routers utilization IP ACLs
() Faster, more responsive access to allowed websites; less service impact
Cons:
() Collateral damage - legitimate sites on the same virtual host as banned site are also blocked
() Slightly more difficult to circumvent (a websites https site will likely be in the same blocked subnet)

Comparison with Other Instances of State-Controlled Internet Access:
I see three major differences in the Australian proposal as opposed to the other major regimes implementing state-wide filtering of websites (China and Iran). They are as follows:

The use of layer 7 proxies instead of layer 3/4 firewalls and route filtering

In China and Iran the responsibility of implementing and maintaining the filters rests on the tier-1 to tier-2 network providers who bring capacity into the country. By filtering at this level, you are enforcing that ISPs block these sites along with everyone else in the country. By placing the responsibility on the ISP, who provides the access to the end-user, you are going to find that ISPs (a) will add/remove entries from the blocked list to fit their own agendas; (b) will suffer varying performance impact and quality of service based on their investment in the filtering technology and correctness of the implementation; (c) will raise prices to pay for increased hardware/software components, man-hours maintaining the systems, and extra capacity required to maintain a reasonable quality of service; and (d) some will become popular with a certain customer base due to being lax in their filter list updates and tendency to allow some banned content.

Another side effect of this proposal, from an economic standpoint, is that it is likely to put smaller ISPs out of business. Instead of putting the smaller burden on the backbone providers, with considerably more capital, it will place a more expensive burden on ISPs with less resources at their disposal. If these filters become legally mandatory, this will likely put smaller ISPs out of business. A smaller provider may not have access to the resources (money, manpower, and know-how) to meet these requirements and will thus have to shut down operations.

The third difference is in the legality and enforcement of the filters. In the Australian proposal, it will be legal to circumvent the filters provided you know how. In China, they are known for randomly allowing then blocking then allowing access to certain websites and enforcement is relatively low. Occasionally they will decide to make an example of someone, and they will end up in prison. In Iran, enforcement is rather strong, with penalties ranging from prison time to possibly "disappearing".

Other Thoughts:
There is one other somewhat commonly used filtering technique involving DNS. The ISP or corporate gateway will transparently route all DNS requests by the end-user to DNS servers under their control. The DNS servers will be configured as authoritative for the blocked domains; typically configured to return an IP address that connects you to a website telling you that your access is blocked and possibly why. This is similar to the Walled Garden approach.

*/