SteveW

What I believe is happening is that for some reason your browser is sending, at random times, outgoing requests to one or more remote websites different from the one you are visiting at the time. It is from those websites that you are receiving the error messages. I did a web search on the symptoms you're reporting, and got some results on similar but not identical issues. This is one, at a forum where I've seen people receive much helpful advice: http://www.bleepingcomputer.com/forums/topic332524.html For that person, it appears the problem went away after they went through Windows rootkit removal steps. A rootkit is a very serious kind of computer infection. This is not to say that you definitely, or even probably, have a rootkit, but it does indicate that it's one of the possibilities, which suggests that this has the potential of being quite serious. This is another similar post in the same forum: http://www.bleepingcomputer.com/forums/topic359330.html I was going to suggest that you post here a list of your Firefox and IE add-ons and toolbars, and that you post the contents of your Windows "hosts" file. And that you install the Firefox add-on called "Live HTTP Headers" https://addons.mozilla.org/en-US/firefox/addon/live-http-headers/ which allows you to view in real time the outgoing requests that your browser is sending, so you can see where they are being sent to. You can feel free to do that, if you wish, but I suspect that you may find these steps to be more of a challenge than you might want to attempt. And one of the reasons that I posted the link to that other forum is to illustrate that the steps needed to track down and resolve mysteries like this can be very complicated. Because that other forum has a focus on issues like this, it might be worth posting there to get advice from people who do that on a daily basis. However, you can see from that example post that the types of things they are likely to ask you to do to try to track this down can be very challenging. It would probably be much less nerve-wracking to take your computer to a service shop for examination. It's just my opinion, but I don't think it's wise to do things like bid on eBay or visit other financial related sites while you're experiencing a mystery like this that could be malware related.

In spite of my misgivings this time, the upgrade on my forum seems to have gone as smoothly as it always has before. I don't have any official "mods" installed, just an index.template.php that I customized myself, and that wasn't one of the files affected by the upgrade. I agree that requiring forum users to conform to password rules (or username guidelines as I suggested was desirable) is unrealistic and that most forum admins, including myself, wouldn't bother, to avoid user confusion or annoyance. On the other hand, any SMF forum admin could use those measures to protect their own account, since an admin's account is the one you really don't want compromised. I consider long random passwords necessary, but if someone insists on using a weak password and using the same one at a forum and Facebook and Twitter and their online bank, that's their problem, not mine. It's easy to create a password strong enough that it can't be guessed over the internet within any reasonable time (like 1000 years). I agree, all good ideas. SMF uses a pretty good CAPTCHA on the registration form. I haven't had any bot registrations that I know of. Adding it elsewhere such as the post submission form would require custom coding, as would the slow response and lockout strategies. Unless there's an SMF mod for them. I don't know. This current "attack" really doesn't seem that effective. The request rate I've seen is slow (1 per 4 minutes), which isn't going to guess anybody's password unless it's "123456" or "password". The SMF admins most concerned about the attack are probably seeing much higher request rates, such that their users can't stay logged in, and it fills up SMF error logs.

SMF has released version 1.1.13, and SMF 2.0 RC5, and a security patch for SMF 2.0 RC4. The announcement is at http://www.simplemachines.org/community/index.php?topic=421547.0 I haven't done this upgrade yet, and find it more confusing than normal. Even though the release includes 1.1.13, the provided information and discussion seem overly focused on the 2.0 branch. The announcement post doesn't have links to the usual files that you can review to see what changes are being made, but there is a web page list of the file edits at [go to http://custom.simplemachines.org/upgrades/ Click the SMF 1.1.12 to SMF 1.1.13 link (but not the Download link next to it)]. It seems to me (I could be mistaken) that there are more reports of upgrade problems than normal in the 1.x support board at http://www.simplemachines.org/community/index.php?board=9.0. ---- Simultaneously, there seems to be a sizable botnet (?) attack currently going on against SMF forum sites. That topic is also being discussed in the support board linked above. Two symptoms of the attack: 1. Users are unable to remain logged in. 2. Your forum error log shows hundreds or thousands of "password incorrect" errors. Robots are harvesting SMF usernames from forum posts. Then, brute force password attacks are launched, from a very large number of IP addresses, against those user accounts. The reason the legitimate users can't stay logged in is that after a certain number of failed login attempts on their account, SMF invalidates all the outstanding login cookies for that user. The currently announced upgrade is said to alleviate the login problem, but it can't stop the attacks. It only makes it possible for the legitimate users to remain logged in themselves. The defense against brute force password attacks is for all users to use long random passwords that can't be brute-forced. It also helps if users use a screen name (display name) that is different from their login name. That way, the name that they log in with doesn't appear on their forum posts. Any illegitimate login attempts will be using the wrong login name. There is much talk about banning the IP addresses that are doing the attacks, but that is not such a good idea because there are so many. If you're affected by this, it's better to examine your logs for the common elements of these login attempts, and ban (in .htaccess) by those common characteristics (other than IP). A careful examination will reveal that the illegitimate login attempts can be distinguished from legitimate ones.

