Archive for the ‘DDoS’ Category

The Top 10 Things To Do While Under DDoS Attack

Sunday, January 24th, 2010

In my past decade-plus dealing with distributed denial-of-service attacks, I have noticed a few patterns in the way that companies handle these attacks. Usually when an unprepared virgin company is first attacked, all hell breaks loose. The lack of preparedness causes several chain reactions that make the situation worse. Addressing these most common mistakes ahead of time can help a situation tremendously.

When someone calls me for advice, the first few items I go over have nothing to do with fixing the attack. I’m giving advice that I think is common sense, and I’ve been surprised that others don’t find it obvious.

Here are my Top 10 To-do’s for making life less painful during an attack.

1. Don’t Panic

While the network and your services are exploding and bouncing offline, there must be someone that is comfortable enough to make good decisions. I’ve seen managers freak out and threaten everyone with the prospect of the company collapsing. I think they were trying to motivate people to figure out some solution, but they ended up creating more chaos during an already tough situation.

Once I saw employees hastily rip out the network’s firewalls and re-configure the load balancers. They ended up creating more mess than they had before because they were reacting to an angry and stressed manager.

You are going to create a disaster if you approach with a sledgehammer and wishes. Don’t let anyone make quick changes; try to follow your company’s policies. Sit back, analyze the problem, isolate the actual device that’s failing in the chain, and make an informed–and usually small–adjustment.

If you’re in the 10th hour and things don’t seem to be improving, gather everyone, go away from the office, have a beer, relax for 15 minutes, and talk about something positive. The information flow after that beer might just save you and motivate everyone to do a good job – the solution will come!

2. Create a contact list of external email addresses and phone numbers.

This one is sadistically funny. Most companies host their email, VoIP system, IRC, Wiki, databases, primary storage, etc. all in the same colocation behind the same network connection that hosts their web sites and services. This is, for lack of better words, stupid. All of your digital eggs are in one basket, and that basket is also holding a grenade. A DDoS attack ends up crippling the company’s infrastructure, leaving it with no phones, email, or any communications structure whatsoever.

I’ve seen CEOs of massive companies using their hotmail account and cell phone to contact me because it was their only way of communicating from their multi-million dollar offices.

If you insist on being an “eggs in one basket” company, keep a list of vital email accounts and cell phone numbers on a notepad. That way you can at least call your IT person when everything is down.

3. Setup a “War Room”

Convert your conference room into a war room. Get everyone that has influence in the company in that room. This includes marketing, IT, the CEO, etc. It ensures everyone is on the same page, leaders can lead, and everyone can be in sync.

I typically fill the room with a constant flow of healthy snacks, coffee, and other beverages. If you don’t have anything like that handy, order pizza immediately or send someone shopping.

4. Get one of your guys to the colo ASAP

If you are offline due to DDoS attack, chances are your IT staff cannot log in to the remotely hosted hardware in your datacenters. The easy solution is to physically get them there. They can console in to the hardware and actually see what is going wrong. It’s not fun, but it will result in a much faster resolution to the problem (Make sure they have folding chairs, cash for the vending machines, and serial cables).

5. Find an old hub

Yes, I said hub. You know, those old things that cause collisions? If you’re dealing with an attack and yours is like a lot of companies, it may be difficult for you to set up a traffic monitoring port on your main routers. Assuming you’re setup with Ethernet, at least you can bridge a hub in-line and connect a laptop to the hub and sniff or analyze the traffic!

This is key because having eyes into the data stream really helps figure out how to filter it. Pulling random cables and shutting down random services is not the solution. Make an informed call because you were thoughtful enough to have a hub or SPAN/Mirror port pre-configured.

6. Understand the nature of the attack

There’s a reason you are the target for this attack. Obviously there are a lot of reasons for any given attack, yet understanding the attacker’s motivation is key to creating a better defense strategy.

In the field I have observed a very strange phenomenon; the people working at a victim company usually have a gut feeling about why they are being attacked. So far, their gut instinct has been correct.

Some people know they are being extorted and some people feel it’s a competitor trying to shut them down. Others have a customer that has pissed someone off so the attacker takes down the whole company just to silence one customer. Maybe shutting down the attacker’s target for awhile may actually save the entire ship. Go with your gut on this, make a hypothesis and test it.

