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?"
I must think on this.
is to launch global network monitoring, perhaps monitered by a reputable security company like mi2g. It would require nodes at pretty much all internet connections, of course, at could be costly, but the cost is miniscule compared to the savings. Then that company could record traffic and, once a virus propogates, backtrack through teh logs for the first time it appears. From there, we could find the originator and bring the full weight of the maw on him.
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.
m00.
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.
Hmm... Gibson's AI intrusion countermeasures coming to life?
I just got an image of him presenting his paper, and pointing to each audience member, "patent pending, patent pending, patent pending" ala Homer Simpson.
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."
The author refers the different behaviour of a computer infected by a virus as a way to detect the virus. What the author says is that a virus will try to make connection to as many comouters as possible. This different behaviour is then monitorized by a system and someone somewhere is informed of the presence of the virus.
But to have this system installed you will be giving someone an authorization to see your computer use profile, giving away your privacy. And it will not detect most virus that are only interested in destroing your data and/or spam your friends via email.
------I can please only one person per day. Today is not your day. Tomorrow isn't looking good either.------
Tries desparately to think of something interesting to say about this post, other than, "cool", "why didn't I think of that" etc. Fails.
Tries desparately to resist temptation to mention FirstPost. Fails.
Tries to think of something else to discourage moderators from hitting the thumbs down button. ??
Skiing? Check out The Independant Skiers Portal
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."
If the throttle is implemented on the same machine as the virus, the virus writers will turn it off.
:-)
If it becomes a widespread implementation on the upstream routers, then virus writers will throttle their own connections to 1 per second to evade detection.
This defense was only tested against Nimda, and other viruses may work other ways. Will it stop email virii?
Makes the Warhol worm a bit harder to implement though
...where are the details. What kind of heuristics is this 'throttle' using? Do they look for disparate connections, like 100+ individual hosts per minute, or simply just for connections outside of a tripwire-esque 'connection profile' for the machine? What kind of protocols does the throttle watch?
I really enjoy the Economist, but this article is so shallow and fluffy, especially for them.
Nice going, turd for brains. No wonder Slahsdot's such a pile of shite these days.
The article basicly says that it wants user intervention when it connects to a new/unknwon computer it hasn't connected to before. So the virus could still spread to it's known list?? What if you run kazaa? The program would block outgoing connections.. I know which one is going out of the window first..
Here's Williamson's paper on the idea: Throttling Viruses: Restricting propagation to defeat malicious mobile code I haven't read it yet, but I see one potential problem right away. When you load a web page, you normally make quite a few connections--one for each image, e.g. I'll have to see how he handles that
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.
/me can see the flames mentioning X+KDE and X+Gnome's speeds being slow as well decending upon him. @_@
Any sufficiently advanced influence is indistinguishable from control.
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.
The current method of paying a mandatory annual fee to one of the anti-virus companies seems almost like an inherent conflict of interest, much as plumbers used to install pipes that easily corrode in a few years. We're always playing catchup, and I have an *extra* annual fee for each of my computers connected to the internet.
Searching and scanning for new viral signatures are not a final solution. The real solution is a transparent system where processes running are recognized by the operator, much as you recognize a familiar face when the mailman comes to the door.
I have so many services/processes running on WinXP that I have no idea what half of them do, but I can't turn them off, or something won't work. Seems like virus authors hardly have to try to find ways to exploit millions of systems with a single outbreak.
To those working on a different solution, thanks in advance.
attention virus writers: There is a new technology on the horizon. It hasn't been implemented yet. You only have a year or 2 to figure out a way around this.
We've got malware that now disables personal firewall software so as to avoid detection. This throttle might be an effective patch against current viruses, but the next round will simply work around the throttle, if it is applied locally.
Of course the article doesn't really say whether this is enforced on the local machines or is applied from outside (i.e. at a switch or router). However, by talking about it as an inoculation, it suggests it really enforced on the local machine.
It's a good idea, in general, but it has to be user-tweakable, and that means it's virus-tweakable too.
People are never as simple as their stereotypes. This applies equally to Christians, Muslims, and Emacs-lovers.
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...
Run Windows! That'll slow things down. Maybe it would slow down the spreading of viruses too?
I think we should go back to having fun hacking up new programs and having a hell of a time debugging them instead of just throw it out for money so the consumer can just buy it and it get rated like crap or midgrade to another program and becomes another victim
How about some Outlook awareness classes?
The idea, then, is to limit the rate at which a computer can connect to new computers
Hope this throtlling doesn't adversely affect p2p apps.
...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.
Wouldn't it be more accurate to say "operating systems"? Of course the article appeared in a mainstream, non-techinical journal so I guess:
Of course some "computers" are already resitant to virii (viruses?):Worms on the other hand...
[SARCASM]
...um.... basket weaving!
Prevent the spread of viruses, make computers more secure, enjoy life in the Real World, spend more time with your family & loved ones!
All this and more can be yours! Support Neo-Ludditism - break your computer today!
No computers means no computer problems!
Just imagine a profitable new career in
[/SARCASM]
There are a thousand forms of subversion, but few can equal the convenience and immediacy of a cream pie -Noel Godin
In the time that it takes a technician to swig a mouthful of cold coffee and clear the boxes of congealed pizza from his desk,
Ha Ha Ha!
Fscking hell, I just spit Mountain Dew all over the chinese food delivery guy...
Reminds me of a "game" inside a MUD I once played (god, that is sad. Better make this an anonymous post)
The computer tried to guess a number you had in your head. It went like this:
Is it 6?
>no
Is it 6?
>no
Is it 6?
>no
Is it 6?
>no
Is it 6?
>no
Is it 6?
>yes
AHAHAHAAAA! I WIN! YOU LOSE! I'M THE BEST!
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.
Virii thought: Woohoo, I got in a machine!
.............
Windows: "Are you a dll?"
Virii thought: "Umm... Yes. I like Outlook."
Windows: "Okay, hang on..."
Launches Outlook...
Virii thought: "Why is everything blue?"
Windows:
Virii thought: "Oh, if only I had hands!!!"
It will be easy to motivate our fellow man; there is hardly anything people treasure more than not being annihilated.
I don't get the joke there at all. Can someone show me where it is?
Why the virus or the worm should respect any restriction brought by the operating system? Doesn't it make more sense to prevent the connection at the computer that is attacked rather than attacking computer? But then how do you distinguish an attack using eg.SSL from a legitimate connection?
ato
This is designed to slow self spreading worms like Nimda. The idea is to reduce the number of new connections a computer can make to computers it's never talked to before. There's nothing about how an O/S could actually enforce this.
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.
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
Warning: Anivirus program detected recent installed software has caused computer slowdown and transmission of unknown packet to www.microsoft.com
Possible cause: Microsoft software.
Advise: Do not trust Microsoft
Solution: Install GNU/freeware alternatives.
You might have heard of it, it was called "Clippy"
why not just stop the anti-virus companies from making all the virus's in the first place?
I mean, they make money on sales of anti-virus software, without any kind of regulation, hell with the way corporate america is already going, who says its not a big scam anyhow?
"an eye for an eye only makes the whole world blind"
[Are you sure you want to do this]
[Are you certain]
[press enter to exit]
[press escape to continue]
The"annoy the user to death" virus has already hit!
I'm sure this sounds like a good idea to some people, but I'm not convinced.
The idea, then, is to limit the rate at which a computer can connect to new computers, where "new" means those that are not on a recent history list. Dr Williamson's "throttle" (so called because it is both a kind of valve and a way of strangling viruses at birth) restricts such connections to one a second. This might not sound like much to a human, but to a computer virus it is an age.
This sounds to me like the idea is to basically make the tcp/ip stack single threaded.
Ok smart guy, so lets use an http request as an example. Loading a web-page, a browser could theoretically make several connections to several different servers. So, with our single threaded, "throttled" tcp/ip stack, a simple web page could take several seconds to load, at least until the server on the other end is in the "history".
Ok, so this "history" as the document describes... where is it kept? Hard drive? RAM? So, for every outgoing connection, the machine needs to check the address against a table somewhere... this is added overhead. Lets say that the address needs to be resolved... well, then we need to go through this process a second time just for the DNS server.
So, this "Doctor Matthew Williamson" of HP... is he full of crap? I dunno -- I don't have a phd.
Skiers and Riders -- http://www.snowjournal.com
The basic idea of "find ways to strangle virii" is a good one. I think he's onto something here, something so obvious it wasn't obvious. Even if his technique slowed virii down only a few percent, the spread over time would be much lower.
However, this is really only one idea. Its value is in pointing out that to deal with an age of virii, unreliable web pages, email viruses, trojans, bad firewalls, and everything else that didn't exist fifty years ago, we need to think in radically different methods.
The greatest value of this research is really going to be how it gets people to take a new look at computing. And for that, I say, it is about time. Our ideas for dealing with computer troubles need to evolve since the troubles we're facing continue to occur, spread, and change.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
We would turn you in to the KGB and take bets on how long it would be before you died in the Gulag.
Unfortunately I don't know much about P2P protocols, but wouldn't this tend to slow them down a bit? How many connections does Gnutella (for instance) throw out per second?
Why not propagate the 'fix' the same way the virus itself propagates? We know the virus is efficient as hell, surely the fix in assembler can't be much bigger than the virus?
Actually the parent post talked about stopping DDoS.
A Distributed Denial of Service is done by hijacking many user boxes and from each bombarding a server with hundreds of bogus requests per second. This throttle would likely choke that (unless the server being DDoS'd is on this users list of known servers)
Perhaps we could somehow throttle Microsoft and limit them to releasing one new OS every 5 years or so. Maybe that would give us enough time to patch all the Gaping Security Holes.
Say something critical about Micro$oft and you get modded down at once... when did Slashdot turn into Micro$oft's bitch? Heck, they're showing M$ ads for chrissakes!
When do we see this in iptables ??
In Murphy We Turst
I support the notion that the key to ultimate security lies in the quality of the code. I'll go further and say that open source is the key to reaching the absolute goal of inpenetrable code. The open source model is our best bet at insuring that many, many eyes (with varying degrees of skill and with different intentions) will scan the code for flaws. I just wish that some of the more popular open source projects were more heavily reveiwed before their latest builds went up.
:w :w :w :w :w :q
wrote file, 10 lines 200 chars
What about when I'm viewing Fark in Moz and middle-clicking (open in new tab) links at a furious pace? Or, even worse, using mouse gestures to drag over 5-10 links and simultaneously open them all in new tabs? In the particular case of Fark, the initial request for each link will go through the fark.com domain (for nav statistics, I suppose), but is immediately forwarded on to another domain.
Really, I guess those requests could be handled at 1 second or, preferably, user-specified intervals. I can't imagine viewing the requested documents (more likely images, if we're being honest here) at a faster pace, anyway.
One of the reasons that I became a lawyer was to avoid ever having to hire one. -SPYvSPY
Yeh i know we've all heard this before, "Virii is not the plural form of virus". But in case anyone is interested this site has a good explanation why.
Whats the plural of 'Virus'?
I think this could be a good thing on desktop machines. On the serverside it is much simpler. Make sure that your servers are not allowed to make connections to the outside world. A webserver doesn't have any reason to do a connection to the outside world. It should just sit and wait for a new connection to happen from the outside and send the data down that channel. It should never contact the outside world itself.
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.
Don't blame my application because you download the latest screen saver that is infected.
Insecure software doesn't even start to facilitate the spread of viruses, historically or today. And questionable functionality, where the insecurity was planned, facilitates the spread of most worms or internet viruses. Stupid users running infected code is where the problem lies, the OS did what it was supposed to.
Maybe the next thing you will suggest is stopping fire bugs by making non-flamable fuel.
The history list is automatic - There is no actual direct user intervention, it just happens that throttling makes it painfully obvious to the user that something has gone horribly wrong.
The throttle rules are most likely something like this:
Have I connected to this host in the past x minutes?
Yes -> Originate as many new connections to that host as I want, as fast as I want.
No -> Have I made a connection to a new machine in the last second?
Yes -> Wait 1 second.
No -> Go ahead, make a connection and put this host in history list.
Anything else would cause a problem even in normal usage.
Note: This is only applied to outgoing connections, not incoming connections (So servers wouldn't be affected unless they were infected and suddenly tried to make lots of outgoing connections.)
Interestingly, this would put a major damper on spammers abusing open relays. One would probably have to increase the speed limit for normal mailserver operation, but even "sane" speeds would be enough to severely retard spammers except for the largest of mailservers.
It wouldn't work if the spammer had control over the machine doing the worst of the gruntwork, though - He could just kill the throttle. But most of the time the dirty work is done by some unsuspecting open relay.
retrorocket.o not found, launch anyway?
There isn't any user intervention involved in the actual operation of the throttling system. It's automated. Basically, once you connect to a machine, it's whitelisted for a period of time.
.1-second delay instead. Much faster for KaZaA, but still a major slowdown for viruses.)
The only "user intervention" is the fact that once a virus starts opening outgoing connections like crazy, the user will perceive severely reduced system performance.
Not even a Gnutella client starting up and searching for other hosts can come close to the number of connections many virii open up. (Although it may be useful to whitelist certain apps as having permission to connect faster - They still should be throttled, but maybe 1 second for all apps but you can give Kazaa permissions for a
retrorocket.o not found, launch anyway?
Like any other type of security strategy, a proper one should have several layers of defence. I think this idea is an excellent one, and would serve well as one layer in a complete strategy. Another good layer might be trapping. Of course heuristics and signature scanning should be used as well. The most important layer of all IMHO... training. Human training.
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.
I remember back .. 10 years back.. actually 5 or 6. Assembly written viruses were rampant. Everyone knew what they were and were more likely to find some way to prevent it. Once a week i had a bootsector virus detected that needed to be cleaned from floppies and hard drives. Virus cleaners were rampant and they nagged you somewhat when they were ot of date. They even gave you instructions how to update sometimes.
.. surprising. Popping up messages like, "I could have formatted your computer because of XXX, go fix it by doing... "
Let's fast-forward. Today, OS's only seem more secure, they aren't. We don't get loads of virus software floating about like we used to. More people don't know about viruses than do... and what's worse, they are less viruses about that do more damage.
I'm also surprised that intrusion detection systems don't have nag screens which are attached to daemons to let you know that your software needs to be updated, or you are fucked.
Servers should be required to run a small cron job'd progoram like Nessus (search freshmeat), which would nag you when the data is old. snort, the ids software should do the same.
For the lack of viruses, we need whitehats to write exploits that aren't damaging but are
Maybe if people were made more aware that the computing world isn't all plug-n-play, bells and whistles, that you are using a device that needs care.
-
ping -f 255.255.255.255 # if only
If virus writers restrict outbound connections to 1 per second, while we lose the detection advantage of this scheme, we've STILL slowed the virus down. A virus opening a new connection per second can't spread nearly as fast as one that can open up hundreds.
retrorocket.o not found, launch anyway?
It's not a limit of one new connection per second, but a new connection to an UNKNOWN HOST per second.
i.e. if you've opened an outbound connection to that host already in recent history - No speed limit.
retrorocket.o not found, launch anyway?
Those users you mention were hopeless anyway.
The nice thing about this is that *even if it doesn't improve detection*, it' slows down viruses a large amount. So the virus writer has rewritten his virus to avoid detection by throttling its own connections.
Guess what? We've forced that virus writer to cripple his virus' ability to spread in order to avoid detection. Yes, the virus can spread undetected. No, it can't spread as rapidly as Nimda or Code Red did.
retrorocket.o not found, launch anyway?
This wouldn't work very well with fully distributed p2p networks.
99% or more of the machines infected by Nimda and Code Red had NO need whatsoever to open multiple connections. Viruses DON'T all reside in major servers. In fact, that's the LEAST likely place for them to reside, as such machines will be the most well-maintained and patched against security holes/checked thoroughly for improper activity. Nimda and CR were hitting mostly machines that were never configured as a server but happened to be running IIS because of MS stupidity in default configurations.
Even if 10% of infected machines are unthrottled because they need to be for normal use, we've severely reduced the capability of 90% of the transmission vectors of a virus. This scheme isn't about black and white winning/losing - It's about simply slowing the damn things down so they're less of a threat.
retrorocket.o not found, launch anyway?
a virus that circumvented this software throttle? (Relatively speaking, of course.) We have viri that attempt to disable virus scans, so why would this be any different?
...///...
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.
Great, you develop a standard to limiting connections to NEW hosts. Then the virus just simply needs to poll this database of ip addresses local to this machine rather than just tring every ip address it's ip address guessing algorithm uses. Wow! now we can get complete virus converage in an efficient manor!
Test first.
Thank you.
I think that P2P programs may set off the alarm a bit too easily, no?
The idea, then, is to limit the rate at which a computer can connect to new computers, where "new" means those that are not on a recent history list. Dr Williamson's "throttle" (so called because it is both a kind of valve and a way of strangling viruses at birth) restricts such connections to one a second.
Given the large institution focus of the article, I assumed the control would be external at the network level. The only way to really stop a computer from connecting to "new" machines is to keep a record of connections and stop "new" ones external to the machine. If you can't secure the computer secure the network the author seems to be saying.
The author wonders why no one had thought of this before and I can tell him that the reason is that it's contrary to the founding priciples of the internet and it won't work. The whole idea behind the internet is to have a network without central control or intelligence. Putting this kind of invasive intelligence into the net adds complications useful only for censorship and control. How, pray tell, can you do this for a mail server? Mail servers contact new machines all day, that's their job! The virus mentioned as an example happened because of poor software from a certian vendor, Microsoft. The same trick can be had again if the virus shifts its mailing burden to the stupid IIS server.
Attention has been focused on the root cause of the problem: mail clients that run as root and automatically execute commands sent by strangers. Everyone said it was a bad idea when M$ did it, and everyone should continue to point the finger of blame in the right direction. Adding hacks like this elswhere is a waste of time and has serious implications for the internet as a medium for imformation exchange.
Friends don't help friends install M$ junk.
You raised one of the two issues here: Trojaned software.
The other problem: What if KaZaA itself turned out to have an exploitable vulnerability and became infected?
Or if a virus deliberately infected KaZaA after coming into the system another way? (Note: Making the speed limit exceptions port-based would eliminate this, leaving only a vulnerability in KaZaA itself.)
In fact, port-based limit settings would be an excellent solution to a number of the issues of machines which have legit reasons to be opening lots of outgoing connections, like mail servers. Allow a high speed limit on outgoing SMTP, but throttle anything else. (Why would a mail server make numerous HTTP contacts?) Too bad that vulnerable MTAs are probably the second most common virus vector... But at least a mailserver could still be throttled against spreading an IIS worm.
Last but not least - How long until we see an implementation of this for Linux, possibly at the firewall level? (i.e. to restrict outgoing connections at a NAT server. Of course, such a server would inherently make it harder for a virus/worm to enter in the first place.)
retrorocket.o not found, launch anyway?
The idea of slowing down the attack rate of an intruder is really not so new. One example is the infamous Linux "syn-cookies" countermeasure to syn-flooding. Syn-cookies prevent the excessive use of connection resources by reserving these resources to connections that have evidently gone through a genuine TCP three-way handshake. This forces the attack to slow down, since instead of throwing SYN-packets at a host as fast it can it now has to do a proper three-way handshake. This involves waiting for the associated round-trip times which cause the attack to slow down to the speed of genuine connection attempts.
Now since the attack has been slowed down to the speed of the genuine users, it takes part in the competition for connection resources on a fair and equal ground with other users, wich makes it as successful as other users to acquire connection resources. That means that the rate of attack is not quick enough for a resource starvation attack anymore, and it is reduced to a resource abuse attack. Since the latter type of attack needs to be employed for a long time to cause significant damage, the risks of being discovered become too big to make the attack practical.
Well, now this is not exactly a "throttling" countermeasure as described in the Economist's article. The countermeasure from the article selectively slows down outgoing connection attempts to "new" hosts, in order to further slow down the attack in an attempt to put genuine users not on equal footing with the attack but at a significant advantage. This element of selection may be new, at least I can not come up with an older example. As others commented before, the selection technique also has its disadvantages:
a) depending on the attack, different kinds of selection methods must be employed to actually single out the malicious connections -- there is is no predefinable "catch-all-attacks" selection method
b) depending on the services you run on your network, the effort you have to make to find out how your usage patterns can be discerned from known attack patterns varies.
The one and only reason why viruses spread so much and quick is that nobody cares about the principle of least privileges while creating OS and application software. If there will be means to control privileges fine-grained and automatically easy adjust them - that will be half of the solution of the problem...
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.
If an enterprise depends upon a single firewall, they deserve all they get. A real enterprise (i.e., with the cash) invests in a DMZ and at least two different firewall technologies each side of that DMZ.
Back to the world of the home user of XP. I was horrified when I first discovered that they still hadn't separated privileges, i.e., a user can use and install from the same account (and can do so without realising it).
What's so bad about GUI email programs? Is your beef with the current implementation of them, or is it the concept of having email presented in a graphical environment? Does the simple act of displaying it graphically make it inherently insecure? No. And let's not forget (mostly) everyone's favorite text-based email client, the historically insecure PINE! Should we all switch over to that and trade one security hazard for another? And not to flame you for the GNU/Linux comment, but virii will spread just as quickly on linux if it becomes the de facto standard and you've got millions of lusers out there logging in as root everyday.
... but what i get out of it as for the actual idea, without reading the HP whitepaper is
limit _new_ connections
so a webpage view will consist of X connections to 1 machine. the first time its a 'new' connection the other times its in the history, so a webpage will NOT be affected unless it has a group of image servers and applet servers or popup ads to everywhere under the sun (like some p0rn sites)
the history can be fairly short, like connections in the last 5 minutes of 1 per second that do get through, that is only a table of 300 IPs. 4 bytes each for IPv4 1200 bytes or IPv6 16 bytes each for a 4800 byte table. (index probably 2 bytes each, so add another 600 bytes to the table to make searching faster)
as this can easily be kept in ram, and it doesn't need to be long term profiling, privacy issues can be easily conntrolled.
if the machine is connecting to 400 different IP addresses per second, then you either have a poweruser or a netblock port scanner or a worm
and limiting it to conntacting 300 machines every 5 minutes would be a good thing.
"in tests it has a 2% fail rate", well in my neck of the internet, my isp's provider has a 3% fail rate in MTR tests, i don't know if i would blame the connection filter or just my bad connection to remote parts of the world
so in short, it will fail because it will affect p0rn sites and most/all P2P and worms will be made to handle them just like they handle anti-virus software now.
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 article neglects to mention which one this "throttle" system will be based upon.
The idea, then, is to limit the rate at which a computer can connect to new computers, where "new" means those that are not on a recent history list.
If the history is implemented in software, what the fuck is to stop a virus from injecting the IP's it wants to attack into the history?
It sounds great, however, it looks like they tested against a virus that makes connections as fast as it can. What happens when someone writes a virus that attempts to take advantage of any such system?
For example, intentionally make connections at a decreased rate. It gives you a couple of (probable) advantages -> You'd slide by the detection aspect of this (No backlog of connections), You'd spread slower, but you could make that work to your advantage -> a slower spread can mean longer time until detection, which may mean more hosts infected. Also, if this works as the article states, you could eventually make it so that the hosts you were connecting to were -not- throttled (Say you're getting ready to propogate a DDOS attack virus).
This would catch most virus/worms as they are written -now-, but as soon as this is widely deployed, someone will write a virus or worm that sneaks around it, by avoiding the behavior it's looking for.
Code or be coded.
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...
Ah yes, well, see, we're going to throttle the network, so that the virus spreads more slowly.
Throttle what? bandwidth? That wouldn't have much of an effect on virus activity, but it certainly would affect everything else. Connections per second would probably slow down a virus, but would basically shut down SMB and DNS as well.
You better make sure Ridge doesn't hear about this, or we'll be required by law to wear 20 lb. lead shoes everywhere we go, to make it easier to catch running terrorists.
if we are going to get anywhere.. from the article: "..takes a technician to swig a mouthful of cold coffee and clear the boxes of congealed pizza from his desk, 30 new machines around the world can be infected.." ok first of all those were chinease takeout boxes and i had to kick them out of the way to get to the desk not clear them from the desk (stuff on my keybaord, yeah right). Second it wasn't cold coffee, it was mt. dew the drink that always tastes good at room temp. I really don't see why we should take this stereo typing, not all _geeks eat pizza and drink coffee, some of us like sushi or subway, hell if i could find some indian take out and get some samosas. Plus coffee?! I like coffee as much as the next but there are much better ways to get your caffiene. we have to move beyond the stereotypes, think outside of the pizza box.. its all about respect.. r-e-s-p-e-c-t... suck-it-to-me.. Mmm.. jus a lil bit, jus a lil bit.....
"If you are going through hell, keep going." - Winston Churchill
A worm that talks to everybody you sent E-mail to recently will only hit whitelisted addresses.
We need to get rid of executable E-mail attachments, or at least keep them at a low integrity level until they've been through a guard. That's how it's done right.
Simple, elegant code requires thoroughly understanding the task at hand. Spending a minimum amount of resources means the opposite.
To put it another way, you have to write a (relatively - depends on your skill) bloated, inefficient implementation before you can write a graceful implementation - unless someone who is already an expert is holding your hand.
[an error occurred while processing this directive]
Is that ability ever utilized to any extent in legitimate, day-to-day operations?
Yes. My company, Lumeta, does scans of corporate networks, connecting to hundreds to thousands of new machines every second. Of course, if this is done at the OS-level, this is a non-issue, since we do not use connect() anyway (does not give us enough information, reactivity, or control), but rather construct packets from scratch and, regardless, we can play with the OS, since it runs on FreeBSD.
If, on the other hand, this is done on the network-level, this would cause problems, and we would have to be put on exclude lists on every router up to the corporate backbone. We balance the load across the corporation's entire IP space, but it takes a lot of divisions to get from even 100/second to 1/second.
We already run into issues where a certain router vendor has an odd "cache" that is not reaped when memory starts to become low. This would make things much worse.
Unfortunately, if this can be disabled in the OS programatically, it is useless, so the network is the obvious place to put such a restriction. Of course, now the network is retaining state about all connections going through it. Most firewalls already do this, however.
In the datacenter I work at we handle 2000 transactions per second per machine on average with peaks reaching 10000 transactions per second. Not every transaction requires a new connection because of caching in our software but we create far more than 1 new connection per second.
"You can now flame me, I am full of love,"
There are several types of worms: the two biggies, e-mail worms, and the worms infecting ISS that he mentioned (Nimda and Code Red). Throtteling really won't make much of a difference for e-mail based worms. They don't scan so they'll just go through you'r email addreess book and mail everyone. Assuming they don't make one big coneciton to mail server and do it all at once,assuming each message gets its own connection, seriouly, how many people do you have in you address book. 200? Thats a lot. And guess what. It'll be over in just over 3 minutes. Not really enough time to stop it. And what if it infects ISS or some other server (BIND? Sendmail?) These are not regular desktop machines. These are servers. You can't really limit a server like that. It'd be murder. So again, this really wouldn't work. Fine, he set up a test with a 16 computer cluster and it worked, but he didn't acount for the fact that a real web site (not a web site that no one will see) cannot be limited like that. So yeah. Nice try :)
But not practical as I see it.
1. Dont open any attachments, period. If they want to send you a file, make them post it on a website, and make sure they can account for what it is before you do go and get the file.
2. Install a firewall program. That's really easy.
3. Get anti-virus software. Most computers dont come with anti-virus software.
Now. why don't these things happen? Time. Money. Combination of both. Convenience. Lack of understanding on the part of users.
But the big one is the belief that security is a product that can be purchased, that there is a quick fix out there that will solve all your security ills and hide you from all the bad guys.
Security is a PROCESS. Better yet, it's a combination of processes, relating to employees at all levels of your organization, from the CEO to the custodial service contracted by your property manager. Hell, even building safer software isn't going to help you if your users refuse to use it 'cause it's a pain in the ass. Remember, they believe in the panacea of the "single sign-on". They put their passwords on post-its around their workstations. They keep their contacts (oh help us) in their Hotmail addressbook, regardless of how many 'sploits have been uncovered in Hotmail. They're afraid of computers.
Security is expensive. And it should be, because it has to be done right. You need user participation, on all levels. It requires education and training, and a reduction in ease of use.
There is no magic wand.
--mandi
--most people aren't 'servers' beyond http requests (more or less). Have isps offer a 'deal" where you agree to not be a server, let casual surfers sign up for that service at a reduced cheaper rate of cash. People who want to do "more" pay more, get a server "license" in other words, and they get a detailed explanation of safe computing practices and put the onus on them to follow the guidelines "or else". The "or else" can be a variable, maybe temp loss of service, loss of email, forfeiture of a deposit, whatever for malicious virus spreading, etc. The cheaper rate has a LOT of ports and services blocked at their isp. The "server licensed" rate assumes you are more responsible and hip, and are treated accordingly. It also helps to pay for your increased bandwith needs as a 'server'.
I know this is very simplistic, but something I was thinking on for awhile, correlating various discussions about peer to peer and home web page and email hosting, etc. Let the people themselves decide how much service they really want upfront based on their skill and desires level, and with that service comes verifiable accountability, ie, they can be held aty fault as well for being part of the problem if they get caught being..well... lazy and lame.. Joe blow gets the 'server" level full package normal isp connection. Joe blow downloads hotbabe.vbs and gets nailed, his box gets owned, starts sending out a boatload of more hotbabe.vbs files. Too bad, he screwed up, loss of priveleges and/or cash deposit. Better luck next time, deposit doubles.
Just a thought..I know there's flaws in it, but everything else has flaws as well. I know too many people who downloaded some firewall and that's it, in their minds they are 'secure", just do whatever they want, click on any email, never look at anything,never bother to bcc mass emailings, no followup anything but maybe that attempt, and a lot of people don't even bother to get that far, just run the computer at random. they buy it, or get it as a gift, that's it, left to learn to drive on their own, or like being told to learn to swim by being dropped headfirst into a raging whitewater whilst shackled. It ain't never gonna work that way, modern OS's and computers are too complicated right off the bat for people and there's little incentive to learn anything for most people until something "breaks" usually from operator error. It's intimidating to a lot of people, so offer them a less intimidating isp connection, then it won't matter as much. Example, the less intimidating and cheaper isp connection only comes with a web based email account, set so it can never run an executable, it's not downloaded,it's text only, any attachments like images, etc, have to be explicitly allowed and first scanned at the isp level, they'd have to jump through hoops to do that. And etc. Make it so you have to actually be forced to honestly think about what's going on, fail to think, it's not allowed.
Of course, none of this matters if all you have to do is click on an url like is being talked about the past couple of days. There's an accountability issue there with the OS and package vendors eventually, that's the biggest problem, zero incentive to really code better in the security side. there's none, nada. Click the eula to install,and it don't matter closed source or open source,paid for or free, it's caveat emptor, no software makers are ever liable for any security flaws,they write the eulas that way on purpose,it seems to be accepted,duh, so, they'll continue to exist. There's laws against malicious hacking, swell, but sometime this century wouldn't it be nice to finally see the other side of the street where if you charge money for a product it should work as advertised and not work as not advertised because of design flaws? In meat world it's calledcontributory negligence. In cyberworld this doesn't exist, despite billions of dollars exchanging hands for 'products'. Why is this again? We as a society don't accept that with other consumer products, but with software it's the default, "it ain't my fault no matter what". This is silly really. Shouldn't there be some sort of time limit on vulnerabilities, especially for paid-for software? How long will software in general be treated as all experimental betaware with a get-out-of-jail-free card? Hasn't software in the terms of "browsers" and "email clients" whatever and etc been around long enough now so that someplace somewhere the manufacturers and distributors can be declared to be at least partially "at fault" when it's shown to be so flawed that it becomes an internet menace? Isn't this REALLY the biggest problem? When will there be a smidgen of accountability to go along with "profit"?
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
Bounds-checking eliminations have been around for years. While work is still being done to expand the available techniques, boundary elimination as it stands today eliminates checks on most reasonable uses of arrays.
If you want to bash Java, there are plenty of ways to do it with an informed opinion, but that holds true with any language.
Just because it works, doesn't mean it isn't broken.
It's too bad the author of this otherwise interesting article had to insult us with his poor attempt at make-fun-of-the-geek humor. My gosh, that's been the problem all along! Viruses are troublesome merely because our pizza-eating tech-people are too fat to move in time! What an enlightening man. Too bad the most famous virii have been spread by CLUELESS EXECUTIVES, who open every email they get, regardless of warnings from the tech department.
Viruses are spread by readers of the Economist. Don't throw stones at techies if your major was Advanced Giraffe Poetry.
hi, I like pancakes -.-- -.-- --..
say...could you elaborate on #s 4 and 5 (the turning off services part) right here, right now? Thanks.
It's often necessary.
Regarding buffer overflows, I have only three wards:
snprintf, snprintf and snprintf.
VOS/Interreality project: www.interreality.org
Huh. The only way to win, is not to play.
Your right to not believe: Americans United for Separation of Church and
This technique sounds like it would work well if implemented in routers (to prevent the spread outside your office) or even extending it to switches/hubs (which would protect others on your LAN). It wouldn't require a whole lot of hardware, either. Doesn't sendmail have a similar process to throttle outgoing mail to prevent spam? How's that working for admins with a lot of users? Is it slowing down legit email?
Corporations could do it for their own nets, but perhaps ISPs could do it for all the non-business customers. Exceptions may be needed for subscribed mailing lists...or the ISP could have a passworded relay to bypass the throttle (or run with a gentler throttle).
But then, the ISPs who aren't already doing source routing aren't likely to do throttling. And DDoS indicates there are may ISPs not checking their outgoing packets.
National Security Concepts sells internet-based virus filtering services so you don't need to worry about desktop antivirus software. As I understand, it works quite well! --McG33k
I agree on the subject of static buffers. Static buffers arent always wrong. Rather the problem is that coders are usually too frustrated or impatient to take the time to use them properly. Thus giving an opening for viruses and other "sploits". Theres really nothing esoteric about this at all.
:= Foo_Ints(Base .. Base + Read_Length);
For example, a bit of Ada code that would have totally hosed my application had the compiler not caught it...
type Buffer is array(Positive range 1..Size) of Integer;
and then I do this...
type Return_Buffer is array(1..Read_Length) of Integer;
Foo_Ints: Buffer;
Bar_Ints : Return_Buffer;
Bar_Ints
Had the compiler and runtime not caught this, I would have ended up creating a massive security hole. Virus, Trojan, and spoit heaven. All because I was too impatient to use Static buffers appropriatley.
In a nutshell, it's all a matter of who has the most critical eye.
McDoobie
p.s. Can you leet haxors spot the fuck up in this code?
The biggest problem with the hard-stop tools this academic is detracting is that people don't use them. It's 80 percent "social engineering."
The same problem obtains with this theoretical solution: The same user who won't bother to install a firewall (thus providing a hard-stop to the trojan/worm/virus) won't bother to install his tool either.
I'd rather sit behind my router and firewall. And when I find any malware, I will kill it.
Can this be done with SNORT, and is it a reasonable idea?
Tech Public Policy stuff
Does this idea against "computer viral epidemics" kill all GPL'd software?
As soon as the virus has to send to a different TCP port, it's neutered.
IIS worms are dependent on the ability to connect to TCP port 80. If the virus starts using 81, it just hits "connection refused" at the other end (unless someone switched their copy of IIS to switch to 81...)
retrorocket.o not found, launch anyway?
Then a man said: Speak to us of Expectations.
He then said: If a man does not see or hear the waters of the
Jordan, then he should not taste the pomegranate or ply his wares in an
open market.
If a man would not labour in the salt and rock quarries then he
should not accept of the Earth that which he refuses to give of
himself.
Such a man would expect a pear of a peach tree.
Such a man would expect a stone to lay an egg.
Such a man would expect Sears to assemble a lawnmower.
-- Kehlog Albran, "The Profit"
- this post brought to you by the Automated Last Post Generator...