I currently work tech support for a small ISP, I'd say those numbers are about right, at least that many of the calls we get here are spyware related, some so severely that we have to refer the customer to their computer manufacturer to reformat and reinstall, or have the customer (assuming they are local) bring it in to our office to have it removed.
Many of the spyware programs out there now infect the system so deeply that none of the removal programs will manage to get rid of it, and some of its now being designed with properties of classic "stealth" viruses - ie, so that theres at least some component (usually a reinfector stub) thats not detectable while the process is running (intercepting system calls, etc so that you can't see it by normal means))
The problem's getting pretty ridiculous, and will only continue to get worse so long as we have browsers that treat web pages as if they were executable files, and users that click buttons on dialogs reflexively without even realizing they are there.
At this point, I spend as much as 10 hours a week just on spyware-related calls. That's insane, even with the peanuts I make working at a mom-n-pop ISP, thats real money. Now, if we can just find a way to bill the scumware companies for our time...
Given Bert Rutan's history with experemental aircraft, and the things that can go wrong with automated controls, fully manual flight controls only make sense. By keeping the controls simple, and by having avionics that tell the pilot what to do rather than do it for him, they reduce the expense, while improving pilot safety. Look at all thats gone wrong with NASA's massively redundant computer systems - if the flight computer on spaceshipone completely fails, chances are the pilot will still land the craft safely, and may even be able to complete the mission safely.
Hmm... A first post that wasn't a troll. I'm amazed.
I've got a couple database applications using PHP that I've been working on for a while - I wasn't aware that PHP could be easily embedded into a C application.
Obviously, I'd get better performance with a hybrid of C and PHP code, so this actually simplifies quite a few projects for me. (No more mixing PHP, Perl, C, Python, MySQL and TCL on a single application - yay!;)
1) On home machines, *all* network accessible services should default off. In most cases, this will mean that remote exploits aren't going to happen - kernel level remote exploits are fairly rare. This means that if I port scan a machine out of the box, I should find 65535 closed TCP ports, and 65535 closed UDP ports. 2) On buisness workstations, all network accessible services should also default off, but the administrator should be able to provide a configuration to enable services needed for remote management. 3) Unneeded use of privledged accounts should be actively discouraged. M$ - consider defaulting to popping up "don't do anything stupid" reminders to users running with administrator rights under "end-user" versions of windows. Make it easier to obtain administrator rights when needed without having to log off and log back on. Educate users about the "Run As User" facility. 4) Operating systems designed for end users should have a facility to lock down the system temporarily while doing emergency maintainance, a "No services" mode if you will, which allows the user to obtain updates without being exposed while doing so. 5) While it can be argued that automatic updates are themselves a security risk, in practice, lack of updates are a far bigger risk. Anything thats remotely exploitable should be updated frequently and automatically by default. 6) Reboots are absolutely unacceptable to many users. Microsoft needs to work harder to eliminate unneeded reboots, *including* making changes to the way file locking works so that a reboot isn't needed to replace a file that's in use, or so that the affected subsystems can be stopped and restarted without restarting the entire system. 7) While blaster didn't use ActiveX, quite a bit of spyware and other ratware does. Fully executable web pages without any kind of sandboxing is a bad idea. Please, Microsoft, *disable* ActiveX out of the box, or require controls to be manually authorized by the administator by adding them to an "Allowed controls" list in the Tools -> Internet Options dialog - NOT as a pop up "Do you want to install and run" box. 8) Expand user education campaigns. Encourage users to obtain basic computer training, and a basic understanding of computer security. 9) Provide readily accessable documentation that adresses security concerns. Warning labels get old, but perhaps a big red "STOP: Please review this security information" is appropriate. 10) Discourage software developers from enabling network-accessible services automatically. (Hopefully the "new" Windows Firewall in SP2 will go a long ways towards making users aware of what they are running, but time will tell.)
In order to be able to compete for X-Prize later on, the craft is designed to carry 3 people. As this can be seen as a warm-up run for a later X-Prize attempt, I imagine he has quite a bit of weight allowance.
Scaled Composites seems to have done their homework. The craft has a double presure hull, is relatively small, and uses a propellant that is arguably more stable than what we burn in our cars. Any failure is more likely to result in an abort than in a catastrophe. SpaceShipOne has been tested extensively, and the design, although radical, is comparitively simple when viewed alongside early government funded sub-orbital flight.
Perhaps their real concern is that if the courts see them without any real products, then they are even less likely to take them seriously. As it stands, their entire buisness model revolves around half-baked lawsuits - not a good impression to present to the court.
Regardless, as SIGALRM stated above, its a moot point, without a continued inflow of support from the anti-Linux camps, SCO is dead.
> If your keys aren't in hardware such as a smart card then you aren't secure, you are just making people jump through hoops.
I'll respectfully disagree with this. As companies such as DirectTV can probably tell you, even a hardware solution can be compromised. Assume that any device an attacker can physically control can potentially be compromised. Hardware solutions may be more difficult to tamper with, but once a hardware system is cracked, for all practical purposes, it stays cracked. Sure, you can change the keys, but once someone has learned to extract the keys from the hardware, the keys will continue to be leaked. Software systems suffer from the same problems, and are easier to tamper with but the cost of changing the system is at least lower. Regardless, you should design your protective measures with the assumption that anything not under your direct physical control is definantly insecure.
I haven't looked at slackware in a long time, but one of the main reasons that I didn't take slackware seriously is that other distributions were shipping with effective package management facilities. Last time I paid any attention to slackware, it had a very limited package management system that was able to install pacakages, but provided no easy way to uninstall them. Does slackware have facilities for cleanly removing packages yet?
Password saving can be turned off. I think its on as a concession to lazy users.
To its credit, Firefox does have the option of securely encrypting saved credentials, but its buried:
Tools -> Options - Advanced - Certificates - Manage Security Devices is where its hidden in 0.8 - You can secure the saved credentials via a passphrase, or theroretically, via any PKCS#11 compatable security module, such as a smart card.
There are relatively low cost hardware security devices that are compatable with this standard, so if you need both security and convenience, the option is there.
A lot of idiotic webmasters exclude users by their user-agent string, or worse, display broken pages based on user-agent. After the first time a user has had to forge this as IE to get into a website, they probably won't change it back. So there are probably a signifigant number of users of alternative browsers that are masqurading as IE.
Firefox and mozilla support NTLM authentication on all platforms, and have done so for the past couple of releases. They don't however pick up credentials from the OS, so you have to log in seperately with firefox. This is a feature, as a browser that sends credentials before being asked to do so is a security risk.
To me, the biggest point in Firefox's favor its its security settings, and complete lack of support for activex (you can disable activex in IE, but it will keep bugging you every time an activex control tries to load - either in the form of confirmation dialogs or "this page may not be displayed properly" warning popups - really fun when some spyware ridden pages put themselves into a redirect loop if they detect that you rejected their crap, hoping that the user will get tired of the flood of confirmation dialogs and accidently click yes.)
I guess the best way to describe the difference between Firefox and IE is this: - With IE, web pages control the browser. They can open windows, close windows, hide your menu and toolbars, hide your status bar, and do god only knows what else. - With Firefox, the user in in control, including JavaScript security policies and popup controls that define EXACTLY what web pages can and can't do. And the cookie controls are second only to lynx (which had fine-grained control on cookies from the moment they added persistant cookie support;)
And don't get me started on IE's security record and how long IE bugs are public before M$ even admits they exist, much less fixes them...
I used to work for an ISP offering one way satalite internet. Needless to say, it was rather difficult to support, usually not because of problems with the reciever, but because of the dialup issues and TCP/IP stack problems courtesy of whatever spyware the users have downloaded.
As most of the issues that make one way satalite data delivery problematic for consumers don't exist for this type of application, it would seem like satalite technology is a good answer to the data delivery problem.
Time could be leased on commercial communications satalites, or maybe some sort of agreement to use idle capacity at reduced rates could be reached.
The reciever hardware for one way satalite systems is relatively inexpensive, in the $200-$500 range, so it would seem financially feasable as well...
Something similar to this is in place. Apparently, with the sheer volume of patents that are applied for, not every application gets commented on appropriately. Its much easier to bust a bad patent BEFORE it's granted though.
I don't know of any services that send out notice of pending patents, but the USPTO has a searchable database of pending applications at http://appft1.uspto.gov/netahtml/PTO/search-bool.h tml
Unfortunatly, I doubt that we are going to see many people switching to assembly language, but we can hope. I'd love to see a return to applications that were under 100K
Misuse of high level languages such as visual basic, as well as off the shelf components for everything, has led to a level of code bloat in todays applications that is inexcusable.
(note: off the shelf components and high level languages aren't inherently bad, just not always suitable for commercial applications.)
Also, given that modern optimizing C compilers can often optimize better than humans, it may make sense to embed critical sections of assembly into C code, and let the compiler optimize the rest...
Also, whatever happened to profiling? Has this become a lost art among developers? Time your code. See where it bogs down. Find the fat. Cut it out. Please.
-- This post brought to you by Save the CPU Cycles!
Ok. Face it. The script kiddies are going to find security holes eventually. Do the math. They have virtually unlimited time. For legitimate security researchers, its ALWAYS a race against the clock.
Some of the kiddies will release exploits publicly, some won't. Its quite possible with any exploit that someone has known about it for a signifigant amount of time. Depending on how inteligantly they make use of that knowledge, its possible to abuse an undisclosed exploit for a long, long time.
Face it, most systems aren't monitored by an IDS. Most users aren't logging traffic. Most users don't have to forensics knowledge to determine how they got compromised, hell most of them don't even bother to patch. They just reformat and start over, or worse, keep using the compromised system because they can't stand losing their mp3s or their email from aunt sally, are too incompetent to know how to back up the data they care about, and are too lazy to learn.
Until a scriptkiddie attacks someone who cares, or someone independantly discovers the same thing, they can keep using their exploit on as many systems as they like, for purposes such as building larger and larger DDoS armies.
>1. What are the odds of this actually being pulled off?
Its quite possible. Major long distance carriers already do this. There are some technical issues, but they can be addressed, and VoIP uses bandwidth way more efficiently than a circuit switched network, so long term, the cost benefits do appear to be there.
>2. How much will this effect me, a regular dialup and telephone user of British Telecom?
As a voice user, there may be initial problems with echo, garbled voice, and delay if BT doesn't do their homework. Those problems can usually be quickly alieviated in most cases by properly employing the QoS features typically provided by high end routers. A bigger issue is high speed modem use over VoIP, particularly if low bitrate codecs are used. Its possible that they could effectively cripple dialup ISPs without affecting voice quality in any perceptable way.. I don't know how the british communications regulations work, but here in the US, telcos can (with very few exceptions) do whatever they want to the lines so long as voice quality isn't affected (although they do have to support 9600bps data rates, who wants to surf at that speed.) Hopefully, they will keep in mind modem users, but they may decide this is a good time to force customers into broadband.
Looking at the costs/benefits of linux vs windows realistically, its easy to see where M$ gets some of their flawed conclusions, because they aren't entirely flawed, just not the complete picture.
The initial software cost is much higher for windows that linux.
However, *nix systems generally require more technical skill than windows systems to manage. That means *nix admins demand higher salaries.
Long term, the increased salaries are going to be more that the savings in software costs. Unfortunately, this is where Microsoft's analysis stops.
In terms of the man hours spent, Microsoft probably assumes the use of every available centralized management tool that they provide, and assumes it to work correctly. In the real world, administrators rarely make use of such tools for servers, except in extremely large scale enviroments. They are too complicated to set up initially, too difficult to learn, and they break frequently, because there is almost nothing for windows thats designed to be unattended.
The nature of a typical linux enviroment however, makes centralized administration much easier, *IF* the administrator sets the systems up properly to begin with. Thats where a large portion of the cost savings for linux comes in. If you are managing more than a handful of servers and don't have central patch & software distribution, configuration management, and central monitoring set up, you are probably wasting time and money.
Now, lets look at the security issue. Out of the box, linux and windows are arguably equally insecure.
*nix administrators work deeper into the guts of the system, and have a better understanding of how things interact. Linux, and other *nix systems don't have the black box mentality of windows, so with someone understanding both the system and the security issues, a VERY secure configuration can result, all the potential exposures can be understood, and risks can be kept minimal.
On the other hand, with windows, you see what microsoft wants you to see. With their history of hiding security flaws, and with the complexities of the system hidden behind a pretty GUI, its quite possible that there are less than a handful of people even at microsoft that know how it works and really understand how things interact. (Keep in mind that Microsoft has reportedly employed a highly compartmentalized development process, with very few people being allowed to see the whole of any project. They apparently don't even know whats going on with their own software.)
Bottom line from a cost factor, if all you have are one or two servers running windows, and you don't have a compelling reason to switch, don't. On the other hand, if you have a large number of servers to manage, you may be able to find a reason to switch, but look at the costs and benefits REALISTICLY, and plan well so that you actually save money.
From a security factor, every piece of software will have flaws. Those risks are easier to manage under linux, but they will be there. If you expect linux to be a magic bullet that makes all your security problems go away, it isn't.
Finally, if you decide to embark on ANY migration, do your homework. Make sure you understand what your network and servers are doing, and what buisness processes they support. Be prepared for unexpected dependancies, such as users storing files on network shares where you don't expect, or applications that have to talk to a program running on one of your machines. Most of these interactions won't be documented properly, even in a tightly controlled network.
Plan your deployment carefully, and implement centralized controls from the start, so that you avoid having to micromanage each server on a daily basis. Set up maintainance schedules. Don't neglect backups. A well planned linux deployment will save you money in the long run. A poorly planned one will be a bottomless financial pit.
My prefered method of securing a computer in this situation would be a Boot ROM that quickly restores the system to a pristine state every time its rebooted. Look at some of the solutions offered by Rembo, such as BpBatch.
Properly set up, the loader in the boot rom can validate the user-accessible partition against a reference copy on a hidden partition, then syncronize it rapidly in a manner similar to that of rsync. The renter has nearly unrestricted use of the system, but the second they reboot, its a clean system. If you want to be less anal, you could configure it so the wipe is only performed "on demand", or performed at the request of an off-premises master server, allowing the renter to store files while they are there, and have them wiped when they leave.
The sad thing about such disclaimers is that they may potentially interfere with measures that are actually EFFECTIVE - such as encryption and authentication. When disclaimers are added on by mailservers after leaving the client, this violates the integrity of the message, and will cause some encryption packages to reject the message as having been tampered with.
So by trying to get by with only false security, these companies may be rejecting REAL security.
While there are sometimes reasons to delay blacklist checks, the best (and probably the most common) current practice is to reject immeadiately, during the SMTP transaction, with a perminant failure code (usually 550). This failure message can be customized in most modern SMTP daemons, and on many SMTP daemons, its trivial to include TXT records from a DNS blacklist in such a custom message automatically.
In a configuration like this, the sender gets something like the following:
Your message could not be delivered because one or more recipients were rejected by the server. 550-Access restricted - Your host is currently blacklisted at: 550-dnsbl.example.com - See http://www.example.com/dnsbl/lookup.php?ip=127.0.0.1 550 You may contact postmaster@someisp.example.net for further assistance.
Such a message is not only informative to end users, but it also encourages senders of legitimate mail to make contact with an address that's been made exempt from filtering (mail to postmaster shouldn't be filtered, except in a denial of service situation, per various RFCs.)
Blocking later and sending bounces, or silently deleting (at least at the provider level) actually causes more problems than its worth - spammers will forge, so if you bounce later, you bounce to the wrong person, creating MORE spam, and silently deleting makes legitimate customers upset when mail doesn't go through, and makes troubleshooting missing mail very difficult.
AHBL usually takes the surgical approach, occasionally even punching holes in blocks to reduce collateral damage.
However, there's always been a special section for when thats been demonstrated to be unworkable.
This section requires extreme, prolonged abuse, or threats of legal action to get listed. Extreme problems do sometimes call for extreme measures. This isn't anything to take lightly, but for a surgical blacklist to maintain its effectiveness, it has to keep the option of larger blocks when nothing else will work. In this case, nothing else would work - the spammers were being allowed to move to unblocked address space faster than surgical blocks could keep up with them.
Rima-tde's long time treatment of abuse complaints has lead to them being labeled by many in the community as a rogue provider.
This has continued for quite some time, as evidenced by archived usenet posts (http://groups.google.com/groups?q=rima-tde&ie=UTF -8&oe=UTF-8&hl=en&btnG=Google+Search)
Getting up there along with the likes of HINET and Chinese state-run providers takes some serious work, and in goes to show Telefonica De Espana's commitment to its spammers!
Congratulations to them on this well deserved moment of (in)fame.
Slashdot Mirror
I currently work tech support for a small ISP, I'd say those numbers are about right, at least that many of the calls we get here are spyware related, some so severely that we have to refer the customer to their computer manufacturer to reformat and reinstall, or have the customer (assuming they are local) bring it in to our office to have it removed.
Many of the spyware programs out there now infect the system so deeply that none of the removal programs will manage to get rid of it, and some of its now being designed with properties of classic "stealth" viruses - ie, so that theres at least some component (usually a reinfector stub) thats not detectable while the process is running (intercepting system calls, etc so that you can't see it by normal means))
The problem's getting pretty ridiculous, and will only continue to get worse so long as we have browsers that treat web pages as if they were executable files, and users that click buttons on dialogs reflexively without even realizing they are there.
At this point, I spend as much as 10 hours a week just on spyware-related calls. That's insane, even with the peanuts I make working at a mom-n-pop ISP, thats real money. Now, if we can just find a way to bill the scumware companies for our time...
Given Bert Rutan's history with experemental aircraft, and the things that can go wrong with automated controls, fully manual flight controls only make sense. By keeping the controls simple, and by having avionics that tell the pilot what to do rather than do it for him, they reduce the expense, while improving pilot safety. Look at all thats gone wrong with NASA's massively redundant computer systems - if the flight computer on spaceshipone completely fails, chances are the pilot will still land the craft safely, and may even be able to complete the mission safely.
Hmm... A first post that wasn't a troll. I'm amazed.
;)
I've got a couple database applications using PHP that I've been working on for a while - I wasn't aware that PHP could be easily embedded into a C application.
Obviously, I'd get better performance with a hybrid of C and PHP code, so this actually simplifies quite a few projects for me. (No more mixing PHP, Perl, C, Python, MySQL and TCL on a single application - yay!
Thanks for pointing this out..
http://www.cnn.com/2004/TECH/space/06/21/suborbita l.test/index.html
1) On home machines, *all* network accessible services should default off. In most cases, this will mean that remote exploits aren't going to happen - kernel level remote exploits are fairly rare. This means that if I port scan a machine out of the box, I should find 65535 closed TCP ports, and 65535 closed UDP ports.
2) On buisness workstations, all network accessible services should also default off, but the administrator should be able to provide a configuration to enable services needed for remote management.
3) Unneeded use of privledged accounts should be actively discouraged. M$ - consider defaulting to popping up "don't do anything stupid" reminders to users running with administrator rights under "end-user" versions of windows. Make it easier to obtain administrator rights when needed without having to log off and log back on. Educate users about the "Run As User" facility.
4) Operating systems designed for end users should have a facility to lock down the system temporarily while doing emergency maintainance, a "No services" mode if you will, which allows the user to obtain updates without being exposed while doing so.
5) While it can be argued that automatic updates are themselves a security risk, in practice, lack of updates are a far bigger risk. Anything thats remotely exploitable should be updated frequently and automatically by default.
6) Reboots are absolutely unacceptable to many users. Microsoft needs to work harder to eliminate unneeded reboots, *including* making changes to the way file locking works so that a reboot isn't needed to replace a file that's in use, or so that the affected subsystems can be stopped and restarted without restarting the entire system.
7) While blaster didn't use ActiveX, quite a bit of spyware and other ratware does. Fully executable web pages without any kind of sandboxing is a bad idea. Please, Microsoft, *disable* ActiveX out of the box, or require controls to be manually authorized by the administator by adding them to an "Allowed controls" list in the Tools -> Internet Options dialog - NOT as a pop up "Do you want to install and run" box.
8) Expand user education campaigns. Encourage users to obtain basic computer training, and a basic understanding of computer security.
9) Provide readily accessable documentation that adresses security concerns. Warning labels get old, but perhaps a big red "STOP: Please review this security information" is appropriate.
10) Discourage software developers from enabling network-accessible services automatically. (Hopefully the "new" Windows Firewall in SP2 will go a long ways towards making users aware of what they are running, but time will tell.)
In order to be able to compete for X-Prize later on, the craft is designed to carry 3 people. As this can be seen as a warm-up run for a later X-Prize attempt, I imagine he has quite a bit of weight allowance.
Scaled Composites seems to have done their homework. The craft has a double presure hull, is relatively small, and uses a propellant that is arguably more stable than what we burn in our cars. Any failure is more likely to result in an abort than in a catastrophe. SpaceShipOne has been tested extensively, and the design, although radical, is comparitively simple when viewed alongside early government funded sub-orbital flight.
Good luck and Godspeed to the SpaceShipOne team.
Perhaps their real concern is that if the courts see them without any real products, then they are even less likely to take them seriously. As it stands, their entire buisness model revolves around half-baked lawsuits - not a good impression to present to the court.
Regardless, as SIGALRM stated above, its a moot point, without a continued inflow of support from the anti-Linux camps, SCO is dead.
> If your keys aren't in hardware such as a smart card then you aren't secure, you are just making people jump through hoops.
I'll respectfully disagree with this. As companies such as DirectTV can probably tell you, even a hardware solution can be compromised. Assume that any device an attacker can physically control can potentially be compromised. Hardware solutions may be more difficult to tamper with, but once a hardware system is cracked, for all practical purposes, it stays cracked. Sure, you can change the keys, but once someone has learned to extract the keys from the hardware, the keys will continue to be leaked. Software systems suffer from the same problems, and are easier to tamper with but the cost of changing the system is at least lower.
Regardless, you should design your protective measures with the assumption that anything not under your direct physical control is definantly insecure.
I haven't looked at slackware in a long time, but one of the main reasons that I didn't take slackware seriously is that other distributions were shipping with effective package management facilities. Last time I paid any attention to slackware, it had a very limited package management system that was able to install pacakages, but provided no easy way to uninstall them.
Does slackware have facilities for cleanly removing packages yet?
Password saving can be turned off. I think its on as a concession to lazy users.
To its credit, Firefox does have the option of securely encrypting saved credentials, but its buried:
Tools -> Options - Advanced - Certificates - Manage Security Devices is where its hidden in 0.8 - You can secure the saved credentials via a passphrase, or theroretically, via any PKCS#11 compatable security module, such as a smart card.
There are relatively low cost hardware security devices that are compatable with this standard, so if you need both security and convenience, the option is there.
A lot of idiotic webmasters exclude users by their user-agent string, or worse, display broken pages based on user-agent. After the first time a user has had to forge this as IE to get into a website, they probably won't change it back. So there are probably a signifigant number of users of alternative browsers that are masqurading as IE.
Firefox and mozilla support NTLM authentication on all platforms, and have done so for the past couple of releases. They don't however pick up credentials from the OS, so you have to log in seperately with firefox. This is a feature, as a browser that sends credentials before being asked to do so is a security risk.
To me, the biggest point in Firefox's favor its its security settings, and complete lack of support for activex (you can disable activex in IE, but it will keep bugging you every time an activex control tries to load - either in the form of confirmation dialogs or "this page may not be displayed properly" warning popups - really fun when some spyware ridden pages put themselves into a redirect loop if they detect that you rejected their crap, hoping that the user will get tired of the flood of confirmation dialogs and accidently click yes.)
;)
I guess the best way to describe the difference between Firefox and IE is this:
- With IE, web pages control the browser. They can open windows, close windows, hide your menu and toolbars, hide your status bar, and do god only knows what else.
- With Firefox, the user in in control, including JavaScript security policies and popup controls that define EXACTLY what web pages can and can't do. And the cookie controls are second only to lynx (which had fine-grained control on cookies from the moment they added persistant cookie support
And don't get me started on IE's security record and how long IE bugs are public before M$ even admits they exist, much less fixes them...
I used to work for an ISP offering one way satalite internet. Needless to say, it was rather difficult to support, usually not because of problems with the reciever, but because of the dialup issues and TCP/IP stack problems courtesy of whatever spyware the users have downloaded.
As most of the issues that make one way satalite data delivery problematic for consumers don't exist for this type of application, it would seem like satalite technology is a good answer to the data delivery problem.
Time could be leased on commercial communications satalites, or maybe some sort of agreement to use idle capacity at reduced rates could be reached.
The reciever hardware for one way satalite systems is relatively inexpensive, in the $200-$500 range, so it would seem financially feasable as well...
http://www.uspto.gov/web/offices/pac/mpep/document s/1900.htm
h tml
Something similar to this is in place. Apparently, with the sheer volume of patents that are applied for, not every application gets commented on appropriately. Its much easier to bust a bad patent BEFORE it's granted though.
I don't know of any services that send out notice of pending patents, but the USPTO has a searchable database of pending applications at http://appft1.uspto.gov/netahtml/PTO/search-bool.
Unfortunatly, I doubt that we are going to see many people switching to assembly language, but we can hope. I'd love to see a return to applications that were under 100K
Misuse of high level languages such as visual basic, as well as off the shelf components for everything, has led to a level of code bloat in todays applications that is inexcusable.
(note: off the shelf components and high level languages aren't inherently bad, just not always suitable for commercial applications.)
Also, given that modern optimizing C compilers can often optimize better than humans, it may make sense to embed critical sections of assembly into C code, and let the compiler optimize the rest...
Also, whatever happened to profiling? Has this become a lost art among developers? Time your code. See where it bogs down. Find the fat. Cut it out. Please.
--
This post brought to you by Save the CPU Cycles!
Ok. Face it. The script kiddies are going to find security holes eventually. Do the math. They have virtually unlimited time. For legitimate security researchers, its ALWAYS a race against the clock.
Some of the kiddies will release exploits publicly, some won't. Its quite possible with any exploit that someone has known about it for a signifigant amount of time. Depending on how inteligantly they make use of that knowledge, its possible to abuse an undisclosed exploit for a long, long time.
Face it, most systems aren't monitored by an IDS. Most users aren't logging traffic. Most users don't have to forensics knowledge to determine how they got compromised, hell most of them don't even bother to patch. They just reformat and start over, or worse, keep using the compromised system because they can't stand losing their mp3s or their email from aunt sally, are too incompetent to know how to back up the data they care about, and are too lazy to learn.
Until a scriptkiddie attacks someone who cares, or someone independantly discovers the same thing, they can keep using their exploit on as many systems as they like, for purposes such as building larger and larger DDoS armies.
>1. What are the odds of this actually being pulled off?
Its quite possible. Major long distance carriers already do this. There are some technical issues, but they can be addressed, and VoIP uses bandwidth way more efficiently than a circuit switched network, so long term, the cost benefits do appear to be there.
>2. How much will this effect me, a regular dialup and telephone user of British Telecom?
As a voice user, there may be initial problems with echo, garbled voice, and delay if BT doesn't do their homework. Those problems can usually be quickly alieviated in most cases by properly employing the QoS features typically provided by high end routers.
A bigger issue is high speed modem use over VoIP, particularly if low bitrate codecs are used. Its possible that they could effectively cripple dialup ISPs without affecting voice quality in any perceptable way.. I don't know how the british communications regulations work, but here in the US, telcos can (with very few exceptions) do whatever they want to the lines so long as voice quality isn't affected (although they do have to support 9600bps data rates, who wants to surf at that speed.) Hopefully, they will keep in mind modem users, but they may decide this is a good time to force customers into broadband.
Looking at the costs/benefits of linux vs windows realistically, its easy to see where M$ gets some of their flawed conclusions, because they aren't entirely flawed, just not the complete picture.
The initial software cost is much higher for windows that linux.
However, *nix systems generally require more technical skill than windows systems to manage.
That means *nix admins demand higher salaries.
Long term, the increased salaries are going to be more that the savings in software costs.
Unfortunately, this is where Microsoft's analysis stops.
In terms of the man hours spent, Microsoft probably assumes the use of every available centralized management tool that they provide, and assumes it to work correctly. In the real world,
administrators rarely make use of such tools for
servers, except in extremely large scale enviroments. They are too complicated to set up initially, too difficult to learn, and they break frequently, because there is almost nothing for windows thats designed to be unattended.
The nature of a typical linux enviroment however, makes centralized administration much easier, *IF* the administrator sets the systems up properly to begin with. Thats where a large portion of the cost savings for linux comes in. If you are managing more than a handful of servers and don't have central patch & software distribution, configuration management, and central monitoring set up, you are probably wasting time and money.
Now, lets look at the security issue. Out of the box, linux and windows are arguably equally insecure.
*nix administrators work deeper into the guts of the system, and have a better understanding of how things interact. Linux, and other *nix systems don't have the black box mentality of windows, so with someone understanding both the system and the security issues, a VERY secure configuration can result, all the potential exposures can be understood, and risks can be kept minimal.
On the other hand, with windows, you see what microsoft wants you to see. With their history of hiding security flaws, and with the complexities of the system hidden behind a pretty GUI, its quite possible that there are less than a handful of people even at microsoft that know how it works and really understand how things interact. (Keep in mind that Microsoft has reportedly employed a highly compartmentalized development process, with very few people being allowed to see the whole of any project. They apparently don't even know whats going on with their own software.)
Bottom line from a cost factor, if all you have are one or two servers running windows, and you don't have a compelling reason to switch, don't. On the other hand, if you have a large number of servers to manage, you may be able to find a reason to switch, but look at the costs and benefits REALISTICLY, and plan well so that you actually save money.
From a security factor, every piece of software will have flaws. Those risks are easier to manage under linux, but they will be there. If you expect linux to be a magic bullet that makes all your security problems go away, it isn't.
Finally, if you decide to embark on ANY migration, do your homework. Make sure you understand what your network and servers are doing, and what buisness processes they support. Be prepared for unexpected dependancies, such as users storing files on network shares where you don't expect, or applications that have to talk to a program running on one of your machines. Most of these interactions won't be documented properly, even in a tightly controlled network.
Plan your deployment carefully, and implement centralized controls from the start, so that you avoid having to micromanage each server on a daily basis. Set up maintainance schedules. Don't neglect backups. A well planned linux deployment will save you money in the long run. A poorly planned one will be a bottomless financial pit.
My prefered method of securing a computer in this situation would be a Boot ROM that quickly restores the system to a pristine state every time its rebooted. Look at some of the solutions offered by Rembo, such as BpBatch.
Properly set up, the loader in the boot rom can validate the user-accessible partition against a reference copy on a hidden partition, then syncronize it rapidly in a manner similar to that of rsync. The renter has nearly unrestricted use of the system, but the second they reboot, its a clean system. If you want to be less anal, you could configure it so the wipe is only performed "on demand", or performed at the request of an off-premises master server, allowing the renter to store files while they are there, and have them wiped when they leave.
The sad thing about such disclaimers is that they may potentially interfere with measures that are actually EFFECTIVE - such as encryption and authentication. When disclaimers are added on by mailservers after leaving the client, this violates the integrity of the message, and will cause some encryption packages to reject the message as having been tampered with.
So by trying to get by with only false security, these companies may be rejecting REAL security.
While there are sometimes reasons to delay blacklist checks, the best (and probably the most common) current practice is to reject immeadiately, during the SMTP transaction, with a perminant failure code (usually 550). This failure message can be customized in most modern SMTP daemons, and on many SMTP daemons, its trivial to include TXT records from a DNS blacklist in such a custom message automatically.
0 .1
In a configuration like this, the sender gets something like the following:
Your message could not be delivered because one or more recipients were rejected by the server.
550-Access restricted - Your host is currently blacklisted at:
550-dnsbl.example.com - See http://www.example.com/dnsbl/lookup.php?ip=127.0.
550 You may contact postmaster@someisp.example.net for further assistance.
Such a message is not only informative to end users, but it also encourages senders of legitimate mail to make contact with an address that's been made exempt from filtering (mail to postmaster shouldn't be filtered, except in a denial of service situation, per various RFCs.)
Blocking later and sending bounces, or silently deleting (at least at the provider level) actually causes more problems than its worth - spammers will forge, so if you bounce later, you bounce to the wrong person, creating MORE spam, and silently deleting makes legitimate customers upset when mail doesn't go through, and makes troubleshooting missing mail very difficult.
AHBL usually takes the surgical approach, occasionally even punching holes in blocks to reduce collateral damage.
However, there's always been a special section for when thats been demonstrated to be unworkable.
This section requires extreme, prolonged abuse, or threats of legal action to get listed. Extreme problems do sometimes call for extreme measures.
This isn't anything to take lightly, but for a surgical blacklist to maintain its effectiveness,
it has to keep the option of larger blocks when
nothing else will work. In this case, nothing else would work - the spammers were being allowed to move to unblocked address space faster than
surgical blocks could keep up with them.
Rima-tde's long time treatment of abuse complaints has lead to them being labeled by many in the community as a rogue provider.
This has continued for quite some time, as evidenced by archived usenet posts (http://groups.google.com/groups?q=rima-tde&ie=UT
Getting up there along with the likes of HINET and Chinese state-run providers takes some serious work, and in goes to show Telefonica De Espana's commitment to its spammers!
Congratulations to them on this well deserved moment of (in)fame.