7. Document everything

Your business was just smacked around by some bad guys, but what proof do you have? If you don’t have any, then what do you think the law enforcement is going to do for you?

During the attack, lock down all your logs and assign someone within the company to be the custodian of the records. Save server logs, web logs, email logs, any packet capture, network graphs, reports – anything – including a timeline of events.

8. Call your ISP

Your ISP can help, however they have a process to follow. The process usually requires a ticket escalation requirement before you can get real help. If you call early in the attack and open a ticket, that can help you when you really need someone.

Your ISP also has hardware that may be capable of filtering or rate-limiting the attack. The more you know about the attack and you can point them in the right direction, the more they can help you.

They may also suggest you to sign up for their DDoS protection system. Don’t do that right away; reserve that until you are out of all other options. If you do sign up, make sure there is a service level agreement. In the meantime, there are a number of free services you can request:

Null routing of the target IP address
Router ACLs of the top attacking source addresses
New IP addresses
Detailed traffic reports

If you can find the guru at the ISP that knows how to fix these problems, that might be time well spent.

9. Setup “We are down” web hosting services

If the attack is running longer than you had anticipated and you don’t have a solution in sight, you could get your site working at least enough to communicate to your customers.

There are web-hosting companies, which as part of what they do, provide DDoS service level agreements. For a small amount of money you could quickly sign up with several of these companies, upload a “Sorry we’re down, but contact us here” page, and flip your DNS to the cluster of hosted servers.

Your customers will have more confidence in your performance and the attackers may get bored because the attack has not completely shut everything down. If this plan doesn’t work, at least you have diverted some of the attack away from your network.

10. Learn from the event

Post attack can be a blur; everyone is exhausted and burnt out. Mostly, everyone just wants the day-to-day atmosphere to return to status quo. Well, if you’ve been attacked and you did not learn and improve your strategy on how to deal with future attacks, then you are not doing your job.

You should start a review the very day after, while everything is fresh, and make sure that everyone is prepared. Go over what worked, what did not work, and how to improve your system’s overall technology.

Spend the money to fix things properly. Don’t just duct-tape it.

RSA 2010

Tuesday, December 15th, 2009

I’m presenting at RSA 2010 with co-speaker Joseph Menn. We will be talking about the soon-to-publish book Fatal System Error, which covers some of my adventures with Cyber Warfare and cyber-extortionists.

What aspects of the adventure would you find most interesting?

Send me an email with suggestions: blyon [at] blyon.com

More Twitter Woes?

Tuesday, August 11th, 2009

Around noon today, Twitter had some stutters and on their status page they wrote:

We’re working to recover from a site outage and will update as we learn more.

Update (12:17p): We’re back up and analyzing the traffic data to determine the nature of this attack.

I am guessing as time goes on, the attacks to Twitter will be much more targeted. Attackers can update their bots to attack specific user accounts or other process-intensive working parts of Twitter which could create processing bottlenecks within the internal Twitter application itself.

It is very difficult to build large scaling databases, judging by Twitter’s current network design, I would assume their database design would be similar in stature — lack luster.

Rather than just basic attacks to Twitter’s hosting partner NTT, attackers will target the Twitter database/application weak spots via their API or via their web interface. A targeted attack on Twitter’s own application weaknesses would bring more bang for the buck and be more difficult to defend against.

As seen in the image on the left, some evidence of application fail is apparent. Twitter’s web site is doing some odd stuff; at times my followers/following stats and the trending topics applet disappear.

The strange behavior myself and others are seeing could be caused by more targeted application layer attacks. Of course this is speculation. However, something is not working right over there and people are attacking them.

Twitter’s Hosting Illustrated: F*ckyeahboobies.com

Thursday, August 6th, 2009
Today was an interesting day, it started with a DDoS attack to Twitter and is ending with boobies.

Richard Stiennon (over at Threat Chaos) and I started looking into the attacks and dug a little deeper into Twitter’s architecture.

We noticed that the status.twitter.com page did not go down. That’s because it’s hosted in RackSpace (far away from their web servers) on some guy’s computer. What’s fun about that (as Stiennon noticed) it also hosts Fuckyeahboobies.com (WARNING: link NSFW). Yes, that’s right, Twitter’s corporate status page is also the same server that hosts Fuckyeahboobies.com.

