Web Hosting Geeks' Blog » hackers

What the New User can Learn from the GoDaddy Account Hack

Art — Fri, 30 Sep 2011 12:18:03 +0000

Recently a security breach occurred in 445 of GoDaddy’s web hosting accounts. While that may not seem like a lot on a percentage basis, that is also high enough to indicate that the hack was some type of systemic problem. This can scare the new user into a lot of frantic questions.

Panicked thought is seldom a clear thought. So even if you were one of the accounts in question, there are things that you’ll want to consider when evaluating this incident.

Innocent until proven guilty

One of the most obvious knee-jerk responses is the one that is most necessary for us to correct immediately: blaming GoDaddy. When something like this happens, until you have very specific, proven reason to believe otherwise, it’s unwise and unfair to blame the host. We’re hesitant to even use this as an article topic for that reason. We only are because this will happen now and then, and it’s good to have the object lesson.

Why did this only happen with GoDaddy though, you might ask? There are many reasons that have nothing to do with them. The most obvious is just efficiency. By focusing their attack on one host with many users, the hacker(s) don’t have to concern themselves with more than one system architecture.

What actually happened?

Let’s summarize the incident. The compromised accounts had their .htaccess file changed. This is a file that handles URL requests on the user account level. It sets rules for how to treat different requests to that user’s web site based on different criteria. In this case, it was set so that any hits to the user’s site that came from a major search engine were redirected to a malicious outside site. This site in turn infected the surfer’s browser, continuing and amplifying the disease.

The accounts have since been re-secured, but this does now require that we ask the pertinent question: how were the accounts infiltrated?

They got the passwords – but how?

What we know is that somehow the bad guys got these user’s passwords. What we don’t know is how. So in lieu of having further information, we must use this opportunity to repeat two of the oldest security cautions:

Keep your software updated – One site suggested the possibility that the users exploited a hole in a web site created by an outdated version of WordPress of Joomla! You need to decide how much it’s worth it to stay close to the news reel on security updates, but either way don’t ignore them entirely.
Choose secure passwords! – This is the bane of the security world. Even after decades of warning, users still continue to have “123456” and “password” for passwords. Do you? Change it! This is a major reason why we must give GoDaddy the benefit of the doubt: this alone might have been the cause of the break-in.

In summary, if there’s any one piece of advice we can take from this incident, it’s this: don’t panic. Security for your web site requires clear-thinking at all times.

Keep Your Site Safe – Learn What Not to Do

Art — Fri, 23 Sep 2011 13:09:52 +0000

Let’s face it: The Internet isn’t the golden playground it once was, where all could go and have their swing in peace. In fact, it’s now so overrun with bullies and miscreants that it’s a wonder we haven’t decided to swap school districts yet! That was a joke, but the idea remains the same. It’s a wild, wild world out there, and if you aren’t careful, your site may be a ripe melon just waiting to be cracked open.

However, there are steps you can take to safeguard your source of livelihood. First of all, simply admitting that you need to keep your server locked down is a good place to start. From there, it’s worth taking a look at the way you manage your site. If you’re doing any number of things wrong, you may be leaving your site exposed. With that in mind, take a look at the following common mistakes, any of which can drastically reduce the security of your site:

Is Your Password Strong?

Seriously, though, this is one we just can’t seem to convince people to consider. No matter how unique or quirky you may think your password is, if it’s a common phrase or word, it just ain’t strong enough to be your main horse. Most hackers use password guessing software to get at your goods, but a lot of the time they don’t even have to go that far. Be sure your password is long, has a few capital letters, and at least one number. There are too many permutations for even a computer to guess, and if you take advantage of this, you’re already close to home, as far as server security goes.

Keep To Your Roots!

There’s no reason at all that you should constantly be logging in as the root user. No matter how powerful it may make you feel, you just shouldn’t be doing it, because leaving your account access open like that is like tacking a sign to your site that says, “Hack me, please!” Likewise, if your SSH accounts offer direct root access, you’ll want to change that immediately. Having that level of control just laying around is in no way healthy, and will very quickly compromise your site.

Know Your Traffic

Lastly, don’t be oblivious to your traffic, and learn to watch your site’s flow. Know who and where your traffic usually comes from, and be aware of any sudden changes in this pattern. If you see a new user from a suspicious location, be on your toes. The best defense is to keep your eyes open!

How And When To Offer SSH Access To Your Customers

Art — Thu, 22 Sep 2011 16:39:57 +0000

