Tilted Forum Project Discussion Community - The TFP Server was taken out by 'the government'

Haha... I can't believe you all believe the "official" story about how the events of 2/22! It was clearly masterminded by Halx as a way to get support for his "War on Error"...

Below you will find conclusive evidence that the downfall of Catfish would have been NOTHING but a cleverly concealed conspiracy. I can't believe you guys didn't see this yourselves.

The "official" story tells us that Catfish experienced a catastrophic hard drive failure on 2/21 or 2/22 and the resultant data integrity issues were enough to take down our forums and warrant completely replacing the server. But does that really make sense?

*** There were "practice" server failures going on that day
By sheer "coincidence", data center operators were performing drills about what to do in the event that a machine in the server room experienced a catastrophic failure. Is it really coincidence? Check out this AIM log recently leaked from the data center itself. Note that Dajeeb Seetharam is the data center Administrator and Edward Platt is a tech responsible for server room heat management.

Quote:

edward.platt: Hey.. this is Edward. I think we have a problem. I think the heat might be getting a little high in the server room, and it looks like this machine "Catfish" is about to overhead. Can you come take a look?

dajeeb.seetharam: Is this real-world or exercise?

edward.platt: No, this is not an exercise, NOT a test. I need your help down here right now!

On the day Catfish failed there were multiple server failure exercises and emergency drills being conducted with some of them having an eerie similarity to what actually happened. These drills took Dajeeb out of his cubicle and even caused confusion for him, switching from an "exercise" to a "real-world" scenario. Imagine being ordered to practice for a random server failiing and then finding out that it was really happening. Nothing like it had ever happened before - what are the chances?

What if I told you that a key player on the day of the attacks on Catfish and afterwards was on a committee that considered using hard-drive failure as a way to cover up destruction of servers? What if I told you that person was Dajeeb Seetharam? Would you believe me?

*** Catfish crashed way too fast, like a controlled demolition; It took only 18 seconds (if you count the time before power was cut completely).
If you look at the server logs on the day of the attacks, it becomes very clear that the server shut off and "died" way too quickly for an average computer failure. We all know how long it takes for a computer to actually die in the hard drive begins to overheat or seize, and Catfish's failure took 1/10th of that time. ALL experts consulted on the MTTC (Mean Time to Crash) after a hard drive failure agree that Catfish's failure was conveniently fast. It looks like a CLASSIC, A CLASSIC, controlled demolition.

When I asked an expert on computer failure about destroying PCs, he had the following to say

Quote:

I really think Catfish failed too fast. I've personally witnessed the destruction of hundreds of PCs by controlled demolition (Unplugging it and hitting it with a sledgehammer) and I can say that Catfish's failure exhibits characteristics IDENTICAL to controlled demolition. We can say conclusively that Catfish did not fail as the result of a simple hard drive failure.

*** The steel was not hot enough to crash the server
We all know that most servers are NOT made out of aluminum, like some high-performance desktop computers, but steel. Their entire chassis, to which the power supply (and conveniently, the hard drives) is made of STEEL. We know the melting point of steel is 2500 degrees Fahrenheit, and there's no way that the steel could've gotten that hot in an air-conditioned data center. So how did the hard drives "fail", causing a sudden collapse of the Forums? I think we know the answer there. Either there was an external fuel source (planted obviously by people who wanted Catfish to fail) or the "steel melting" story just isn't true. Perhaps it's been developed to draw interest away from the other damning evidence for a controlled demolition?

*** Other servers crashed too, with little explanation
We know that on the day Catfish crashed, adjacent servers also crashed. A few prominent websites were hosted on those machines, with content very similar to that hosted on the TFP forums. Is it sheer concidence that the "debris" from Catfish's failure caused other prominent websites to fail? I think not. If you've ever witnessed a computer's hard drive failing, you know that there is a lot of grinding noise followed by a sudden seizing of the head (on the armature) to the disks within. This doesn't cause ANY debris castoff, yet somehow they claim that the debris from Catfish's destruction caused other adjacent servers to fail?

http://www.cdfreaks.com/images/serve...re_servers.jpg

Shown here is a typical rackmount setup, like the one Catfish was placed in. Do you really believe that one of these machines failing could cast off enough debris to destroy others nearby? What about "Server 7", the rackmount at the bottom? Obviously there are more questions than answers here, and someone is trying to mislead us.