www.fuckyeahboobies.com. 3600 IN CNAME fuckyeahboobies.com.
fuckyeahboobies.com. 3600 IN A 72.32.231.8

;; ANSWER SECTION:
status.twitter.com. 60 IN A 72.32.231.8

Let’s be fair, hosting the status page away from Twitter’s hosting infrastructure is a very good idea. However, mixing it with 14,476 other hosted sites on the same machine may not be so bright. Those other sites can attract problems. If someone were to hack the group hosted machine and modify the status.twitter.com page, it could be harmful to the value of Twitter. One needs to ask the question: “Does this bring value to Twitter? Does saving a few thousand a year in hosting cost outweigh the risks?” Personally, I would expect a company that has $55 million in funding to strive towards world class design. At this point it’s not bringing value to their shareholders by cutting corners on critical infrastructure.

Anyhoo, over the morning, I constructed this basic diagram of Twitter’s hosting architecture (below) to help people understand what happened during their DDoS attacks. I must admit, it started out well with the boobies site, but when I started looking into their network I was a bit disappointed. They have a rather flat network that appears to be completely managed by NTT/Verio.

The sections in red are the paths that the DDoS would have taken. I would guess something in their load balancing farm was not configured to deal with the attack or this would have just been absorbed without much notice. The upstream routers were doing just fine when I ran tests during the DDoS attack. I get the feeling that their load balancers are doing most of the request validation.

When you look at the TCP handshakes for www.twitter.com, it responds on any port, which indicates they are running some sort of blind syn cookies (weeds out spoofed SYN floods). Again, I am assuming their load balancer or an upstream firewall is doing this. Along with their SYN cookies, they are doing a 302 redirect cookie (web server lingo for, “hey get the page over here instead”):

GET /
HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /?c3abf020

The assumption is that a real web browser will follow the new location cookie (”?c3abf020″ in my case). If you don’t follow the cookie, then you’re assumed to be a bot and denied access to the site. In some cases I have seen this setup eventually put repeat offenders on a blacklist, this could be determinate to Twitter.

This is a cleaver DDoS defense mechanism, however, there are thousands of scripts and tools written around Twitter’s API which don’t understand how to follow a 302. Thus, they are going to lock out lots of non-browser based clients. This includes my front page twitter update PHP script, Tweetdeck, Power Twitter, Seesmic, and the list goes on. I’ll fix my script now, but it looks like there was a lack of preparation for these attacks.

It’s pretty clear they are ready for a redesign. They need their own autonomous network, bring in bandwidth from many different providers, and have several layers of security. Building a strong ACL border and a nice mitigation layer would make a lot of sense. I also don’t think abandoning the shared cloud services model is a good idea, but having control over the heart of the operation makes sense.

Facebook has been doing a much better job at this as they were not crippled from the same attacks.

It just goes to show, there needs to be a blend of cloud services (like AWS) along with good in-house design.

UPDATE: 302 redirects were countermeasure fail

Posted on Google Developer Talk, Twitter developer Alex Payne stated:

Alex Payne
Aug 11, 5:00 pm
We’re aware of these issues; sorry.
Our ops team tells me that the countermeasures that are being put in place
should not cause the 302 redirect behavior that impacted OAuth and other
services late last week
. If you’re seeing that behavior, please post here
and we’ll coordinate with them to eliminate it.

Twitter down due to DDoS

Thursday, August 6th, 2009
Twitter Fail, image by hellvetica At a presentation I gave at an International Terrorism and Intelligence conference, I discussed how Twitter is an obvious DDoS target. Well about 30 days later they’re in the thick of it.

Twitter is down and their network has clear signs of massive failure. In the several hundred (if not more) cases of DDoS I have had experience with, this looks like a very clear case of an attack.

Congestion is a very clear sign of a DDoS attack. In this case you will see on a traceroute clean hops up to the last few, where the network starts to get congested. Basically that means each step of the network is clean until things concentrate at the end.

The assumption is the congestion is caused by DDoS and not a system administrator creating a routing loop or something whacky like that.

They also only appear to have ONE network provider (NTT), which is rather insane these days. It also makes targeting Twitter a much less complicated task.