If you’re running on a Unix or Linux server, then you likely access your files systems via SSH on a daily basis. However, this might be well and fine for an administrator like you, but should you also be offering the same access to your customers? SSH is particularly vulnerable to attacks by unwanted intruders, and by giving out that kind of power on a limb you may be greatly compromising the security of your system.

The need for SSH access largely depends on the kind of services you’re offering. Giving customers that level of connection puts them as close to administrator status as they’ll ever get. Also, giving each user a secure password makes it that much easier for a hacker to gain access to your server. With that many backdoors left laying around, you’re only increasing the likely hood of an attack.

That being said, telling customers flat-out that you won’t offer SSH access may alienate a large portion of the available market. If you have a consumer that demands this kind of connection, then it’s best to cave. However, be sure to follow the tips below to ensure your server remains secure, even with the risks involved:

Jail Your Users

If you are granting users SSH access, be sure to jail each of those sorry saps to their home folders. This way they cannot easily see the other files laying about your server, and aren’t likely to accidentally tamper with any of them. Likewise, this makes a truly unfortunate break-in less of a concern, as any hackers—armed with nothing but a security code—will be no better than the user himself.

Setup A New Port, Sailor

By default, SSH travels through port 22. Be sure to change this, at least for your users, that way common exploits cannot be turned against. It also prevents hackers from gaining the same access as you’ve got—a truly tragic situation, and one you definitely want to avoid!

Don’t Put-Out By Default

As mentioned, only offer SSH services when a customer requests it. It’s simple enough, and will save you a lot of headaches that never use, nor want, the service.

Insist On Country Strong Passwords

Make your users have secure passwords, and don’t hesitate to reject weak ones. Likewise, have your consumers change their security codes often. Don’t be afraid to exert your status as server master, and insist that they keep up with a monthly regime of code changes.

How To Deal With A Possible Intruder On Your Server

Art — Wed, 21 Sep 2011 08:59:02 +0000

You’re cruising through your server’s inner network one fine day, when all of a sudden you notice an unfamiliar name accessing your files. This user may have come through SSH, or any other access method, but no matter the entry port, you certainly don’t want them accessing your files. Before panic sets in and you find yourself pulling the plug on your hard-earned hardware, use the following steps to first ensure that you do have a hacker onboard. Only when you’ve made certain should you blow the whistle—remember that neither customers nor colleagues appreciate a Boy Who Cries Wolf.

Did You Forget A User?

Think about it: Did you create a user with this designation, and then forget about it as the seasons rolled by? Perhaps you left a user behind a long time ago with a weak password, or just haven’t seen this user log-in for a while, and are now experiencing an uncomfortable case of deja vu.

Is This An Authorized Robot?

Remember that many of your other servers, such as your database server or your web server, operate within the system as “false” human users. There are also several different services running under the hood that do their jobs in this manner. Before freaking out about a human intruder, check the designation of the “hacker.” If it’s something similar to nobody, noname, sys, or apache, then you’ve not got a problem, just a working robot. If you’re unsure, but think the user might still be a script, do a quick Google search for the user’s name.

What Are They Doing In There?

The next step is to check what the user is actually doing: Are they running a script or program you’re familiar with? This is where things start to heat up, in a software sense: If the user is running a standard application like Apache, then don’t worry your pretty little head. However, if they’re operating a script you’ve never seen, it’s time to do a bit more digging—you may actually have a real intruder on your hands.

What To Do If Nothing Else Has Worked

If you’ve come this far, then you might genuinely have an intruder on your server. If so, the root user is the only one with the ability to create new accounts. With that in mind, check your root password and account for changes: Plug-ins and extras you have installed may also grant accidental access to the superuser. You may need to hire a security expert to check out your system, if there’s no obvious infiltration.

How to Keep Your Server Safe From Common Security Problems

Art — Tue, 13 Sep 2011 14:45:02 +0000

It’s a wild, wild world out there. There’s all kinds of culprits just waiting to hack your website, trash all those gorgeous lines of code, and then steal your information from here to Sunday. Thankfully, though, we as web hosters have had plenty of time to study the most common forms of cyber attack: And we’ve come up with quality ways to deter them, too.

Use the following bits of information and tactic to keep your server safe from cyber hacking.

The Dreaded Denial-Of-Service Attack

This one’s a common one, and sadly, it’s pretty hard to avoid. The best method of defense against this is a good relationship with your hosting provider. This is where it’s a good idea to have a quality web host, instead of that cheap Chinese derivative you found for next-to-nothing in Shadyville, Internet Land.