Excellent solution! Which reminds me that I've been using OpenDNS for ages. Fast, reliable, no problems. You don't have to join or register, even though they have some services that you can join or register for. All you have to do is find the location in your version of Windows where you set your DNS server IP addresses, and change them to the two IP addresses of OpenDNS, which are displayed on their home page. In Windows XP, it's start > Connect To > (Name of your Internet Connection) > Properties > Networking > Internet Protocol (TCP/IP) > Properties > Use the following DNS server addresses:, and fill in the blanks.

Bill, The possible causes I can think of are 1) Corrupted DNS cache on the PC (would be solved by a reboot). 2) Corrupted hosts file on the PC. 3) Malicious or corrupted browser toolbar. 4) Other malware, more deeply embedded in Windows. Those should be detected by antivirus scans. 5) Corrupted DNS cache at the ISP. If it's not one of those, I've run out of suspects. queenpictoria, Any new updates? Is this still happening? If it's an ISP problem, there's not much you can do except report to them what's happening, in as much detail as possible.

In addition to what Bruce said, Yes.

You're correct, this (when you see it at a variety of websites) would definitely not be caused by a problem on your TCH server. Drudge is certainly a real website. They don't reveal what server program they use, but their normal 404 page doesn't mention nginx. Besides the "malware on your PC" scenario I tried to describe in my earlier post, another possibility is a simpler "browser hijacking", also caused by malware on your PC. Do you use an antivirus program? If a scan by your current antivirus program, and another scan using something like Trend Housecall, Symantec/Norton, or Malwarebytes finds no malware on your PC, the next suspect is that there might be a problem at your ISP. It could be a DNS cache poisoning, so some of your outgoing requests get hijacked and sent to the wrong websites. Something like this doesn't happen by accident. This behavior is very suspicious (it can be a hazard to you), and there is a cause.

As others have said, nginx is a web server, like Apache. It can be used, same as Apache, to serve websites. You could see that message if you just happened to be trying to visit a lot of nonexistent pages at websites that happened to be using nginx, but that seems a bit unlikely, as Apache is a lot more common. nginx can run on Windows. I would suggest you do a thorough system-wide antivirus/antispyware scan with a good scanner. The scenario I'm a bit concerned about is that a virus infection might be able to install nginx on your PC, and then make modifications to your Windows "hosts" file (in Windows XP, it's at C:\WINNT\system32\drivers\etc\hosts) that redirects some of your outgoing browser requests to incorrect destinations. That is, it would do erroneous translations from URL names to IP addresses. Some of those requests might be directed to your local nginx server for unknown malicious purposes. If the page doesn't exist, you'd get the 404 Not Found error. It is fairly common for website compromises to install a rogue nginx server alongside Apache on the compromised machine, which is then used for nefarious purposes. I hadn't heard of that being done on a home PC, but it doesn't seem impossible. I think it's worth checking out. As a quicker check, try launching Task Manager to see if anything called nginx is running. I'm not really sure what it would be called, but nginx seems like a logical possibility.

Time/CPU/Memory were all things I'm concerned about, but time is the only one I currently know how to measure and control. I'm assuming the techs won't be shy about disabling the script and informing me if it causes any problem. In case it's any use to someone in the future, this is how I make the script time itself out instead of waiting for the system to do it: > my $maxseconds = 1; # time limit in seconds. 0=no limit. my $starttime = time(); # Now, reference time. my $timedout = 0; # bool flag. my $elapsed = 0; # elapsed time. # Inside a loop, the program accumulates output over multiple levels of processing. # If processing exceeds the time limit before finishing the task, it exits the loop, # but the script will still go on to print whatever output it has. # The task is able to partially or mostly complete, less disruptive than # if the system forcibly terminates it (?). for(something) { do_something(); if($maxseconds > 0) { $elapsed = time() - $starttime; if($elapsed > $maxseconds) { $timedout = 1; last; } } } print("$output\n"); if($timedout) { print("\nOutput is partial due to time limit exceeded.\n"); }