Using very basic tools it is possible to see that the congestion on their network is rather extreme. It’s possible to deduce that the congestion is probably due to a DDoS attack.

DDoS Clue 1: UDP now blocked

6 mg-1.c00.mlpsca01.us.da.verio.net (129.250.24.202) 21.497 ms 18.386 ms 19.277 ms
7 128.121.150.245 (128.121.150.245) 19.289 ms 20.950 ms 17.331 ms
8 * * *
9 128.121.150.245 (128.121.150.245) 20.178 ms !X * *
10 128.121.150.245 (128.121.150.245) 20.731 ms !X * *
11 128.121.150.245 (128.121.150.245) 19.777 ms !X * *
12 128.121.150.245 (128.121.150.245) 27.217 ms !X * *
13 * 128.121.150.245 (128.121.150.245) 24.115 ms !X *
14 * * *

The !X in the traceroute tells us that someone has placed an ACL or a filter to block certain types of traffic. In this case the traffic they are blocking is UDP, which is what traceroute generates to test each hop.

DDoS Clue 2: Massive and erratic latency

When you look at a TCP data flow, with a tool like tcptraceroute, it’s possible to get a little deeper into the twitter network. You can see easily that there’s something very wrong at hop 6, where it goes from 10ms to over 700ms.

This is really strong evidence that someone is attacking Twitter:

4 mg-1.c00.mlpsca01.us.da.verio.net (129.250.24.202) 5.471 ms 10.941 ms 10.987 ms
5 128.121.150.133 (128.121.150.133) 10.988 ms 10.050 ms 10.988 ms
6 128.121.146.165 (128.121.146.165) 713.595 ms 1927.409 ms 1954.990 ms

One step further you can see the ICMP data is also showing massive struggle with the upstream network:

— twitter.com ping statistics —
248 packets transmitted, 68 packets received, 72.6% packet loss
round-trip min/avg/max/stddev = 1.080/424.280/2216.415/625.497 ms

This shows that the max response time has been 2.2 seconds (should be in milliseconds) and that the average is almost half a second. In my experience, this is very clear evidence of DDoS.

UPDATE 1: Twitter’s status page is reporting DDoS

Apparently they operate segmented networks, thus the www.twitter.com servers and load balancers are different than search.twitter.com which is different from status.twitter.com. Both status.twitter.com and search.twitter.com are up, I would assume also some of their API stuff is up, here’s what they say on status.twitter.com right now:

“Ongoing denial-of-service attack 4 minutes ago
We are defending against a denial-of-service attack, and will update status again shortly.

Site is down 1 hour ago
We are determining the cause and will provide an update shortly.

Update: we are defending against a denial-of-service attack.”

UPDATE 2: Twitter is struggling

The site continues to bounce up and down, it’s pretty clear they are trying to use DDoS mitigation techniques. The technique I see right now is a HTTP redirect with the assumption that Bots do not follow redirects:

GET /
HTTP/1.1 302 Moved Temporarily
Content-Length: 0
Location: /?c3abf020

The assumption is that a real web browser will follow the new location cookie (“?c3abf020″ in my case). If you don’t follow the cookie, then you’re assumed a bot.

This is a good, however, there are thousands of scripts and tools written around Twitter’s API which don’t understand how to follow a 302. Thus, they are going to lock out lots of non-browser based clients. This includes my front page twitter update PHP script. I’ll fix my script now, but it looks like there was a lack of preparation for these attacks. There may have been too many cooks in the kitchen.

Digital Assassination – The Ultimate Revenge!

Thursday, July 30th, 2009

All examples included in this posting are for educational purposes only and should never be put to practice or used. In other words, do not do them!

Death by Ethernet Given that today is the opening day for DEFCON 17 (a hacker conference), I figured I would pay homage by exposing some cyberwar techniques that are more social in nature, easier than writing amazing meterpeter exploits, but just as (if not more) impactful.

These days, cyber bullying is popular. Cyber bullying is when a bully makes fun of a kid online using MySpace, email, posting jokes, etc. Cyber-bullying is so harmful to a child’s mind and online persona that it has led several victim children to suicide. Cyber-bullying was brought to light when Megan Meier’s suicide was attributed to cyber-bulling via MySpace.