*** Halx was heard saying "pull it" shortly before the collapse
Yet another coincidence; on the day that Catfish was failing, he was alerted by server techs (Edward Platt and others) that the server seemed to be experiencing hardware failure and might not be recoverable. His response? "Pull it." It's an interesting choice of terms, and another expert I consulted about computer demolition claimed that

Quote:

"Pull it" is a well known computer term. When you say "pull it", you're telling other techs nearby that they should disconnect the power cord from the power supply.

Why would they authorize such an operation? Why would you want to disconnect the power to a machine which could be potentially saved? I think the answer is obvious. They didn't want the evidence of destruction to be available. By pulling the power, they immediately disconnected the server from the internet (and other means of communication), so no one but the men in the server room could ever know what TRULY happened to Catfish.

*** There was evidence that the attacks were known ahead of time
There is even evidence that Halx knew ahead of time that the servers would crash. On the day of the crash, I was able to see PUBLICALLY AVAILABLE information embedded in the source code of the website. I've shown it elsewhere, but I'll show it here too.

PHP Code:


		
			
<div class="sidebarcontent">

  <h2>Latest Posts</h2>

  <ul id="latestposts">

  <li><a href="#">There are none</a></li>

  

  <li><a href="#">because</a></li>

  <li><a href="#">the web server</a></li>

  <li><a href="#">died last night</a></li>

  </ul>

An interesting thing to note is that this was presented LONG before the public was made aware of the failure of Catfish. We all thought that there was some sort of DNS hiccup, or that something non-catastrophic had happend to the server. Yet somehow the developer of this page ALREADY knew that the server had "died"? How did he know this long before anyone else? Perhaps he was part of the plan?

*** They threw the server away before anyone could inspect it
It is customary in "hosting" arrangements to return a failed server to the owner, as it obviously can't be hosted in the data center anymore. Oddly enough, though, Catfish was never returned. Immediately after the "failure" of Catfish happened, system administrators began immediately boxing up the remaining parts of the server. They didn't let anyone else see them, and the server room itself was locked to all unauthorized personnel until the cleanup had finished. They shipped the parts off in a box to some warehouse in China, but no one is willing to provide details about where they ACTUALLY went. If Catfish really suffered a hard drive failure and NOT a controlled demolition, why wouldn't system administrators want people seeing the parts? Maybe because they knew that anyone who saw the parts could clearly deduce that more was wrong with Catfish than a bad hard drive?

*** Data-center operators clearly heard two BOOMs, not the silent failure of a hard drive
Linda Georgette, another tech on duty the night that Catfish failed, remarked:

Quote:

Yea.. [...] right about when that Catfish thing failed, I heard an explosion. What was wierd.. though.. was that I, ummm.. I heard a second boom right afterwards..

What kind of server "BOOMS" when the hard drive fails? I don't know about you, but a hard drive failure is normally signified by a grinding and a hissing, not a big BOOM, like an explosion. What sounds like an explosion? Oh yea, a controlled demolition.

http://www.geekologie.com/2007/07/19/cd-explode.jpg

I think you should see now that we clearly aren't being told the true story about the events that lead to the collapse of Catfish, and someone has a very good reason for wanting it kept secret. If you want to join the Catfish Truth Movement and show your support for the REAL truth about our server's destruction, send your $25 enrollment fee to halxtfp@gmail.com.

Also: Mods, can we move this to Politics? I think its clear from the evidence that this isn't just Paranoia.

http://img509.imageshack.us/img509/6442/catfishgy6.jpg

http://www.cert.org/tech_tips/denial_of_service.html

Quote:

# Description

This document provides a general overview of attacks in which the primary goal of the attack is to deny the victim(s) access to a particular resource. Included is information that may help you respond to such an attack.

A "denial-of-service" attack is characterized by an explicit attempt by attackers to prevent legitimate users of a service from using that service. Examples include

* attempts to "flood" a network, thereby preventing legitimate network traffic
* attempts to disrupt connections between two machines, thereby preventing access to a service
* attempts to prevent a particular individual from accessing a service
* attempts to disrupt service to a specific system or person

