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?"
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.
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.------
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.
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.
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.
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?
How about some Outlook awareness classes?
[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
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.
it's for users, not servers. how many users do you know that make more than 1 connection per second? a webpage with multiple linked images from different sites would be about the only thing I could think of off hand that a typical user would be looking at that would request more than one connection established per second.
No DoSing here. It's completely transparent to the guy in room 207 sending email or looking up stuff on the intranet.
The World's Worst Webcomic!
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.
No. You not getting it adds to it's funniness.
It will be easy to motivate our fellow man; there is hardly anything people treasure more than not being annihilated.
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
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
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?
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.
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.
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.
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?
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?
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.
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).
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.
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.
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]
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,"
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
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?
The proposed throttle limits the number of outgoing connections to NEW machines. This will have no effect on the execution a traditional DDOS attack- DDOS means that all the infected systems target one computer, instead of how a propagating worm targets random computers.
A hacker infiltrates 2000 random PCs, and instruct them to hammer on www.ebay.com at a synchronized time. They each connect, the address is added to the throttle's automated whitelist, and away they go.
The prepartion of a DDOS could be slowed, if it uses "viruses" to prepare the helper systems. But super-fast spreading "viruses" (mostly worms, really) aren't what you use to prep a DDOS- slow & steady is best for that.
Can this be done with SNORT, and is it a reasonable idea?
Tech Public Policy stuff
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?