Children are not the only possible victims of cyber-bullying; someone’s online persona is also a great target. An online persona is an important commodity these days; a Google search on someone’s name is almost the modern day resume. These online personas are part of a larger group of what I term Digital Natives. The Internet has simply amplified older techniques used by intelligence agencies and governments.

Attacking someone’s online persona or discrediting someone using their online persona could have horrific consequences.

With communication and social media, there are new attack vectors, and cyber-bulling can be taken to a new level, something I call “Digital Assassination”. Digital Assassination, which is not anything new per-say, takes old methods and some new methods to manipulate, embarrass, cause jail time, discredit associations, politicians, corporations, or (in some people’s minds) have the ultimate result by invoking someone to commit suicide.

I had an internal struggle about writing this post. I do not condone the methods I discuss, nor have I ever practiced them. I hope this posting is used merely as a mean to inform people and protect them from being victims, rather than encouraging unethical, illegal, or nefarious actions.

There are a lot of tricks to the SEO (Search Engine Optimization) trade. Most of them involve manipulating Google, embedding data on pages to cause Google to think your site is more important than another site. This is what I call “search engine de-optimization.” What if the same techniques used in SEO were used to power a disinformation (or smear) campaign designed to destroy or manipulate someone or something’s digital existence? What if those techniques were combined with hacking, social manipulation? The result is scary.

At first you may feel that the general concept seems somewhat “out there”, but let’s look at some of the possible implementations.

Blog Pressure and Disinformation

    If an attacker is trying to eliminate a movement or politician’s influence, what better way is there to do so than ruining the essence of the movement or tainting the politician’s reputation? Someone can hire a team of paid bloggers; say 150 of them, working in India. There are companies that provide small blogger armies (just Google “paid bloggers”). They all operate on the Internet as if they come from different parts of the world (via proxy servers to make it more convincing), and all they do is post negative sentiments.

    The more this is deployed, the more the victim’s name in Google becomes associated with these negative blog postings. Thus, a Google search for the victim reveals blog postings about how he or she is an alcoholic, child molester, a physical abuser, etc.

    This can be amplified by using mailing list postings and USENET.

    Taking that further, one can link each blog comment to each other and create a more articulated web of links, which will help Google optimize the data.

    Likewise, what if you wanted to start marital troubles for someone? The attacker could start posting about the victim on dontdatehimgirl.com or various places such as twitter:

    “This guy is an asshole, we met at a corporate dinner three years ago, have been having an ongoing affair, and he’s been telling me that he was going to leave his wife, now he just cut me off! I want to expose for who he really is.”

    Or

    “I met last week at the conference, it was an amazing, romantic whirlwind. Now I am pregnant he refuses to return my calls or emails. Help!”

    What’s worse is this could be used via Facebook or even via pure email to the wife. With a little Photoshop help, by creating fake caught-cheating photos, it may be a hard to disprove

    Taking the caught-cheating photos and placing them on various sites will also help Google cache them in images.google.com. Further, if the images are named after the person’s name, it will help them come up first in a Google search.

    Cheating can also be replaced with other actions like industrial espionage, bad associations (having dinner with people you should hate). Imagine photoshopped photos of a VP of a company handing documents to the CEO of a competing company.

Jail Time

    Another method requires a little more work and some hacking skills that some people may not have. Yet it’s one of the most powerful methods one could use. This method basically involves hacking someone’s computer or taking it over remotely, implanting a lot of child porn on the computer, and posting that same child porn on USENET with the victim’s real email address.

    USENET is patrolled so carefully for this type of material that the result would be an FBI agent’s knock on the victim’s door, jail time, public embarrassment, maybe a pile of felonies, and to top it off… everyone thinks the victim is a pedophile.

    There are other methods such as filling a USB Drive full of child porn and simply dropping it near the victim’s car where he or she may pick it up. The attacker then tips off the police.

    In essence, the attacker frames someone for a crime. With the anonymous nature of the Internet, Operating Systems, and general digital accounting, it’s easy to put these crimes on the shoulders of the victim.

Fake Logs

    Another vicious attack vector would be simply to make-up an attack. Create logs of someone uploading child porn to a web site, making fake posting to your blog threatening to kill the president, or just a fake hacking attempt. System logs are all text, so typing up a log that looks real would be very simple and law enforcement can use that information as evidence.

    If fake evidence is introduced, it could have more power than actually attempting to frame someone for a crime.