A denial-of-service attack (or DDOS) is nothing more than putting your servers into hyper-mode. This is accomplished by sending too many requests through to your software, effectively crippling your website with much more load than it can handle.

This seems like a real brute force way to do things, and it is. So why is it still a problem, if it’s so basic a method? Well, the issue is in the way a DDOS is deflected: It’s incredibly hard to defend a site against what is, essentially, just extreme use. To safeguard your website against a DDOS, you’ll need to either shut down flow entirely (very undesirable for any business site) or locate the exact IP of the perpetrator and block it out. To do so, you’ll need a good connection with your host, as well as their willingness to help you out. Remember, a good host cares, and will always try their best.

Script Overload via Buffer Overflow

Your URL is essential for uploading new data to your site, as behind that glorious front page, there’s a collection of packaging scripts that interpret your information into HTML eye-candy. Sadly, these scripts can be hijacked by sending a super-long URL to your server, potentially creating new code or rewriting that which is already in place.

To guard against this, just make sure your scripts are locked down against unwanted intrusion. Keep a strong password, and ensure with your provider that only you or your associates have access to these vital, background daemons.

Several Security Risks and How to Avoid Them

Art — Fri, 09 Sep 2011 14:25:52 +0000

Yes, you’ve made sure that you’ve chosen a password that you can remember, that no one else can guess, and that has in it at least one number and one punctuation mark. You know, though, that there is more to securing your web site than that, but you don’t know where to start looking for the most common methods of weakness exploitation, and how to make them not so weak.

Though they may sound hopelessly technical at first, the basic types of security issues are easy to understand, and once understood, easy (enough) to prevent.

Denial-of-service attack

One of the oldest tricks in the book is still one of the most commonly used. The Denial-Of-Service attack (DDOS) consists of nothing more than flooding a web site with more requests than it can handle, effectively paralyzing the site so that it cannot be used by legitimate web surfers.

The reason that this type of attack still exists today is that it is surprisingly hard to deflect. Done right, a single request from a DDOS doesn’t look noticeably different from a legitimate request. It’s only in the volume of requests that the problem becomes apparent. Furthermore once an attack is recognized the only way to shut it down without shutting out “real” traffic is to find a unique fingerprint on the requests and filter only that. While this means that a lazy attacker can be stopped by simply blocking his IP address, a sophisticated attacker (or worse, dedicated group of hackers) can create a deluge of requests that is very difficult to differentiate.

The only real solution to this is to have a web host that is willing to stay with you and keep the barbarians from the gates. A good host will.

Hacking by URL and buffer overflow

A web page’s URL is a common place to send the information to a web server that it needs to form new pages. The problem is that this information often goes to a script which has privileges that, if hijacked by URL, could be used against the server itself.

A subset of this problem is the buffer overflow. This is when a URL is sent that is too long for the web server to handle. What often happens, depending on the server specifications, is that the remainder of the URL is sent to the server as a command, often run as “root” (the user set by default to have universal privileges).

What you need to do about this depends on what the operating system of your server is, but usually comes down to both making sure that your scripts are secured against this weakness and making sure that they are setup in such a way that, even if they are compromised, they don’t have the security permissions necessary to do anything nefarious.

Check with your web host

A security problem for a single user is potentially a security problem for all users, meaning that your web host doesn’t want it any more than you do. Check their help documentation, and by all means, ask about anything that confuses you. Their livelihood is on the line right along with yours, so they will always be glad to help you both feel more secure in your site.

Performing IP Filtering Through cPanel – A Brief Tutorial

Art — Tue, 06 Sep 2011 10:00:01 +0000

Security is something that nearly every webmaster has the need for, but not every webmaster knows how to pursue effectively the appropriate security measures. Given the craftiness of the hacker world, it can seem to the novice an unwinnable fight where they just have to accept a certain amount of break-ins as a sort of collateral damage.

While it is good to understand that it’s impossible to make a lock that can’t be picked, this doesn’t mean that you should take frequent security breaches as the norm. With just a little bit of education and effort, the untrained webmaster can lock down their site to levels that it would take extreme efforts to break. This brief tutorial will focus specifically on how to use cPanel to filter the IP addresses that can access your web site, a step that, by itself, can keep a large percentage of attacks from even making it to your site.

IP Filtering – easy to do…