It's not quite as strange as it sounds. The perl script has a .txt data file that it reads. It's a list of words that the script will consider "trivial" when it encounters them. I thought people using the script might be interested to know which words are in that list, so on my web page (not in cgi-bin) that discusses the script, I put a hyperlink to the text file. Clicking on that link is what causes the "500" errors. However, the easy solution was to move the .txt file out of cgi-bin into the same directory as the web page, and revise the script to read the file from its new location instead of from cgi-bin.

Thanks, Bruce. I would have discovered that many weeks from now and had a "doh" moment. Before trying cPanel, I went ahead and uploaded Scrubber.pm to cgi-bin and used the 2 lines I posted previously: >use lib '/home/USER/public_html/cgi-bin/'; use Scrubber; # rather than HTML::Scrubber because it's not in an /HTML/ subdirectory. Plus, added this code to cgi-bin/.htaccess to prevent web access to any Perl modules in cgi-bin: ><FilesMatch ".+\.pm$"> order allow,deny deny from all </FilesMatch> It's working! Then I tried installing the module via cPanel, but did encounter some issues. So Alex, unless those are issues that the staff would really want to know about (that is, it would benefit the whole server), or unless there are important reasons why I shouldn't do this by the method I worked out, I'd prefer to stay with what I've got and not bother the support desk.

This also appears to be a possibility : >use lib '/full/path/to/cgi-bin/'; use Scrubber; It's working (at least in tests at home), and looks like it might be preferable because it allows using "USE".

If I put an index.html file in my cgi-bin, I can call it with my browser. But if I put a test.txt file in cgi-bin, the request returns a 500 Internal Server Error. If I put test.txt in any other folder, I can request it successfully. Are the handlers specially configured for cgi-bin such that there isn't one defined for .txt? The "problem" was solved by putting the file somewhere else. I'm just trying to understand why it happened.

My script tracks its execution time and quits if a specified time limit is reached. It's currently limited to 1 second, which seems safe enough for testing but might not be sufficient later. At what point would I be impacting server performance? Maximum execution time for PHP scripts appears to be 30 seconds by default, but is that pushing the limit of what's acceptable? It's also configured so that when one instance of the script starts running, it creates a flag file that prevents any other instances from being launched until it finishes.

I've developed and tested on a server at home a Perl script that I'd like to use on my (shared hosting) website, but it requires a module that isn't installed on the TCH server. Is it permissible to upload the module to my own cgi-bin and use it from there? If so, is this the correct way to do it? It's working for me at home, but I'm not sure it's the best way: In the file that uses the module, instead of: >use HTML::Scrubber; I'm trying this: >do '/full/path/to/cgi-bin/Scrubber.pm';

Thank you Thomas for the many alerts you post here. That's what reminded me to post this. SMF 1.1.12 was released about Nov 1. It wasn't expected that there would be a 1.1.12, but there is.

