Know  your  rights!

The study was performed by William Press, who does bioinformatics research at the University of Texas, Austin, with a joint appointment at Los Alamos National Labs. His background in statistics is apparent in his ability to handle various mathematical formulae with aplomb, but he’s apparently used to explaining his work to biologists, since the descriptions that surround those formulae make the general outlines of the paper fairly accessible.

Press starts by examining what could be viewed as an idealized situation, at least from the screening perspective: a single perpetrator living under an authoritarian government that has perfect records on its citizens. Applying a profile to those records should allow the government to rank those citizens in order of risk, and it can screen them one-by-one until it identifies the actual perpetrator. Those circumstances lead to a pretty rapid screening process, and they can be generalized out to a situation where there are multiple likely perpetrators.

Things go rapidly sour for this system, however, as soon as you have an imperfect profile. In that case, which is more likely to reflect reality, there’s a finite chance that the screening process misses a likely security risk. Since it works its way through the list of individuals iteratively, it never goes back to rescreen someone that’s made it through the first pass. The impact of this flaw grows rapidly as the ability to accurately match the profile to the data available on an individual gets worse. Since we’ve already said that making a profile is challenging, and we know that even authoritarian governments don’t have perfect information on their citizens, this system is probably worse than random screening in the real world.

Many say racial profiling is just another form of racism, but is it an effect of the TSA in picking out possible suspects, or a reflection on what our society sees as a threat? Either way, just as our not being able to take a big bottle of shampoo on a plane, it’s not making us any safer.

IPv6 is ready?

Tonight I did ran netstat (`netstat -plunt`) on my Debian server and saw that I had some ports listening via IPv6.  It’s a shame IPv6 hasn’t caught on as it’s better than IPv4 in virtually every way, and it should, especially since TCP/IPv4 was standardized in ARPANET RFC’s… in 1981!  Also, IPv6 provides network level security via IPSec, which enables authentication of sender and encryption of communication path, to secure communications, all fun stuff, but while some point to the fact that the Beijing Olympics used IPv6 exclusively as a point in how far it’s come, that’s hardly saying much when the protocol went Alpha… in 1996!  I mean I put things off and get distracted, sure, but come on!  So while its adoption can be argued to be a case of the chicken before the egg, since I’m not using anything IPv6, nor do I or my ISP even have the capability to use it, it’s silly and perhaps dangerous to leave it running with open ports.  So, if you’re not using it, disable it – it’s easy, just put on your pointy hat and follow along… First we need to edit:

/etc/modprobe.d/aliases

By default you will have a line like this:

alias net-pf-10 ipv6

Replace that line with:

alias net-pf-10 off
alias ipv6 off

(The second line may/may not be required with newer (2.26.+) kernels, but it won’t hurt anything)

Also, while we’re at it, on your desktop machines, help out Firefox by disabling IPv6 there too.  It’s simple, in the location bar enter:

about:config

Then search for:

network.dns.disableIPv6

and toggle its value to ‘true‘

Well, that’s it, you’re now surfing with 1980s technology (just like 99.098% of the internet!)