Not all service outages, even those that result from malicious activity, are necessarily denial-of-service attacks. Other types of attack may include a denial of service as a component, but the denial of service may be part of a larger attack.

Illegitimate use of resources may also result in denial of service. For example, an intruder may use your anonymous ftp area as a place to store illegal copies of commercial software, consuming disk space and generating network traffic
# Impact

Denial-of-service attacks can essentially disable your computer or your network. Depending on the nature of your enterprise, this can effectively disable your organization.

Some denial-of-service attacks can be executed with limited resources against a large, sophisticated site. This type of attack is sometimes called an "asymmetric attack." For example, an attacker with an old PC and a slow modem may be able to disable much faster and more sophisticated machines or networks.
# MODES OF ATTACK

Denial-of-service attacks come in a variety of forms and aim at a variety of services. There are three basic types of attack:

* consumption of scarce, limited, or non-renewable resources
* destruction or alteration of configuration information
* physical destruction or alteration of network components

1. Consumption of Scarce Resources

Computers and networks need certain things to operate: network bandwidth, memory and disk space, CPU time, data structures, access to other computers and networks, and certain environmental resources such as power, cool air, or even water.
1. Network Connectivity

Denial-of-service attacks are most frequently executed against network connectivity. The goal is to prevent hosts or networks from communicating on the network. An example of this type of attack is the "SYN flood" attack described in

http://www.cert.org/advisories/CA-1996-21.html

In this type of attack, the attacker begins the process of establishing a connection to the victim machine, but does it in such a way as to prevent the ultimate completion of the connection. In the meantime, the victim machine has reserved one of a limited number of data structures required to complete the impending connection. The result is that legitimate connections are denied while the victim machine is waiting to complete bogus "half-open" connections.

You should note that this type of attack does not depend on the attacker being able to consume your network bandwidth. In this case, the intruder is consuming kernel data structures involved in establishing a network connection. The implication is that an intruder can execute this attack from a dial-up connection against a machine on a very fast network. (This is a good example of an asymmetric attack.)
2. Using Your Own Resources Against You

An intruder can also use your own resources against you in unexpected ways. One example is described in

http://www.cert.org/advisories/CA-1996-01.html

In this attack, the intruder uses forged UDP packets to connect the echo service on one machine to the chargen service on another machine. The result is that the two services consume all available network bandwidth between them. Thus, the network connectivity for all machines on the same networks as either of the targeted machines may be affected.

3. Bandwidth Consumption

An intruder may also be able to consume all the available bandwidth on your network by generating a large number of packets directed to your network. Typically, these packets are ICMP ECHO packets, but in principle they may be anything. Further, the intruder need not be operating from a single machine; he may be able to coordinate or co-opt several machines on different networks to achieve the same effect.
4. Consumption of Other Resources

In addition to network bandwidth, intruders may be able to consume other resources that your systems need in order to operate. For example, in many systems, a limited number of data structures are available to hold process information (process identifiers, process table entries, process slots, etc.). An intruder may be able to consume these data structures by writing a simple program or script that does nothing but repeatedly create copies of itself. Many modern operating systems have quota facilities to protect against this problem, but not all do. Further, even if the process table is not filled, the CPU may be consumed by a large number of processes and the associated time spent switching between processes. Consult your operating system vendor or operating system manuals for details on available quota facilities for your system.

An intruder may also attempt to consume disk space in other ways, including
* generating excessive numbers of mail messages. For more information, please see

http://www.cert.org/tech_tips/email_..._spamming.html

* intentionally generating errors that must be logged
* placing files in anonymous ftp areas or network shares, For information on proper configuration for anonymous ftp, please see

http://www.cert.org/tech_tips/anonymous_ftp_config.html

In general, anything that allows data to be written to disk can be used to execute a denial-of-service attack if there are no bounds on the amount of data that can be written.

Also, many sites have schemes in place to "lockout" an account after a certain number of failed login attempts. A typical set up locks out an account after 3 or 5 failed login attempts. An intruder may be able to use this scheme to prevent legitimate users from logging in. In some cases, even the privileged accounts, such as root or administrator, may be subject to this type of attack. Be sure you have a method to gain access to the systems under emergency circumstances. Consult your operating system vendor or your operating systems manual for details on lockout facilities and emergency entry procedures.