Three possible ways to deal with this: 1) No error logging (as per TCH-Alex's instructions). 2) Error log in /public_html/ where it is now, but protected from web access. Add to .htaccess: ># In place of error.log, use whatever is the actual name of your error log. <Files error.log> order allow,deny deny from all </Files> 3) Error log in a custom location: First create the desired folder. Then add to /public_html/php.ini (again using the real file name instead of error.log): >error_log = /home/USERID/public_html/path/to/error.log The example shows where public_html belongs in the path, but you could truncate the path to put the file outside public_html. If, on the other hand, you put the log file in its own folder that is within public_html, you can protect that whole folder from web access: Create an .htaccess in that folder, and put this code in it: >order allow,deny deny from all

I don't know about Publisher 2007, but I experimented with Publisher 2003 when I first got the idea to build a website. Even though I knew absolutely nothing about web design or HTML, it only took me a couple of hours to decide that Publisher had been intended for print publishing, not web publishing, and that web publishing must have been added as an afterthought. In retrospect, if I had continued with Publisher, I don't think I would have learned any HTML skills that would transfer to another web page editor. So my two cents input is that you would be better off using anything other than Publisher, even Notepad. Obviously, if you just want to learn something (anything) new, or experiment with graphic design ideas, Publisher could be interesting and useful for your layout *ideas*, but I suspect when it comes time to put your ideas on a real web page for publishing, you'd end up rebuilding the page from scratch in a real web design program, to match the layout you'd created in Publisher. Since (if your experience is like mine) using Publisher doesn't teach you any HTML skills to help you do that, your time spent in Publisher would have been wasted.

Something from the help desk that might be useful to some people: If you were previously using this .htaccess line to have PHP code parsed in .html or .htm files: >AddHandler application/x-httpd-php .html .htm The new line to use is: >AddHandler application/x-httpd-php5 .html .htm

Thanks, Ryan. That's great. I won't make any changes, then.

Considering that TCH has automated methods for the transition, none of the below may be necessary but I'll go ahead and post it anyway, partly to find out if there is a recommendation that these steps not be done. OJB, I had the same concern as you, that *not* using suPHP requires one .htaccess format and using suPHP requires another. From the moment the changeover occurs until I notice it's happened, it seems possible my site might throw "500 - Server Error" until I make the .htaccess change manually. So here's a possible template that should handle both situations, making the transition seamless: TCH-Dick or TCH-Ryan, does this look correct? Is mod_suphp.c the correct name of the module to test for? ># .htaccess code for if you want to continue using .htaccess for PHP configuration: # THIS BLOCK WOULD BE ACTIVE BEFORE THE TRANSITION TO SUPHP <IfModule !mod_suphp.c> php_flag display_errors Off </IfModule> # THIS BLOCK WOULD BECOME ACTIVE AFTER THE TRANSITION # IT WRAPS THE CODE IN THE php_config TEST <IfModule mod_suphp.c> <IfModule php_config> php_flag display_errors Off </IfModule> </IfModule> OR ># If when the transition occurs, you want to switch to using php.ini: # THIS BLOCK WOULD BE ACTIVE BEFORE THE TRANSITION TO SUPHP <IfModule !mod_suphp.c> php_flag display_errors Off </IfModule> # THIS BLOCK WOULD BECOME ACTIVE AFTER THE TRANSITION # IT CAUSES PHP.INI TO BE USED INSTEAD OF .HTACCESS <IfModule mod_suphp.c> # This tells suPHP where your php.ini file is. suPHP_ConfigPath /home/USERID/public_html </IfModule> # PROHIBIT ANYONE FETCHING YOUR PHP.INI BY WEB <Files php.ini> order allow,deny deny from all </Files> Sample public_html/php.ini text file >allow_url_fopen = Off allow_url_include = Off display_errors = Off display_startup_errors = Off expose_php = Off register_globals = Off A remaining issue is that I believe suPHP doesn't tolerate folders with permissions at 777 or files with 666. I don't know what happens if it encounters any. If you have any, I can't think of a way to make that part of the transition seamless (automated), but maybe TCH will automate that, too?

Thank you for the advance notice, and thank you for posting the changes in the server threads. It will help a lot to know right away when the changeover occurs. Even if the <IfModule php_config> workaround allows PHP configuration to continue to work in .htaccess, will it be permitted to use a public_html/php.ini file as an alternative? Would it be the preferred alternative? There are some options allowable in php.ini that can't be done in .htaccess.

Maybe try checking the hosts file at C:\WINNT\system32\drivers\etc\hosts for unwanted modifications. A malicious or wrong entry in hosts overrides any DNS lookups, which can make sites fail to load, such as if a site that's supposed to be on the web is instead pointed to localhost. That would affect both browsers. The Firefox add-on Live HTTP Headers can show you in real time whether FF is actually sending out the requests, which can help troubleshoot. When a site fails to respond, it is possible for the local DNS cache to save the "note" that the site is unreachable in the cache, which will prevent the system even trying again until the time to live (TTL) of the entry expires, which can be as long as a day. Easiest way to flush the cache is to restart the PC. A command line utility program called tracert (part of Windows) can show you the path from your PC to the destination server. It will show timeouts, etc., which will help determine whether the PC is sending out requests at all, another troubleshooting aid to help determine whether requests are actually being sent, and at what point the hangup is occurring. Also check the firewall log, if there is one. Some firewalls have allow-traffic rules based on a signature of the executable of the requesting program. So if IE or FF are updated to a new version, the signature changes, the firewall program considers it a new program, the old rule allowing the program no longer applies, and the new version is blocked by default.

There's no one or a few ranges of IP addresses that cover all of China, so it would take thousands of .htaccess IP range bans to do that. There are some more complicated solutions available. I'm not familiar with them, but the phrase to do a web search on is GeoIP.

Imagine this situation: Drupal has a bug in it. If you send it a magic phrase, it will allow you to run any PHP script you want on the site where it's running. That's not an imaginary scenario; it's a fanciful description of the actual situation. Rather than the formmail.pl script being the avenue of entry, it's much more likely someone sent Drupal the magic phrase which tricked Drupal into fetching and running a PHP script from some remote site. The script, which at that point was running within Drupal, on your site, found all your text files and injected the text into one or more of them. Considering that the Drupal page at Secunia is mostly about "script insertion vulnerabilities" (with 3 more new ones added yesterday!), that is by far the prime suspect. A script injected like that can delete your entire website if it wants, so whether sent by "script kiddie" or not, it's very dangerous.