I absolutly agree with you about what is being called "real time" being too late (unless it is done on the network, where interruption for allow/deny choices becomes more difficult).
General purpose OS's are not built for RTC needs, so I simply don't think that these computing defintions apply to what is sold as 'real-time scanning' solutions, as least the ones that are PC-based. It may be worthwhile to stick to these definitions, by which most such 'real-time' software FAILS due to the deadline having been past. I would call the deadline for security scanning, to be the time when infection does (or may) take place. Most users think of this in terms of the firewall software which stalls and pops up a question, "Do you want to allow this? (once/always/never)". Which is suitable for opening up most new network connections... but maybe not for the umpteen JS scripts on a given web page. I enjoy the ranting, sorry it is wearing you down, and I hope it is not bothersome to others. I think we're well within the bounds and intentions of our group and its mailing list :) I can't speak to the patience or infomation- processing capabilities of the group's members though! ;) I enjoyed some great [copylefted] videos from November's 23C3 tech-security conference in Berlin, where Vista was of course discussed, and they said that although they could see (by comparing DLLs) that many long-overdue patches had been applied, they also saw a slew of new zero-day exploits waiting to be enjoyed, abused, or otherwise plucked.... same old, same old, it seems. ciao, ben On 2/20/07, Michael Miller <[EMAIL PROTECTED]> wrote:
Ben, I agree with your points. This is my problem with the word real time scanning. In computing real time operations are defined as this. "In computer science, real-time computing (RTC) is the study of hardware and software systems which are subject to a "real-time constraint" —ie. operational deadlines from event to system response. By contrast, a non-real-time system is one for which there is no deadline, even if fast response or high performance is desired or even preferred. The needs of real-time software are often addressed in the context of real-time operating systems, and synchronous programming languages, which provide frameworks on which to build real-time application software. A real time system may be one where its application can be considered (within context) to be mission critical. The anti-lock brakes on a car are a simple example of a real-time computing system — the real-time constraint in this system is the short time in which the brakes must be released to prevent the wheel from locking. Real-time computations can be said to have failed if they are not completed before their deadline, where their deadline is relative to an event. A real-time deadline must be met, regardless of system load. Contents" http://en.wikipedia.org/wiki/Real-time I know this is a little verbose. Real time scanning is after the fact. You have the virus or malware on your system so it's not really real time. Now if you IDS or IPS software on your network / computer this is all so not real time, It's after the fact. You may and can disagree with me on this point. I think best practice for virus scanning is to have the software installed. Then scanning may be what ever fits into your organisations polices. End users are going to browse what ever they want when they want to. The thing with end uses is they don't understand the technology. I think this is where the root of all problems is. If you don't do X,Y and Z you should have no problems at all. The same goes for if you have X,Y and Z programs installed and patches installed. The main problem is people don't do that and this is where the root of the botnet problems are. I'm not so confident that Microsoft in all there good intentions took the correct default security stance with Vista. http://blogs.zdnet.com/security/?p=29 I only think they build a slightly better mouse trap. Maybe I'm wrong about this but I think time will write the final notes on this. -Miller P.S looking for a end too the ranting. On 2/20/07, Ben Barrett <[EMAIL PROTECTED]> wrote: > Hmm, I have to say I'm not really much more scared about this than > as with any other web browsing. To the end-users I support, who are > just as likely to "accidentally" click on some bad email attachment or > "accidentally" surf into nether regions, there is little or no difference. > It *almost* appears as another attack vector, but not quite from what > I've seen. Now, if you start putting this crap in desktop widgets which > are sure to contain JS in some implementation, outside of a browser > entirely, then... well hum. > > I'm confused about why you say this is so important, and yet also state > that real time scanning is over-rated. It appears that real-time scanning, > is the best way to catch (or at least observe) these malicious behaviours. > And I notice all proofs-of-concept, and even early exploits, have say sql > injections in the clear, so it seems like you could easily scan for things > that look like sql in traffic, but with JS it is so easy to wrap/unwrap > data. > > Thanks for bringing this topic up -- future implications of AJAX, and > especially > the ways in which current trends are jut destroying some of the old-timey > web fundamentals, is just not discussed openly enough IMO. > If we started selling a car that drives on top of power lines, to avoid > traffic, then our audience could either be shocked or be busy building > elevated > parking spaces and new on-ramps. Sorry, I'm working on my pataphors! ;) > > > ben > > > > On 2/20/07, Michael Miller < [EMAIL PROTECTED]> wrote: > > Ya your right Ben, I should have posted a example or two. > > > > http://blogs.securiteam.com/index.php/archives/734 > > http://www.gnucitizen.org/blog/google-search-api-worms > > > > I know there is a lot of hype out there about this. Some of this is > > just theory and some of it is or will be fact when some one releases > > another banner ad worm. > > > > -Miller > > > > On 2/20/07, Ben Barrett < [EMAIL PROTECTED]> wrote: > > > Are you asking if we know that AJAX can do things that we should > consider > > > scary? > > > (I think I agree... but...) How about giving a few examples of why we > > > should be > > > so scared? There are a LOT of folks who won't disable JS since it > "breaks > > > the web" > > > almost as much (in their opinion) and unplugging network cables! > > > > > > thanks, > > > > > > ben > > > > > > > > > > > > On 2/20/07, Michael Miller < [EMAIL PROTECTED]> wrote: > > > > Real time scanning is over rated in my book. The only time you need > > > > to scan items real time is when your receiving e-mail. If you turn > > > > off Active X and java script ( If you can. ) You should be fine. It's > > > > really scary what we can do with AJAX and Java script in the web > > > > browser. I'm sure most of you if not all know this. If you can do > > > > some in line scanning with your web traffic that is even better. I > > > > thinking about setting up Squid to use ClamAV to scan the banner Ad's > > > > along with everything else looking for malware and or militias > > > > content. > > > > > > > > -Miller > > > > > > > > On 2/16/07, Elijah Buck < [EMAIL PROTECTED]> wrote: > > > > > FYI, > > > > > > > > > > clamav doesn't have a real-time scanner (that is, it only scans when > you > > > > > schedule it to scan). > > > > > > > > > > > > > > > > > > > > > > > > > On 2/14/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > > > > > > > > > > > > > > > > > Just out of curiousity, how does AVG size up against Clam AV? > > > > > > > > > > > > -E > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > EUGLUG mailing list > > > > > [email protected] > > > > > http://www.euglug.org/mailman/listinfo/euglug > > > > > > > > > > > > > > _______________________________________________ > > > > EUGLUG mailing list > > > > [email protected] > > > > http://www.euglug.org/mailman/listinfo/euglug > > > > > > > > > > > > > _______________________________________________ > > > EUGLUG mailing list > > > [email protected] > > > http://www.euglug.org/mailman/listinfo/euglug > > > > > > > > _______________________________________________ > > EUGLUG mailing list > > [email protected] > > http://www.euglug.org/mailman/listinfo/euglug > > > > > _______________________________________________ > EUGLUG mailing list > [email protected] > http://www.euglug.org/mailman/listinfo/euglug > > _______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
_______________________________________________ EUGLUG mailing list [email protected] http://www.euglug.org/mailman/listinfo/euglug