An intruder may be able to cause your systems to crash or become unstable by sending unexpected data over the network. An example of such an attack is described in

http://www.cert.org/advisories/CA-1996-26.html

If your systems are experiencing frequent crashes with no apparent cause, it could be the result of this type of attack.

There are other things that may be vulnerable to denial of service that you may wish to monitor. These include

* printers
* tape devices
* network connections
* other limited resources important to the operation of your organization

2. Destruction or Alteration of Configuration Information

An improperly configured computer may not perform well or may not operate at all. An intruder may be able to alter or destroy configuration information that prevents you from using your computer or network.

For example, if an intruder can change the routing information in your routers, your network may be disabled. If an intruder is able to modify the registry on a Windows NT machine, certain functions may be unavailable.

For information on configuring UNIX machines, see

http://www.cert.org/tech_tips/unix_c...uidelines.html

For information on configuring Microsoft Windows NT machines, please see

http://www.microsoft.com/security/

3. Physical Destruction or Alteration of Network Components

The primary concern with this type of attack is physical security. You should guard against unauthorized access to computers, routers, network wiring closets, network backbone segments, power and cooling stations, and any other critical components of your network.

Physical security is a prime component in guarding against many types of attacks in addition to denial of service. For information on securing the physical components of your network, we encourage you to consult local or national law enforcement agencies or private security companies.

# Prevention and Response

Denial-of-service attacks can result in significant loss of time and money for many organizations. We strongly encourage sites to consider the extent to which their organization could afford a significant service outage and to take steps commensurate with the risk.

We encourage you to consider the following options with respect to your needs:

* Implement router filters as described in Appendix A of CA-96.21.tcp_syn_flooding, referenced above. This will lessen your exposure to certain denial-of-service attacks. Additionally, it will aid in preventing users on your network from effectively launching certain denial-of-service attacks.
* If they are available for your system, install patches to guard against TCP SYN flooding as described in CA-96.21.tcp_syn_flooding, referenced above. This will substantially reduce your exposure to these attacks but may not eliminate the risk entirely.
* Disable any unused or unneeded network services. This can limit the ability of an intruder to take advantage of those services to execute a denial-of-service attack.
* Enable quota systems on your operating system if they are available. For example, if your operating system supports disk quotas, enable them for all accounts, especially accounts that operate network services. In addition, if your operating system supports partitions or volumes (i.e., separately mounted file systems with independent attributes) consider partitioning your file system so as to separate critical functions from other activity.
* Observe your system performance and establish baselines for ordinary activity. Use the baseline to gauge unusual levels of disk activity, CPU usage, or network traffic.
* Routinely examine your physical security with respect to your current needs. Consider servers, routers, unattended terminals, network access points, wiring closets, environmental systems such as air and power, and other components of your system.
* Use Tripwire or a similar tool to detect changes in configuration information or other files.
* Invest in and maintain "hot spares" - machines that can be placed into service quickly in the event that a similar machine is disabled.
* Invest in redundant and fault-tolerant network configurations.
* Establish and maintain regular backup schedules and policies, particularly for important configuration information.
* Establish and maintain appropriate password policies, especially access to highly privileged accounts such as UNIX root or Microsoft Windows NT Administrator.

Many organizations can suffer financial loss as a result of a denial-of-service attack and may wish to pursue criminal or civil charges against the intruder. For legal advice, we recommend that you consult with your legal counsel and law enforcement.

U.S. sites interested in an investigation of a denial-of-service attack can contact their local FBI field office for guidance and information. For contact information for your local FBI field office, please consult your local telephone directory or see the FBI's contact information web page:

http://www.fbi.gov/contactus.htm

Non-U.S. sites may want to discuss the activity with their local law enforcement agency to determine the appropriate steps that should be taken with regard to pursuing an investigation.

If you are interested in determining the source of certain types of denial-of-service attack, it may require the cooperation of your network service provider and the administration of the networks involved. Tracking an intruder this way may not always be possible. If you are interested in trying do to so, contact your service provider directly. The CERT(*) Coordination Center is not able to provide this type of assistance. We do encourage you to report your experiences, however. This helps us understand the nature and scope of security incidents on the Internet, and we may be able to relate your report to other activity that has been reported to us.