This is great, Defcon16 is a mere few days away, but already, the drama has started! Of course there’s the excitement about security guru/celebrity Dan Kaminsky discovering the DNS flaw a few months back that will be revealed this week (so that folks won’t be able to reverse-engineer them to exploit the vulnerability…ahead of time at least), but now there’s a reneg by Apple that’s sure to raise a few feathers, as well as highlight how they weren’t the most forthcoming with their DNS fix (which hasn’t hit yet even though all other vendors have released patches). In an interview, Kaminsky talks about the ‘bug’ he found in DNS, “We got lucky in this particular bug, because it’s a design flaw,” Kaminsky said in an interview. “It shows up in everyone’s network, but the fix is a design fix that doesn’t point directly at what we’re improving.” After peer review it was deemed this was indeed a huge deal, and even the original developer of BIND (the dns software in question) urged everyone to patch. “It took a couple of hours to find the bug,” said Kaminsky, “and a couple of months to fix it.” Kaminsky said he stumbled across the hole in the so-called DNS system for steering people to the websites they are seeking “by complete and total accident.” Smaller DNS flaws have been used before to “poison” the servers that send people to the numerical address of the website name they enter. [...] “This is about the integrity of the Web, this is about the integrity of e-mail,” Kaminsky said. “It’s more, but I can’t talk about how much more.” So learning more about that exploit will be very interesting, and should lead to more people investigating and deploying DNSSEC, a DNS option built with security in mind from the ground up. So there’s that, but now there’s something even more fun because it deals with a companies lack of openness in regards to their security methods. A talk at Black Hat yesterday was scrubbed at the last minute by folks over in marketing at Apple. It seems that they blocked the scheduled presentation that was, “…to give an inside look at the ultra-secretive company’s security response team. “Marketing got wind of it, and nobody at Apple is ever allowed to speak publicly about anything without marketing approval,” a Black Hat organizer told IDG News.” This is unfortunate for Apple, who are reeling after a week of beatings in the ‘blogosphere’ over their handling, or non-handling, of their update for the DNS flaw we mentioned above! “Apple’s policy of saying next to nothing about how it goes about protecting its users from escalating threats is, to say the least, unfortunate. Just last week, the company said it had patched its software from a serious flaw in the net’s address lookup system. Three days after two separate researchers warned Mac clients are still vulnerable to the flaw, Apple hasn’t uttered a word, an omission that generates confusion and doubt in those who depend on the vendor. Apple’s tight-lipped policy.” Come on Apple, you preach about how you’re ‘Open Source’, but then continue along the path of the old school hide and seek ways. Hell, people are already pointing out how their methods are less open than Microsoft’s in releasing information about security. What are they so afraid of? Ah, but we’ll learn more come Thursday, I’ll be in Vegas for my third Defcon and can’t wait. Watch for updates here, or more timely ones over at our Twitter profile.

I’d like to share my thoughts in as to why I think the network is better served with keeping internal traffic and public traffic separate.  Regardless of if you use the existing web proxy server, or another one with different network topology, I care less about the tool, and more about making the network and user experience better for both internal and external users

integrity
First off, my strong feeling is that internal users should *never* be able to effect the performance of production websites (and to a slightly lessor extent vice versa).  Say for example we have a virus that bounces from email to email and sends out spurious requests via the Internet, this hammers our local network which kills the integrity of our production websites.  External users are left with an unusable system, and our integrity suffers.  On the flip side, a PR announcement goes out and traffic to our production sites surges, making not only our production sites slow, but also the local network for users trying to get email and look up things on-line.  Having all of these resources straining the same bandwidth pipe puts other things such as credit card verifications for sales in direct competition with a YouTube video download by an employee.  Sure a packet shaper can set priority for the credit card line, but why even have the competition?  Having these two types of traffic segmented from the start is a must to keep the integrity of our network, and our production running as well as they can without the chance of either one negatively effecting the other.  Additionally this setup cascades down to effect the other following aspects of how our network performs.  They are…

security
I’ve always been of the mindset that by default incoming ports are always set at “deny everything, allow only what is needed”, something that virtually every firewall follows.  For the same reasons this should be the default behavior for any traffic originating here and heading out via the outgoing ports.  As far as I could tell, under the old gateway configuration, everything was allowed out (aside: even some protocols that people on the network side told me were blocked, were simply not) with the new gateway everything outbound was initially denied, and then we only opened things that ‘needed’ to be open.  In doing this we’ve shut down 1000s of ports that could otherwise be available for malicious program to utilize to breach our security from inside.  This is often how malware and viruses communicate their successful infestation and request further instructions.  Additionally, having a web proxy often stops this kind of communication because even a simple HTTP request initiated by the malware will not be configured to transmit through a web proxy; it will be expecting a straight shot out, since that’s far more common.  This is one of the benefits of a traditional proxy over a so called ‘transparent’ proxy where no configuration is needed for the client to communicate externally; with a traditional proxy the malware will not know how it needs to be configured to transmit through the proxy.