Rogue Disinformation

    Hacker groups, governments, terrorist groups, politicians, businesses, and other activist groups use the Internet to spread their propaganda, turning their web sites into recruiting machines.
    What better way is there to disrupt them by using disinformation to discredit and fragment the momentum?

    One can hack their web site, and rather than a full website defacement, only change the wording a tiny bit, just enough to turn people off. Doing so will make their followers go, “huh?” and it may take a while for the changes to be caught.

    As an example (which should never be done and is fictitious), on a Governor’s web page, there is usually an about section. Let’s just say the text officially reads, “People who know me know that besides faith and family, nothing’s more important to me than our beloved Alaska.”

    IF one were to change that text to read; “People who know me know that nothing’s more important to me than my liberal views and beloved Alaska. In my life, I reject faith and family.”

    If the site massaging is not detected, the new text would sit for a few weeks would spread some serious disinformation.

    It’s also possible to register web sites that appear to be supporting a victim, gather viewing, and then negatively morph the message over time. For example, register supportgovernorname.com, copy the full text and content from other governor support sites. Link the site in places such as Wikipedia and other political blogs. Once there is traffic and linking going directly to the site (people are reading it/using it), slowly morph the text to make her messaging appear negative. Using DDoS attacks to shutdown the official web site to force people to the alternative fake site would also help force people to your messaging.

    For “informal movements” such as “the anti-sec movement”, a few well-placed postings usually derail them quickly. I suggested in a previous post that their threat of finding exploits to OpenSSH may have been someone not with the anti-sec movement anonymously posting using their name as a smear campaign. This hurt their public reputation.

Moving on…

There are many other examples of using Digital Assassination to control situations. I’m sure my readers could think of many other methods of using the Internet to control people and movements. I would be interested in hearing these ideas and attribute them in this page.

What you see, read, and link to may not always be reality.

Using Squid Proxy to Fight DDoS

Friday, July 24th, 2009



Complicated web applications are often difficult to scale, as a result they become easy DDoS targets. However, making them scale is easy with front-end proxy servers. The added scale gives an application more resiliency to DDoS attacks.


When setup correctly, the proxy “network” becomes the target of any malicious activity and can be placed globally while still keeping the original web application in same location for content.


This is by no means new, it’s been done all over the Internet and in some cases is the base of a bunch of different companies. This is just a simple tutorial that is meant to help people understand how this works.


Proxy servers can also be used with a dynamic caching function which can provide caching which will help increase the speed and functionality of the web site.