To filter an IP address or block of IP addresses from accessing your site using cPanel is simple. In the Security section near the bottom of your cPanel main page you will see an icon labeled “IP Deny Manager”. Click on it and you’ll be at a page where you can add new restrictions, see your current ones, and remove any existing ones. The page lists the appropriate formats (don’t bother with the CIDR format: it doesn’t do anything you can’t do any easier way).

Now, if you know how to block IP addresses, a more important question comes: what addresses to you block? If you are getting a wave of attacks from a single IP address, the choice of course is simple. But what do you do if they are coming from a number of IP addresses? The short answer is this: block a range if it feels right, but don’t go overboard.

Let’s say that you are getting attacks from 212.56.24.X, where X is variable, and nothing else from that class C (an IP address format is Class A.Class B.Class C.Class D). Then, blocking everything from 212.56.24 should be safe. But let’s say they are all from 212.56. You do some research and see that this is a university Class B and there are plenty of safe hits from those addresses. Of course, a college is going to have a few bored hackers. Taking down all of those addresses is overkill and will negatively impact your traffic.

Find the right middle ground

It’s rare that you are going to want to restrict anything more than a Class C. In general, you’re not going to want to restrict anything more than you have to. Use trial and error: block what you need to and, if the site continues to get hammered, modify and expand your rules. Then, once it feels like you might have scared them away, remove the blocks, keeping a close eye for 24-72 hours afterwards to make sure that they don’t start up again. Also, be sure to let your web host know if the attack is particularly vicious: they might want to filter the bad IP addresses on a network level.

IP Filtering by itself will not solve all of your security problems: no one method will. But it will ensure the bulk of the worst attacks will be filtered away from you so you can focus more on other things.

Is SSL Essential for eCommerce Sites?

Art — Fri, 29 Jul 2011 20:41:32 +0000

As the number of eCommerce websites grows, the security software must improve to protect webmasters from hackers acquiring sensitive customer information. One such technology is Secure Sockets Layer (SSL) which permits the site administrator to transfer the contents of web pages to visitors over a secure protocol (HTTPS versus HTTP). One example of this technology is with banking websites.

Should eCommerce Websites Use SSL?

However, this begs the question, should eCommerce websites also use this type of security? They all handle important customer data that could be harmful if released to the wrong hands. This really depends on the type of business and functions the website serves. For instance, for websites like online stores that collect credit card numbers, addresses, emails, phone numbers and names, SSL is a necessity.

SSL and the Front-End Store

However, there are a multitude of websites that only serve as the front-end of the store and all transactions are managed by a third-party payment processor which utilizes SSL encryption. In this situation, SSL may not be a requirement. However, webmasters in this situation may still wish to add the security software. This is especially important if collecting user information such as names and email addresses; even if no financial information is transferred.

Find an eCommerce Package

For websites that only provide basic contact information, SSL encryption is not necessary. If you decide to implement SSL encryption onto your website, it is critical to find a web hosting provider that offers some type of eCommerce package. Many of these plans provide a specific IP address for SSL to ensure the highest level of protection.

Ask About Specific Items Included in the Package

In addition to the basic eCommerce plan, you will also need to purchase an SSL certificate which is a digital item that may be provided as part of your eCommerce web hosting package. It is always a good idea to ask about the items specifically included in the eCommerce package prior to signing a contract.

SSL technology has become a vital part of the eCommerce industry. However, it is not essential to every site. Those that will be most affected by the technology are sites that collect specific information such as banking, detailed contact information, telephone numbers and email addresses. Since this could compromise the most important data about an individual, it should always be protected by SSL encryption.

LulzSec’s Hacking Career Slated to End

Art — Fri, 22 Jul 2011 19:27:09 +0000

Well-known Internet mayhem group LulzSec recently announced to its followers that it will cease its campaign of web-based attacks. The group implemented numerous DDoS (Distributed Denial of Service) attacks on a variety of targets during its 50-day spree of chaos. Many of the attacks were a result of poor security measures.

Utilizing Twitter Feeds

Ironically, the group left numerous tips on its Twitter feeds for its victims. For instance, when Fox Broadcasting was attacked, LulzSec released a Twitter update stating, “Don’t use the same password twice. Your laziness will not end well.” Another guideline announced was to not using prepaid credit cards to conduct online purchases. The slew and successful hit of targets included giant conglomerates, law enforcement agencies, governmental organizations, television networks and ATMs.

The Goal of the Mayhem

LulzSec stated in the letter that their goal was to have fun, entertain other followers and share “lulz.” During the period from May 6^th, 2011 to June 26^th, 2011, the group left information technology experts wondering who they will be attacking next.