bandwidth
A reverse proxy works by checking an HTTP request from a user against a cache of recently requested objects that the proxy stores.  This saves bandwidth since if a stored object (think of a file like a graphic, css, javascript, etc) is found it can be used instead of making another external request and download.  The current web proxy/gateway includes this functionality using the industry standard Squid, with no maintenance required.  It’s simply better utilizing the resources automatically, so its use is a no brain-er here.  If we ultimately drop the web proxy I’m still going to be of the opinion that running a standalone reverse proxy like Squid, or my choice Varnish, would save incoming and outgoing bandwidth on our network.

transparency
While we got into this exercise because the network was slow; it was slow for internal users and slow for external users.  Now it’s fast for internal users, with plenty of headroom to spare, and it will never infringe upon external users.  Any slowness of our sites can now be diagnosed without the concern of unknown network traffic effecting its abilities thus making troubleshooting and managing much simpler.  If we went back to the ‘everyone in the same pool’ setup, we’ll be at the same mercy the next time the network is slow – how will we troubleshoot it then?  Pull the external users onto a new proxy so we can segment them out as a cause of the slowness?  With the network segmented we can already rule out one type of traffic being the cause of slowness.

simplicity
While a web proxy/firewall solution can be complex, the gateway in place is running Smoothwall, a specialized Linux install that is administrated fully through a web user interface.  It’s simple to use and administrate as it is very well documented.  If I were to leave tomorrow I have no reservations that someone in the networking department could pick this up and run with it, no problem.  Other proxy solutions should be considered which could preform the same role with a similar level usability and upkeep.  The point is, we can do complex network configuration to best utilize our resources without having a specialist on hand to administrate it.

conclusion
I’ve installed a solution here that works at improving the network in a myriad of ways, and is doing the job without any day to day maintenance, however I would not be offended if another solution was suggested and used over mine.  My concern is not only for our network performance, but how our presence is perceived externally to the world as far as providing useful, reliable resources for information.

Extra credit for reading all the way to the bottom, and regardless of what decision is made, thanks for allowing me to present my solution, and my rational for it.

If anything, that should be the message to all Internet surfers out there.  This graphic shows the danger, the percentage of users who have their browsers at their most secure, in regards to patches/updates being applied. Clearly people running IE aren’t going through the trouble of updating, while Firefox has updates built in that you can even automate.  Another thing to keep in mind is plugins; Firefox has millions of those, and now it takes care of keeping those updated, and disabling ones that aren’t.  So just from a software security point of view, Firefox is just a no-brainer.  The report concludes with, “Although Web browser users wish perfect software that will never have any exploitable software vulnerabilities, the nearest they can realistically hope for is that any vulnerabilities are promptly fixed by the software vendors and instantly applied to their browser. Critical to this instantaneous patching process is the mechanism of auto-update. Our measurement confirmed that Web browsers which implement an internal autoupdate patching mechanism do much better in terms of faster update adoption rates than those without.”

In the New Hampshire Democratic primary

CNN estimates:

* Hillary Clinton has won 9 New Hampshire delegates (3 statewide, 6 district-level)

* Barack Obama has won 9 New Hampshire delegates (3 statewide, 6 district-level)

* John Edwards has won 4 New Hampshire delegates (2 statewide, 2 district-level)

* 22 Democratic delegates were at stake in the New Hampshire primary

Ok, so it was a tie in regards to the delegates, but Hillary won the popular vote, but wait, what about the ‘superdelegates’ in New Hampshire? Back to the article:

* There are also 8 Democratic “superdelegates” in New Hampshire. Of those, 2 support Clinton and 3 support Obama, according to a CNN survey.

So now it looks like Obama was actually the winner, making the ‘win’ for Hillary seems like an old fashioned PR/spinfest. Even though they’re first, Iowa and New Hampshire are small states, and in the end, 2,025 delegates are needed to secure the nomination. The fact that people seem to be winning and losing at this stage is irresponsible. Ok, so now Obama has won 2 states, but wait, what about the super delegates in Iowa? Oh, I see.