Positives:

  • Scales web server farms
  • Increases reach
  • Can accelerate a web site
  • Can provide additional security layers

    Negatives:

  • Adds an additional layer of debugging
  • Slows down long dynamic pages if they are not cacheable
  • Expensive to operate


    To start, I recommend using Squid Proxy version 2.7, it is available at http://www.squid-cache.org/


    After downloading the package, the vanilla build will suffice for most needs. You can use FreeBSD as the operating system and simply make install on the /usr/ports/www/squid package or build the package with a ./configure –prefix=/usr/local ; make install


    Often the prefix is /usr/local but determine what is appropriate for your OS.


    After the build has finished you will need to configure Squid, attached below is a sample configuration file:

    acl all src 0.0.0.0/0.0.0.0
    acl DO_NOT_CACHE urlpath_regex -i cgi-bin \? asp php css js
    acl manager proto cache_object
    acl purge method PURGE
    #
    refresh_pattern .               0       20%     1440
    #
    http_access allow all
    icp_access allow all
    #
    request_header_max_size 10 KB
    #
    cache_dir ufs /vol1/cachedir 512 16 256
    #
    visible_hostname supersite.com
    pid_filename /var/run/squid.pid
    #
    cache_access_log /var/log/httpd/proxy-a_access.log
    #
    cache_mem 64 MB
    maximum_object_size_in_memory 64 MB
    #
    httpd_accel_host virtual
    httpd_accel_uses_host_header on
    #
    #
    connect_timeout 30 seconds
    #
    emulate_httpd_log on
    hierarchy_stoplist cgi-bin ? asp css js php
    http_port XX.YY.ZZ.AA:80
    http_port XX.YY.ZZ.BB:80
    negative_ttl 60 seconds
    no_cache deny NOCACHE
    

    The configuration options are all explained in the default configuration file, the only major items to change are the http_port list, which should be the IP address it should respond on and the cache configuration. Some sites may have special items that should not cache. Often css and js should cache, but for this example they are dynamic.


    The logs will be written to /var/log/httpd/proxy-a_access.log in a combined Apache style format.


    When starting the squid, you will need to create a /cache directory on the server, simply run:


    mkdir /vol1/cachedir
    chown squid /vol1/cachedir

    You will also need to Create swap directories so Squid can run:


    /usr/local/bin/squid –z


    You will also need to teach squid how to communicate back to your “real” or “backend” web farm, often the DNS for www points to the IP address squid is answering requests for, this can be done using the /etc/hosts file:


    XX.YY.AA.BB www.mysitedns.com


    Replace the example above with the real IP address of the web farm and the host entry you want to be used to reach the IP address.


    Once squid is running and answering requests (/usr/local/bin/squid -k reconfigure /usr/local/etc/squid.conf) and the cache is working, it tends to stay stable until the hardware fails or you become under DDoS attack, which may require some additional ACLs within the squid.conf or SYN cookies configurations on the OS itself.


    Scaling squid is also not very difficult, it’s possible to load balance a farm of Squid servers with any standard load balancer, and have the requests still return to the same web farm, which may or may not work with any given user authentication / sessions setup.


    Blocking a given attack in Squid is trivial, however, if there are hundreds of Squid servers to configure at the same time, this may require some special configuration management that could require some development effort.


    Often most attacks have an empty or mal-formed User-Agent, this simple ACL will block 99% of invalid User-Agent attacks:

    acl OK_BROWSER browser a b c d e f g h i j k l m n o p a r s t u v w x y z 1 2 3 4 5 6 7 8 9 0 A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
    acl DO_NOT_CACHE urlpath_regex -i cgi-bin \? asp php css js
    http_access allow OK_BROWSER
    http_access deny all
    http_access deny manager
    http_access deny purge
    icp_access allow all
    


    You can also create a deny filter by creating an ACL that will deny rather than allow, the above ACL requires the user to have an VARCHAR in their User-Agent, which is pretty wide, so denying a specific item can be done like this:


    acl BAD_BROWSER browser Attack-Bot


    Add the deny line as the first line in the http_access ACL:


    http_access deny BAD_BROWSER


    Blocking a specific URL can look like this configuration line (which is designed to block most malicious requests):


    acl BLOCK_URI urlpath_regex -i \.exe \.\./\.\. \.\.\. \.ida \.idq \.IDA \.cnf \.asp \.dll 333-3333 test999 passwd /etc \` boot \.exe cmd \./\./ filenumber \% \* \; SELECT \\\.\.\\ \/\.\.\/


    Configuration of connection rate limiting looks like:


    acl 8conn maxconn 8


    And blocking a specific source address prefix:


    acl ip_addr1 src 192.168.1.0/24


    Just ensure that the ACL that is created is also configured in the http_access deny/allow list properly. Squid also needs to be told to re-read the configuration file, this is done by sending squid a –k reconfigure flag which will simply reload the rules without impacting traffic.


    To enable reverse proxy of SSL with the Squid cache owning the SSL certificate, you can use a pem cert and the following configuration line:


    https_port IP:443 cert=/usr/local/etc/squid/certs/COMPANY/COMPANY.pem key=/usr/local/etc/squid/certs/COMPANY/COMPANY.key


    Good luck and happy calamari

  • The Anti-Sec Non-Movement

    Wednesday, July 22nd, 2009
    A group calling itself “The Anti-Sec movement” released this statement over 48-hours ago:

    “In 48 hours, the anti-sec movement will publicly unveil working exploit code and full details for the zero-day OpenSSH vulnerability we discovered. It will be posted to the Full-Disclosure security list.”

    A number of people thought it was a joke, yours truly included. Yet there was a “what if” scenario which could have been ugly, so it should not have been completely ignored.

    The post to the Full-Disclosure security list may have been done to harm the reputation of the “movement”, something of a disinformation campaign. It also could be that they are just a bunch of script-kiddy kids.

    Anyway, for some mid-week entertainment, I put out an open call for Anti-Sec to use their new cool exploit to hack my personal server:

    “In fact, if it’s not FUD… use your uber cool 0-day sploit to hack my server please! blyon@blyon.com port 22. Prove it!”

    Of course the hack never happened, I had a few people trying to brute-force logins for accounts that did not even exist.

    HELPFUL TIP: Look, kiddies, if you’re going to try, at least use the username I provided to start with.


    I think anti-sec failed basic logic 1A, I mean… holy flawed logic Batman: In the ImageShack hack, their manifesto demands zero public disclosure on exploits, but then they contradict their own words by saying, “It [their OpenSSH exploit] will be posted to the Full-Disclosure security list.”

    As for their OpenSSH exploit: Anti-sec proved they have too much free time on their hands during the summer. The anti-sec movement needs to have a movement back to school. At least some people used it as an opportunity to cleanup their system configs.

    We are Digital Natives

    Saturday, July 4th, 2009
    A new class of person has emerged in the online world: Digital Natives. While living in San Francisco, I also live on the Internet. The Internet is now a place: a two dimensional world that has transcended the web; there is no government, and the citizens are Digital Natives. As Digital Natives, we are not people that only exist in a physical sense–we are something or someone metaphysically different. We are no longer just citizens of say, the United States; we are also citizens of the Internet.

    The concept of the Digital Native is a paradigm shift. In the past, there were movements, but not full worlds where one can exist and do as one pleases in parallel with their physical being. Some Digital Natives are deeply affiliated with all sorts of interests that bring them together organically: Piracy groups, massively multiplayer online games, open source software development, cracking encryption, etc. Others become deeply interested in movements such as Anonymous, the RBN (Russian Business Network), or even terrorist organizations.

    I’m not trying to say a Digital Native is better than someone unplugged in the Congo, I am trying to say they exist in a different social construct.

    Some Digital Natives may feel like their digital citizenship takes precedence over their physical citizenship. They choose not to define themselves by what country they live in but, rather, by what online movement(s) they are involved in. In these situations, what law does one live by? How are the actions of a Digital Native regulated? Governments don’t know how to react to, control, or assert power over them in these situations.

    Digital Americans are no longer just American citizens–they have a deep affiliation as Internet citizens as well.

    This scares the crap out of Governments all over the world, because they are ill prepared to deal with these situations. To government regimes that are comfortable asserting their control, this concept is terrifying. How do they counteract the changes online and the movements? Do they need to change their politics, defense, propaganda, and warfare?

    Apparently the U.S. Government thinks so. In June of 2009, under an order signed by Defense Secretary Robert Gates, the Pentagon announced it will create a Cyber Command to oversee the U.S. military’s efforts to protect its computer networks and have presence in “cyberspace”.

    Now even the US Military war machine is joining the world of Digital Natives.

    I’m a bit worried, not for us, but for them.

    Barrett Lyon creates fun companies that do all sorts of innovative exciting things with video and security.

    CDN cdn
    BitGravityBitGravity Barrett Lyon
    BitGravityBitGravity
    Barrett Lyon
    LimeLight Networks LimeLight Networks
    EdgeCast EdgeCast
    CDNetworks CDNetworks
    Consulting Consulting
    Speaker Speaking Opportunity
    Speaker Speaking Opportunity
    Content Delivery Network Content Delivery Network
    Content Delivery Content Delivery
    Flash Streaming Flash Streaming
    Interactive Video Interactive Video
    Live Streaming Live Streaming
    Live Video Live Video
    Streaming Audio Streaming Audio
    Streaming Media Streaming Media
    Video Delivery Video Delivery
    Video Hosting Service Video Hosting
    Video Podcasting Video Podcasting
    Video Podcasts Video Podcasts
    Video Services Video Services
    Video Streaming Video Streaming
    Barrett Lyon Barrett Lyon
    Barrett Lyon Barrett Lyon
    Barrett Lyon Barrett Lyon
    Barrett Lyon Barrett Lyon
    Barrett Lyon Barrett Lyon
    Barrett Lyon Barrett Lyon
    Barrett Lyon Barrett Lyon