Fox.com

One of the first attacks conducted by LulzSec occurred on May 6^th, 2011. The group targeted the Fox.com website due to a leaked database of X-Factor contestants. LulzSec also defaced 14 LinkedIn accounts of Fox Broadcasting employees.

ATMs

Through the 50-day period, the group harvested 3,133 individual bank account details from ATMs in England which were posted on Twitter and Pastebin. The details included machine identification number, latitude and longitude, the address, company owner and transaction amounts recently made.

PBS.org

Next on their list was the PBS.org website in which the group posted a fake story claiming the dead rapper Tupac Shakur was still alive in New Zealand. Also, many passwords were stolen and a number of web pages defaced. The attack was in response to a documentary on Julian Assange which displayed him in a negative light.

Sony PlayStation Network

The Sony PlayStation Network was the next target due to the lack of security measures. LulzSec stole information from 1 million user accounts to prove the company did nothing to improve their security. Other hacker groups condemned LulzSec from exposing the user data which could have led to identity theft.

The most interesting aspect of the group was their telephone hotline. By dialing 614 LULZSEC, angry callers could request a target to be DDoS’d. During its reign, the group missed more than 5,000 calls and had over 2,500 voicemails. Additionally, the group redirected phone numbers to World of Warcraft customer service, a hosting company and FBI office in Detroit. LulzSec proved their point by wreaking havoc on Internet companies and groups that they simply did not like.

How to Prevent Domain Hijacking

Art — Fri, 10 Jun 2011 20:12:12 +0000

Although a website owner may feel secure upon registering a domain name, many don’t realize that domains are subject to hijacking. Domain hijacking, or domain theft, is a prevalent nuisance that is on the increase. Hackers need not to even access the target web server to create havoc.

The process of hijacking a website really doesn’t require a lot of knowledge or even effort. There are various methods hackers use to hijack domains such as launching Trojan viruses, illegitimately acquiring login information or utilizing software to hack into a web hosting account to reconfigure ownership information. Once hackers gain access to the targeted web server’s control panel, the chaos and headaches begins for website owners.

While most domain hijacking attacks are illicit, large companies take advantage of their branding leverage citing copyright infringements. By doing so allows more established companies to legally “hijack” specific domains. Unfortunately, small companies simply don’t have the necessary resources to defend their domains when toppled by a larger company with the same resources readily available to combat legal battles.

Locking the Hijacking Tool Shed

The truth is hijacking of a domain doesn’t take an arsenal of tools to access an authorized account. The two basic items needed to hijack a domain is the target domain’s registrar name and the administrative e-mail address for the target domain. Upon accessing these two essential items, hackers can easily hijack a domain without the knowledge of the authorized owner. Website owners often don’t realize that this information is available online for the public to view by visiting www.whois.com. A simple search can reveal the imperative information needed to hijack a domain, however, it’s possible to thwart hacking attempt by opting for a private domain registration.

A private domain registration allows website owners to hide vital information such as personal details including name and administrative e-mail address. So, when a potential hacker looks up the domain on WHOIS, the information is hidden from public view. It’s strongly recommended that website owners take the proactive security measures and choose to hide such details to thwart hijacking attempts.

Additionally, website owners should always inquire about the respective registrar’s security policy. Also, ask about domain locking options as most registrars provide the feature to prevent unauthorized security breaches.

An Ounce of Prevention

Perhaps the best way to protect a domain name from being hijacked, aside from the above suggestions, is to opt for a reliable and trust-worthy provider. Remember that usually you get what you pay for, so if a proven legit provider costs a few dollars more, it’s worth the extra cost to protect your domain name from hijacking attempts. The initial proactive security costs are a well-worth investment, especially when compared to trying to undo the chaos created by a successful hacking mission.

Web Hosting Geeks' Blog » hackers

What the New User can Learn from the GoDaddy Account Hack

Related posts:

Keep Your Site Safe – Learn What Not to Do

Related posts:

How And When To Offer SSH Access To Your Customers

Related posts:

How To Deal With A Possible Intruder On Your Server

Related posts:

How to Keep Your Server Safe From Common Security Problems

Related posts:

Several Security Risks and How to Avoid Them

Related posts:

Performing IP Filtering Through cPanel – A Brief Tutorial

Related posts:

Is SSL Essential for eCommerce Sites?

Related posts:

LulzSec’s Hacking Career Slated to End

Related posts:

How to Prevent Domain Hijacking

Related posts: