Slashdot Mirror
Throttling Computer Viruses
An anonymous reader writes "An article in the Economist that looks at a new way to thwart computer viral epidemics, by focusing on making computers more resilient rather than resistant. The idea is to slow the spread of viral epidemics allowing effective human intervention rather than attempting to make a computer completely resistant to attack."
Start writing secure software!
I'm not joking. The #1 rule of computer science is that computer scientists are lazy.
We need to stop working just to accomplish the minimal functionality desired and start testing the hell out of our software to ensure that it's secure.
If you celebrate Xmas, befriend me (538
Antivirus software makers are recycling some old tricks to combat computer viruses proliferating over the Internet.
The technique, called "heuristics," checks for suspicious commands within software code to detect potential viruses.
Heuristic techniques can detect new viruses never seen before, so they can keep malicious code from spreading. An older method, called signature-scanning, uses specific pieces of code to identify viruses.
Both methods have down sides. Heuristic techniques can trigger false alarms that flag virus-free code as suspicious. Signature-scanning requires that a user be infected by a virus before an antivirus researcher can create a patch--and the virus can spread in the meantime. Most antivirus vendors use both techniques.
It's time for the industry as a whole to look at different approaches The time-honored method of signature scanning is a little worn and weary given new viruses coming out
"This must be a Thursday, I never could get the hang of Thursdays."
Doesn't current human interaction show that it only stimulates viral spreading , by opening emails and running stuff because it says "I love you" not to mention the spreading of emails "warning new virus delete file foo.exe?"
This is an excellent idea. For a long time the fight against computer viruses (as well as many other aspects of computer security) has been focused on winning or losing, period. Try to stop the virus, and that's it. But what about what happens when a virus gets through? Like almost all things in computer security, there hasn't been enough attention given to what happens if security fails. Bruce Schneier has been yelling from the mountain that security is as much about what happens when safeguards don't work as it is about making sure they do. The notion of being able to keep a virus in check to a certain degree is a good example of security that can fail gracefully when a new virus comes around.
For your security, this post has been encrypted with ROT-13, twice.
Could you imagine how slow Slashdot would be at one connection per second? How well could this work on high traffic sites?
It would probably save other sites from being Slashdotted, though.
Hrm... well, it might have some benefit for things like Nimda, but it won't do anything for nasties that spread via email. If this becomes a default in a future version of Windows, though, you can bet that any virus meant to propagate by opening outgoing connections will just self-throttle, or disable the feature first. Already there is precedent for this, such as Bugbear that disables software firewalls so it can get out and spread.
I would much rather see effort spent educating people to install security related patches regularly and turn off unused services, and push vendors towards "secure by default."
semi-anti-virus programs that "hold" the virus in until Joe Blow computer user comes in, and accidentally releases the virus into his machine.
"Some fight for law. Some fight for justice. What will you fight for? One day, you will see."
I think the issue at hand is a more global issue faced when writing applications.
Software is expected to behave 100%. How many of the developers here have had some strange bug, that may only appear in 1 out of every million users (not instances, otherwise it would happen in less than a second in most all modern processors). Then we are asked to fix it.
This solution is great, throttle the computer, lose that 2% of all connections being instantaneous, but then it won't be perfect.
I think we have to more realistically analyze the needs of modern software, and accept that it can "fail" to an acceptable degree if we want some superior functionality.
The human brain is great, but it fails (quite too much for myself). IBM is annoucing building a computer that could simulate the human brain, but it won't reap the rewards of our brains, until it's willing to give in to the issues that we face, uncertain failure.
With our "uncertain failure", look how great we are at calculating PI to the 100th digit (well, normal individuals anyway). Our brains certainly couldn't calculate nuclear simulations with the "uncertain failure"
We will probably have to split "computer science" into the "uncertain failure, superb flexibility" and the "perfect, 99.999% of the time" categories.
This sounds great for the "uncertain failure" group.
A lot of the vulnerabilities of these systems are things that are just downright idiotic, in my opinion. We've made programs that don't really need to talk to the outside world able to do so (Word, Excel), and we've given programs that shouldn't be able to control the filesystem and other aspects of the system that privilege (Outlook, Internet Explorer). During the Summer I managed to have Internet Explorer install software for me (.NET Platform).
Why do we not look at applications and give them a domain before we just open the floodgates? Why not just say, "hey, email comes from the outside world, I don't trust the outside world, so I won't let my email client do anything it wants to". I know that this wouldn't stop all of these problems, but I think the general idea would circumvent many virii.
Give your switches enough memory and let them keep a history of 20 IP addresses per host. (this number needs to be tweaked according to usage of course) When you get a IP packet going to a new host, record the address and start a 1-second timer. While the timer runs, drop all IP packets to hosts not on the list.
The packets you drop will be resent, and you get the wanted behaviour.
Another advantage is that you only need to change the switches, not the systems.
Only problem I can see: What about web pages with lots of images from different servers? Those will take forever to load. You could tell everyone to use a proxy, but you wouldn't be able to run this throttling on the proxy...
How about some Outlook awareness classes?
...it is rarely up to the implementors to decide. The project has a budget which is too little, and there is a schedule, which is too tight, and everyone else not in the project expects to see miracles.
Since only TCP has the idea of connections only this protocol can be protected from abuse in this way. Others such as UDP/ICMP etc send their data in descrete packets (as far as the OS is concerned, whether the app client-server system has the idea of connections over UDP is another matter) and if you limit these to 1 packet a second you can kiss goodbye to a whole host of protocols because they simply will not work effeciently or at all any longer. All his idea will do is cause virus writers to use protocols other than TCP. For macro viruses this could be a problem (does vbscript support UDP?) but for exe viruses its no big deal I suspect.
If this is on individual computers, I can't see "human intervention" being effective. It might certainly slow the progress of a worm, but I can just see someone getting a pop-up box "Your machine appears to be infected with a virus, should I delete it?" and someone sitting there and hitting "No."
It would probably be more effective as some kind of network device/firewall that eats excessive network connection requests, then lets the administrator know that computer X appears to be infected (bonus points for inspecting packet content to determine type of infection).
In fact, that implementation isn't new, I recall seeing a computer setup at a colocation site setup to inspect http traffic and blocked http requests that looked like code-red infection attempts.
If I have been able to see further than others, it is because I bought a pair of binoculars.
Hackers/kiddies/whomever are annoyingly clever at times. My assumption is that someone may be able to take advantage of a throttle to compromise legitimate traffic.
Since that's what exploits are all about, I have absolutely no doubt someone will try it if such defenses become commonplace.
Yes, this will slow down the spread of viruses -- but the article makes a big deal of the fact that a throttled system can detect the attempts to rapidly make many network connections, setting off an alert. Of course, as soon as people come to count on this as their primary form of virus detection, a virus will be written that only attempts one connection a second, and then, very slowly it will spread undetected on those systems that rely on the throttle for detection. And we know there will be people who rely on it exclusively . . . .
In short, this guy's idea for curbing infection rates of &pluralize("virus"); is to restrict systems network access to one new host per second. Exceptions would be made for high demand, known servers, such as mail server and (I presume, even though it wasn't in the article) HTTP or SOCKS proxies. Interesting idea, and it would help in slowing down the infection of, say, Nimba or Code Red.
.exe/.com infectors, or boot sector infectors. The article fails to mention the Hows of this throttling; is it based on the routers (in which case quick infection of the local subnet would take place) or on the switches (which could break most broadcast applications, not to mention mean all systems outside the subnet look the same) or in the OS (in which case the virus could put its own TCP/IP stack in to replace the throttled one, and end up with no throttling affects whatsoever).
I can't help but think that his logic is flawed however. For example, most corporate headaches come from email based virii. If the only connections needed for the virus to spread is the email server it already has access to, there is no delay for the emails to be sent out to the mail server. No one could request for the email server to be throttled and keep their job, so the infected emails would be sent out, with no perceptable delay caused by the throttling.
The only thing this might help with is worms only, no virii in the more common sense such as email based LookOut virii,
How about, instead of throttling network access, we move to more reliable code, better access controls at the kernel level, and a hardware platform that makes buffer overruns and stack smashing a thing of the past. While I am anti-MS, Palladium does actually have some good ideas on the hardware level. Is the DRM level that stinks to high heaven.
Toodles D. Clown
When do we see this in iptables ??
In Murphy We Turst
This is like banging your head with a hammer and wearing a thick, foam rubber hat so it doesn't hurt as much.
Strange women lying in ponds distributing swords is no basis for a system of government.
Web-based message boards -- Several of the message boards that I'm on allow users to include inline images. However, the users are responsible for hosting the images on their own servers. So a given page full of messages could easily add an extra 10 hosts to the "fresh contact" list, causing a 10 second delay. Furthermore, at least one of the message boards has a large enough user population that the "recent contact" list wouldn't help out enough at reducing the delay.
Half-Life -- The first thing Half-Life does after acquiring a list of servers from the master server list is to check each one. For even a new mod (like Natural Selection), this can be hundreds of servers. For something popular (like Counter-Strike), it's thousands.
Further it should be (putting on fire suit) a function of the government to finance an independent system to publicize standardized virus recognition fingerprints. Then it should be integral to the operating system to run a scan as part of the executable load function. This would be justified as protecting commerce. This won't solve the problem of "script" viruses that play off the integration features of Microsoft products but that can be dealt will by requiring Microsoft to produce products that actually ask for permissions from the user before doing stupid stuff. Sometimes a parent just has to take control of their offspring. Either that or firewall off anyone using Microsoft products, most of them are so non standard they aren't hard to recognize. Many places don't let Microsoft attachments go through and it has saved them a lot of lost time. XML and other standard formats work just fine and are interoperable with other systems.
Do unto others as you would have done to yourself, don't let America become like Israel. It is un-American to support human rights violations, support justice in Palestine.
How about, instead of throttling network access, we move to more reliable code, better access controls at the kernel level, and a hardware platform that makes buffer overruns and stack smashing a thing of the past. While I am anti-MS, Palladium does actually have some good ideas on the hardware level. Is the DRM level that stinks to high heaven.
I've got good news for you. The average free *nix already has more reliable code with better access controls at the kernel level. You can check it out for yourself because the software is free, unlike that other silly stuff you mentioned from a particular abusive and convicted vendor, caugh, MicroSoft. Heck, you could even just use a mail client that does not run as root and does not automatically execute commands sent from strangers, like most free software. Way to go!
I've also got bad news for you. Buffer overflows can not be defeated at the hardware level in a general purpose computer. Why is left as an exercise for the reader, but a shortcut is that Microsoft says it will work.
Friends don't help friends install M$ junk.
would probably just look at the IPs commonly in the history file, and put in the entire range of IPs for that subnet, then begin making connections. once you're infected, you're screwed. the same as we have viruses that currently disable firewalls, we also will have viruses that circumvent this as a matter of routine...
PC moderators can suck my White pierced, tattooed dick. If you think pride == hate, s/dick/Aryan meat mallet/g.
The only reason a virus doesn't wipe your
hard disk out is because it's making use
of the computer to infect others. If this
idea goes into use, guess how long it'll
take before a virus spreads in a manner
where it doesn't crash machines that let
it spread, but totally destroys those that
don't.
I think you better kill the virus, or
you're only likely to piss it off...
How soon we forget that the stronger we make our antibiotics, the stronger our viruses become.
TodayTM BillyJoelTM GoogleTMd for StitchTMes due to WindowsTM while RollerbladeTMing with an AppleTM and a PopsicleTM