This is yet another reason to not attach a Windows-based computer to internet without a firewall. Of course, having a public-access SQL server (regardless of its software) isn't a particularly good idea, either.
For both of these, there are exceptional requirements that can negate these general rules, but anyone who has these requirements should know better than to not take exceptional measures to protect the server.
The only drives I have had fail are ones that my supplier installed with plastic adapters to fit the 5.25" drive bays.
Their argument is that it cushions the drive in case of impacts in shipment or handling; My argument is that it insulates the drive from its heat sink, so I remove the adapters and put the drives into the dedicated 3.5" mounts provided in just about every case out there, which also frees up a 5.25" slot for other mischief...
DNSSEC has nothing to do with this. DNSSEC allows you to verify the source of changes to a domain server's entries, but does not address the problem of a domain's DNS servers being changed at the root server level.
Blocking their DNS at the routers until they can shape up sounds like the way to correct the issue next time.
I take it you're not familiar with how a registrar handles things like this, are you? A regisrtar does not necessarily handle any DNS traffic. They just make entries into the master database as to who does handle the DNS for a given domain. If they're providing web hosting or DNS services as part of their package, then yes, there would be DNS traffic to/from that registrar, but normally not.
But, I think what you're wanting would be handled by not accepting any database updates from them, which would require stripping them of their ICANN accreditation first.
Hmmm... I'm a GODADDY customer, and the only messages I receive from them are notices of things like the ICANN screwball decision, and domains about to expire, with 90, 60, 30, and 10 day advance notice.
Of course, I remembered to uncheck the little box when I set up my account that authorizes "third-party offers", and, when I log it, it says I "missed out on $328 in savings on special offers", but I'm not being spammed by GODADDY.
'I think kernel bugs should be fixed as soon as humanly possible, and any delay is basically just about making excuses,' Torvalds wrote.
My problem with this is that some people will interpret it as how quickly you can patch over the symptom, rather than how quickly you can correct the underlying problem. This will lead to "workarounds" being called "patches".
Personal experience shows that most bugs involve issues that might take a few days to resolve conflicts. "If I insert this fix here, does anything else break?"
Please authorise my PO so I may purchase the domainname OurNewProduct.com
Not a problem, unless the sender set their return address to something@OurNewProduct.com, and it doesn't exist. One of the restrictions available on Postfix and other MTAs is, "if you can't find a domain server for the MAIL FROM domain, reject it." It doesn't matter if there are invalid domain names WITHIN the message, because it doesn't parse those.
We've been buying our "medium-end" hardware, such as dual-processor Athlons. Liked it better before Google made them change their name from GOOGLEGEAR...
Remove the rock that is going to slide and place it as a break water around the side that will collapse. Once in place, if what's left collapses, you get a big splash, and fill in the breakwater with new crop lands.
If so, how come as I write there are 670,000+ defaced sites?
There are that many defaced phpBB sites because not all users or hosters know about proper setting of file permissions. Our unpatched sites were attacked for a MONTH (attacks started 21 November) prior to my hearing about the PHP and phpBB bugs, and were never damaged... Because the user 'apache' doesn't have write privileges in any of the directories that are accessible to the exploit. No writing means no defacing.
And that situation applies to both Linux and Windows hosting. When permissions are set correctly, the Santy worm hasn't got a chance.
Preferably in another building
In another city.
Inside a locked box, in a safe, in a bunker, which is inside another, bigger bunker, deep inside my secret volcano lair guarded by sharks with frickin' laser beams on their heads.
And UNDER the plans on display for the new hyperspace bypass route...
Actually, it doesn't have to do with unpatched phpBB installations.
It has everything to do with a design decision made by the authors of PHPBB, and copied by others... They trust cookie data. It just so happens that the unserialize() bug affects this, but there are other ways to exploit it.
The data they're storing in a user cookie should be kept on the server. The cookie should only contain a "key" to retrieve the data from the server's storage. If the users can't change the data directly, they can't exploit things like SQL injection, injection of unexpected variables, etc.
Compared to what, the migration of the continents?
I ask, because we're working very hard to remove Tomcat from our client's systems because it's been a huge bottleneck to expanding their capacity. Tomcat's job is a simple one - it runs one script, which (essentially) concats two XML files into a HTTP POST request, makes an HTTPS connection to a remote server with that request, and writes a file that contains the resulting XML to a file. The code to do this was provided by the vendor only in Java, the client was in a hurry to have things operational, so we set up a Tomcat server to get the job done. Unfortunately, it takes THREE SECONDS per transaction to do this on a 600MHz machine.
To be honest, our speed problem is related more to the overhead in starting the script and loading its required modules at each invocation than to the speed of Tomcat itself. Tomcat is using 6 times more memory resources than Apache, which doesn't help. If the vendor had provided us with code that didn't require file-based transfer of data, we could put Tomcat on its own server, and optimize its caching and increasing the memory allocated to it; but they didn't. By the time we'd reworked the Java code to not require the files (all data passed as HTTP requests), it only took another of hours to recode it directly into PHP.
In PHP, the same transaction takes a fraction of a second on the same hardware. Is even faster when the PHP code is incorporated directly into the scripts that currently call Tomcat (30 lines replacing 10), because it removes the overhead of writing files to move the XML data around.
The "working hard" part is political - because a couple of years have passed, and the Tomcat-calling code is incorporated into dozens of heavily-used scripts that the client considers "mission critical", i.e., "you can't break them". So they're reluctant to remove Tomcat, even though we've shown that they can increase their transaction capacity by at least an order of magnitude. Currently, the Java code on the client's end is the limiting factor; with the PHP replacement, bandwidth to the remote server became a problem. The need to remove single-point failures from their system (which Tomcat has become) has opened the door to change, though.
My point was about what you have to do to get PHP working (at least on some distros).
If you chose your distribution based upon "easy" vs. "hard", you already know what you're in for. Use Mandrake, RH/Fedora, SuSE, etc., you run the update script. If you are using a distribution that requires you to compile everything, well, you've made that choice and know what you're in for.
PHP's basic problem on the compile-from-source front is how many different things it can do, and how much it depends upon to do that. Compiling it yourself does involve tracking down all the different development header files, which most distributions don't install by default. You run into the same problem with Postfix, Apache, or any of hundreds of large packages.
I looked at the vulnerable code segments in PHPBB2, and I find them doing something remarkably similar to a massive hole I found in a content manager we were using - blindly trusting something that should never have been in the hands of the client side of the transaction.
In the case of PHPBB2, they save client configuration information in the cookies they send, and decode it when they get a request. When we're doing this sort of thing for our customers, that information is kept on the server, and the cookie only provides a handle to reach it later. This is basic session management, people, and provided for within PHP4! If it is information that needs to be persistent between sessions, it's stored in the client profile on the server, not in a cookie under the client's control! PHPBB2 seems to jump around between the stored-on-server and stored-on-client model, though...
The content manager was an accident waiting the happen, and it did... The author stupidly allowed the client to specify a file name to include in the script, using the super-secret HTML variable name "link", without even basic validity checking. What kind of mental giant does it take to realize that "if ($link !='') include $link;" is a bad idea?
I hate it when people spew information about Windows that hasn't been true in over 6 years and get modded up as +5 Informative
Ah, yes... The tendency for Windows ME and later to refuse to let you over-write a DLL it has decided is the "right" one for all programs to use, even when it isn't.
1. Each process under Win32 has its own address space and thus can load its own version of a DLL.
In a perfect world, everyone would store all required libraries that might have incompatible versions running around the world in the application's binary directory. But, that wasn't something Microsoft was selling when they came out with DLLs... "shared common code" and all of that. So people put all those required DLLs into the Windows directory tree, which is why a lot of programs (even today!) require SOME space on your Windows boot drive, even if you say they should install somewhere else. That would make the application's version of any DLL load into its private address space, since the app's directory is searched first.
Retroactively tell everyone who ever distributed a Win32 program to do that for me, would you, please? Lots of programs out there that work well that don't have XP-validated versions. I have a VMware Windows 98 virtual machine on my laptop so that I can run programs I need to control machinery, because the WinXP versions of the system DLLs don't work with them. Even in the cases where the company is still around, the XP-compatible version won't talk to the existing equipment, and XP's "Windows File Protection" scheme won't let the working DLL versions be installed... it's "protecting" me!
If I knew just what DLLs the various applications were dependent upon, I might be able to copy them from a Win98 disk to the program directory on an XP system, and maybe they'd work, but the installer from 1999 doesn't tell me that... it simply fails to install the program, because XP won't let it copy needed files.
Sorry, I've never had this happen in my life. Ever.
And I've never had a land mine explode under my car, so it can't happen. Right?
It hasn't happened to me in a few years, but it does happen. One of the news groups I subscribe to periodically gives advice to people going through it on how to resolve it... But, then again, it deals with programs that aren't considered "useful" to 98% of the computer users out there, so they're not as up-to-date as, say, "Half Life 2". But, they still have more users than there are Linux desktops.
Linus et al didn't invent problems with shared libraries, and neither did Microsoft. The important thing is having ways to deal with incompatible shared libraries... Which Microsoft was late in coming up with. I have programs I compiled under Mandrake 8.0 (2.4 kernel) that I run under 10.1 (2.6 kernel) without problems, so long as I load the right MySQL and GD shared libraries, which live side-by-side with the "native" versions. This is because the incompatible shared libraries have different names under Linux... while Microsoft hasn't always changed a library's name when they changed the API significantly.
Even the AC who put up a very detailed message on how Microsoft hacked together a way around most of the DLL problems (i.e., by moving to OCX et all for new development) shows that it was still a problem through Win2K and WinXP, and even there, unless the programs keep their copies of DLLs in their program directory (rather than just copying everything to \WINDOWS\SYSTEM32 like some installers default to doing), you could end up with the wrong DLL being loaded.
Note also that Microsoft's tool for detecting whether or not applications are vulnerable to the recent JPG and PNG problems doesn't catch all versions of the bad OCX file... Do the "good" and "bad" versions share the same GUID, to prevent loading problems, or different ones, so that you can differentiate between them?
What are they to do when the "honey pot" addresses are for the domains they're also targetting for spam? Our web pages serve up one trackable, but undeliverable, spam trap address per page view, which isn't visible to humans, but would be caught by any harvester. They're within the domain of the page being viewed, and would be obvious to a human as being fake.
One of these days, I'll automate the blacklisting of domains and IPs when these spam trap addresses are hit... Would save me a dozen manual postings per day.
The 69.6.0.0/16 subnet has SO many spam sites in it that our policy is to "soft bounce" anything coming from within that subnet until we can determine if it is legitimate. If it isn't, we introduce a hard bounce on the/24 subnet in question. If it real, though, we add a bypass for the affected IP (sometimes subnet), so it can go through.
Checking our filters, there were 120 subnet listings within 69.6.0.0/16, and none are marked "OK"! I say "were", because I just took the time to consolidate a lot of the adjacent subnet listings. The 69.6.66.0/24 subnet was first added to our filters in June of 2004, because of proxy-like activities (faked HELO addresses, MAIL FROM the same as the TO address, etc.).
I can download a binary onto Windows, and it just works.
Because installers for Windows programs silently replace DLLs with the versions they require... which can and does cause earlier programs to suddenly fail, because they depended upon a particular DLL's quirks. It's called "DLL Hell".
Linux programs are more proactive about checking library versions. But, you can install multiple versions, because the shared libraries usually have different names. Not so under Windows, and windows will only load the first version of a named DLL it finds, and hang onto it until you reboot. If that version fits your program, life is good; if not, well...
For many months now, I've published SPF records for all domains under my management. And every day, we get AOL trying to bounce messages allegedly from non-existant addresses within those domains... If AOL were really using SPF to reject spoofed mail as it arrives at their gateways as they've said they were going to, they'd have never accepted the spoofed messages, and I'd knock about 3% off my server load...
Give the user modify privileges on the [Palm] folder....
Are you refering to giving the specific domain user (not a local user) privileges, or does giving privileges to the "Domain user" group supposedly work? So far, I've tried giving "Full control" to the "Domain user" group for the whole Palm directory tree, and also the Chapura directory tree (some users are on the older Palm software, where the Outlook conduits were separated from the main program). As soon as the user is removed from the Administrators group, they're hotsyncs stop talking to Outlook.
I've tried this in the past - as soon as I remove the users from the admin group, they stop being able to hotsync to Outlook.
This isn't to say they can't hotsync - Anything they put into the Palm software application works just fine, and the data they grabbed from Outlook on the earlier sync will be backed up, but they can no longer attach to their Outlook data, once their privilege level is reduced to "power user".
Note that even this proposed solution isn't that great - what if the user has something in their "run once" registry that installs malware, just waiting for them to be elevated to the point where it can do real damage? If you have to make someone an administrator for ANY reason after they've wandered into the wrong sites, you're still very mutch at risk.
Slashdot Mirror
For both of these, there are exceptional requirements that can negate these general rules, but anyone who has these requirements should know better than to not take exceptional measures to protect the server.
Their argument is that it cushions the drive in case of impacts in shipment or handling; My argument is that it insulates the drive from its heat sink, so I remove the adapters and put the drives into the dedicated 3.5" mounts provided in just about every case out there, which also frees up a 5.25" slot for other mischief...
DNSSEC has nothing to do with this. DNSSEC allows you to verify the source of changes to a domain server's entries, but does not address the problem of a domain's DNS servers being changed at the root server level.
I take it you're not familiar with how a registrar handles things like this, are you? A regisrtar does not necessarily handle any DNS traffic. They just make entries into the master database as to who does handle the DNS for a given domain. If they're providing web hosting or DNS services as part of their package, then yes, there would be DNS traffic to/from that registrar, but normally not.
But, I think what you're wanting would be handled by not accepting any database updates from them, which would require stripping them of their ICANN accreditation first.
Hmmm... I'm a GODADDY customer, and the only messages I receive from them are notices of things like the ICANN screwball decision, and domains about to expire, with 90, 60, 30, and 10 day advance notice.
Of course, I remembered to uncheck the little box when I set up my account that authorizes "third-party offers", and, when I log it, it says I "missed out on $328 in savings on special offers", but I'm not being spammed by GODADDY.
My problem with this is that some people will interpret it as how quickly you can patch over the symptom, rather than how quickly you can correct the underlying problem. This will lead to "workarounds" being called "patches".
Personal experience shows that most bugs involve issues that might take a few days to resolve conflicts. "If I insert this fix here, does anything else break?"
Not a problem, unless the sender set their return address to something@OurNewProduct.com, and it doesn't exist. One of the restrictions available on Postfix and other MTAs is, "if you can't find a domain server for the MAIL FROM domain, reject it." It doesn't matter if there are invalid domain names WITHIN the message, because it doesn't parse those.
We've been buying our "medium-end" hardware, such as dual-processor Athlons. Liked it better before Google made them change their name from GOOGLEGEAR...
You haven't been on eBay in the last few days, have you? Passport won't work there soon...
Remove the rock that is going to slide and place it as a break water around the side that will collapse. Once in place, if what's left collapses, you get a big splash, and fill in the breakwater with new crop lands.
There are that many defaced phpBB sites because not all users or hosters know about proper setting of file permissions. Our unpatched sites were attacked for a MONTH (attacks started 21 November) prior to my hearing about the PHP and phpBB bugs, and were never damaged... Because the user 'apache' doesn't have write privileges in any of the directories that are accessible to the exploit. No writing means no defacing.
And that situation applies to both Linux and Windows hosting. When permissions are set correctly, the Santy worm hasn't got a chance.
In another city.
Inside a locked box, in a safe, in a bunker, which is inside another, bigger bunker, deep inside my secret volcano lair guarded by sharks with frickin' laser beams on their heads.
And UNDER the plans on display for the new hyperspace bypass route...
It has everything to do with a design decision made by the authors of PHPBB, and copied by others... They trust cookie data. It just so happens that the unserialize() bug affects this, but there are other ways to exploit it.
The data they're storing in a user cookie should be kept on the server. The cookie should only contain a "key" to retrieve the data from the server's storage. If the users can't change the data directly, they can't exploit things like SQL injection, injection of unexpected variables, etc.
Compared to what, the migration of the continents?
I ask, because we're working very hard to remove Tomcat from our client's systems because it's been a huge bottleneck to expanding their capacity. Tomcat's job is a simple one - it runs one script, which (essentially) concats two XML files into a HTTP POST request, makes an HTTPS connection to a remote server with that request, and writes a file that contains the resulting XML to a file. The code to do this was provided by the vendor only in Java, the client was in a hurry to have things operational, so we set up a Tomcat server to get the job done. Unfortunately, it takes THREE SECONDS per transaction to do this on a 600MHz machine.
To be honest, our speed problem is related more to the overhead in starting the script and loading its required modules at each invocation than to the speed of Tomcat itself. Tomcat is using 6 times more memory resources than Apache, which doesn't help. If the vendor had provided us with code that didn't require file-based transfer of data, we could put Tomcat on its own server, and optimize its caching and increasing the memory allocated to it; but they didn't. By the time we'd reworked the Java code to not require the files (all data passed as HTTP requests), it only took another of hours to recode it directly into PHP.
In PHP, the same transaction takes a fraction of a second on the same hardware. Is even faster when the PHP code is incorporated directly into the scripts that currently call Tomcat (30 lines replacing 10), because it removes the overhead of writing files to move the XML data around.
The "working hard" part is political - because a couple of years have passed, and the Tomcat-calling code is incorporated into dozens of heavily-used scripts that the client considers "mission critical", i.e., "you can't break them". So they're reluctant to remove Tomcat, even though we've shown that they can increase their transaction capacity by at least an order of magnitude. Currently, the Java code on the client's end is the limiting factor; with the PHP replacement, bandwidth to the remote server became a problem. The need to remove single-point failures from their system (which Tomcat has become) has opened the door to change, though.
My point was about what you have to do to get PHP working (at least on some distros).
If you chose your distribution based upon "easy" vs. "hard", you already know what you're in for. Use Mandrake, RH/Fedora, SuSE, etc., you run the update script. If you are using a distribution that requires you to compile everything, well, you've made that choice and know what you're in for.
PHP's basic problem on the compile-from-source front is how many different things it can do, and how much it depends upon to do that. Compiling it yourself does involve tracking down all the different development header files, which most distributions don't install by default. You run into the same problem with Postfix, Apache, or any of hundreds of large packages.
In the case of PHPBB2, they save client configuration information in the cookies they send, and decode it when they get a request. When we're doing this sort of thing for our customers, that information is kept on the server, and the cookie only provides a handle to reach it later. This is basic session management, people, and provided for within PHP4! If it is information that needs to be persistent between sessions, it's stored in the client profile on the server, not in a cookie under the client's control! PHPBB2 seems to jump around between the stored-on-server and stored-on-client model, though...
The content manager was an accident waiting the happen, and it did... The author stupidly allowed the client to specify a file name to include in the script, using the super-secret HTML variable name "link", without even basic validity checking. What kind of mental giant does it take to realize that "if ($link !='') include $link;" is a bad idea?
Ah, yes... The tendency for Windows ME and later to refuse to let you over-write a DLL it has decided is the "right" one for all programs to use, even when it isn't.
1. Each process under Win32 has its own address space and thus can load its own version of a DLL.
In a perfect world, everyone would store all required libraries that might have incompatible versions running around the world in the application's binary directory. But, that wasn't something Microsoft was selling when they came out with DLLs... "shared common code" and all of that. So people put all those required DLLs into the Windows directory tree, which is why a lot of programs (even today!) require SOME space on your Windows boot drive, even if you say they should install somewhere else. That would make the application's version of any DLL load into its private address space, since the app's directory is searched first.
Retroactively tell everyone who ever distributed a Win32 program to do that for me, would you, please? Lots of programs out there that work well that don't have XP-validated versions. I have a VMware Windows 98 virtual machine on my laptop so that I can run programs I need to control machinery, because the WinXP versions of the system DLLs don't work with them. Even in the cases where the company is still around, the XP-compatible version won't talk to the existing equipment, and XP's "Windows File Protection" scheme won't let the working DLL versions be installed... it's "protecting" me!
If I knew just what DLLs the various applications were dependent upon, I might be able to copy them from a Win98 disk to the program directory on an XP system, and maybe they'd work, but the installer from 1999 doesn't tell me that... it simply fails to install the program, because XP won't let it copy needed files.
And I've never had a land mine explode under my car, so it can't happen. Right?
It hasn't happened to me in a few years, but it does happen. One of the news groups I subscribe to periodically gives advice to people going through it on how to resolve it... But, then again, it deals with programs that aren't considered "useful" to 98% of the computer users out there, so they're not as up-to-date as, say, "Half Life 2". But, they still have more users than there are Linux desktops.
Linus et al didn't invent problems with shared libraries, and neither did Microsoft. The important thing is having ways to deal with incompatible shared libraries... Which Microsoft was late in coming up with. I have programs I compiled under Mandrake 8.0 (2.4 kernel) that I run under 10.1 (2.6 kernel) without problems, so long as I load the right MySQL and GD shared libraries, which live side-by-side with the "native" versions. This is because the incompatible shared libraries have different names under Linux... while Microsoft hasn't always changed a library's name when they changed the API significantly.
Even the AC who put up a very detailed message on how Microsoft hacked together a way around most of the DLL problems (i.e., by moving to OCX et all for new development) shows that it was still a problem through Win2K and WinXP, and even there, unless the programs keep their copies of DLLs in their program directory (rather than just copying everything to \WINDOWS\SYSTEM32 like some installers default to doing), you could end up with the wrong DLL being loaded.
Note also that Microsoft's tool for detecting whether or not applications are vulnerable to the recent JPG and PNG problems doesn't catch all versions of the bad OCX file... Do the "good" and "bad" versions share the same GUID, to prevent loading problems, or different ones, so that you can differentiate between them?
One of these days, I'll automate the blacklisting of domains and IPs when these spam trap addresses are hit... Would save me a dozen manual postings per day.
Checking our filters, there were 120 subnet listings within 69.6.0.0/16, and none are marked "OK"! I say "were", because I just took the time to consolidate a lot of the adjacent subnet listings. The 69.6.66.0/24 subnet was first added to our filters in June of 2004, because of proxy-like activities (faked HELO addresses, MAIL FROM the same as the TO address, etc.).
Because installers for Windows programs silently replace DLLs with the versions they require... which can and does cause earlier programs to suddenly fail, because they depended upon a particular DLL's quirks. It's called "DLL Hell".
Linux programs are more proactive about checking library versions. But, you can install multiple versions, because the shared libraries usually have different names. Not so under Windows, and windows will only load the first version of a named DLL it finds, and hang onto it until you reboot. If that version fits your program, life is good; if not, well...
Didn't you get the memo? It's ALL Bush's fault! Even the fact that the leaves fell off the trees suddenly last month is due to Bush ignoring Kyoto!
For many months now, I've published SPF records for all domains under my management. And every day, we get AOL trying to bounce messages allegedly from non-existant addresses within those domains... If AOL were really using SPF to reject spoofed mail as it arrives at their gateways as they've said they were going to, they'd have never accepted the spoofed messages, and I'd knock about 3% off my server load...
Are you refering to giving the specific domain user (not a local user) privileges, or does giving privileges to the "Domain user" group supposedly work? So far, I've tried giving "Full control" to the "Domain user" group for the whole Palm directory tree, and also the Chapura directory tree (some users are on the older Palm software, where the Outlook conduits were separated from the main program). As soon as the user is removed from the Administrators group, they're hotsyncs stop talking to Outlook.
This isn't to say they can't hotsync - Anything they put into the Palm software application works just fine, and the data they grabbed from Outlook on the earlier sync will be backed up, but they can no longer attach to their Outlook data, once their privilege level is reduced to "power user".
Note that even this proposed solution isn't that great - what if the user has something in their "run once" registry that installs malware, just waiting for them to be elevated to the point where it can do real damage? If you have to make someone an administrator for ANY reason after they've wandered into the wrong sites, you're still very mutch at risk.