If people are supposed to trust MS making the decision for them that automatic updates should be allowed, ...Why should they distrust them with relations to their browser??
** And the antivirus? and....???Geo
They should. They should also read the documentation and understand that MSIE is not intended to be used as a webbrowser, and doing so is effectively granting the website's owner a remote shell.
And again: MSIE is a general browser for trusted intranet resources, trusted ActiveX applications and trusted HTML-like application interfaces, whereas a webbrowser is supposed to browse potentially untrusted HTML content.
Because they should be able to differ marketing to technical documentation. And the professionals and technet are always telling that virus scanners don't work very well.
Because there is a big difference between:
- trusting in the intentions a company has and trusting in their capabilities
If you're not trusting in Microsoft, that they want to do harm to you with their products, then you should not use their products. If you're not trusting in their capabilities in some region, you may use their programs in other regions, but not in this region.
- trusting into an operating system kernel and trusting in an application program like a web browser
If Windows' kernel is insecure, then no extra "tool" you're installing onto it will be able to fix that. If Windows' kernel is OK, but one of the application programs like Internet Explorer is insecure, then just avoid this program.
And: if you're not trusting in Microsoft at all, just use other programs.
Yours, VB.
[...]
But....
...if you just said that many people cannot do this evaluation, How could they be expected to be able to differentiate which capabilities they shoud trust on? Isn't that rather incompatible with each other? Why would they be using Windows if they really did not trust in its capabilities?
Geo
OT: Wouldn't it be like trusting your doctor but not going to him/her when you're sick?
It is. This is why I'm trying to show, where Windows is well implemented, and where it has problems.
Hm... ;-) Well, while I'm convinced, that Microsoft has some good products, too, while others of their programs are not as good, there are enough alternatives. And: you could use Free Software.
Or, with other words:
Microsoft is a huge company. Of course, not all products have the same level of quality. In some topics, they have very good know-how. In other topics, sometimes I doubt that a rookie programmer, who is gifted enough, would hack such a nonsense ;-)
It's just like with every big company.
Yours, VB.
That's why I wrote: >> Users who don't like it would disable it themselves anyway.
But I probably should have also mentioned users who have hardware and/or software conflicts.
because most people have not read how to secure their browser as MS recommends, so they run it in an unsecure manner.
with paragraphs like you just wrote, discussion will certainly get nowhere. "logical positivist reliance on empirical evidence" Come on!!!
Actually, the real reason this argument never ends, is a)because on one side - posts disappear from the archive, so nobody learns or absorbs the arguments. b)becayse on the other side - we get unnecessarily abstract philosophical arguments about attack vectors and camouflage, and it's not always obvious how they apply. It's not that people are disageeing. It's that the argment never even gets going!!
I think VB's point against not bothering to block outgoing only applies to PFWs. Since they can be and are almost always circumvented(with svchost or piggybacking onto some other allowed process). If one has a FW appliance or OS FW, that does proper app layer filtering, then it could catch stuff. or genreally, by ip and port, it could catch stuff, since it isn't compromised as easily as the PFW or windows xp fw. It could block any outgoing connections to port 25, or any outgoing smtp connections to any ip other than the smtp server. And since it is not so easil compromised, it is better at blocking incoming, like incoming to port 25, or to a trojan smtp server at any port. Maybe with tunneling, even a FW appliance or OS FW can be compromised. Though that indicats that comps behind it have been compromised already.Still, it'd detect and block a lot of malware that don't compromise the FW appliance of OS FW. Really, a decent port logger is essential. So you know what is going on on your machine. I don't think you can do much with an uneducated / unequipped user with complex malware installed on their moachine.
I think Leythos has a point when he said, that the statement - to paraphrase - "blocking outgoing is a waste of time", or "outbound filtering is a waste of time" is not true for all situations. And is even untrue,false,wrong, e.t.c.
This is correct. There are sensible implementations of intrusion detection systems.
This is a misunderstanding.
Tunnelling usually has nothing to do with compromizing a system. Tunnelling means encoding extra meaning into a protocol, which is not designed to, usually driving one protocol over another.
If someone only allowes protocol A on channel A, then encode the data of potocol B in channel B within channel A using protocol A. You just need two tunnel end points, one on each side, and you can communicate through a filtering entity, which only allowes protocol A on channel A whatever you want as extra protocols or channels.
For example, Alex' wwwsh tunnels a remote shell protocol through HTTP and HTML documents, using the technics of my PoC:
Yours, VB.
Huh? An IDS is not supposed to be reliable. Actually it's a pretty useful approach to combine host-based information with network traffic analysis.
This is wrong.
An IDS is supposed to work reliably, just like any other technical implementation, too.
As a matter of fact, and IDS cannot detect every intrusion - but a fixed class of attacks it can detect reliably, and usually there are some heuristics added, which maybe can detect some extra attacks - or just fire false positives, of course.
But a fixed class of attacks have to be detected reliably. There may be false positives, but no such attack has to be overseen in an IDS. And usually, such classes of attacks, which can be detected reliably, have to be documented.
Now look at an host based IDS, which tries to detect successful attacks onto this host itself. If an attack was successful, then the host is compromized, and with it every software program including the IDS implementation. So it's not reliable any more.
The result is, that if you get an information of the IDS, maybe it's a false positive, maybe it's a detected attack. And if you're not getting any information, maybe this means, that there is an attack, and it's of the kind of the class of attacks which should be detected reliably, but the IDS just is compromized, so you cannot say anything.
This does not make sense, because there is nothing deterministic in it any more, and it's even not probabilistic. It's just nondeterministic behaviour, what do you want with such a "security system"?
Yours, VB.
I meant that a packet could get through the OS FW , say, using port 80, and tunneling, and if all other traffic is encrypted similarly too, then it looks no different. So it has got past the OS FW. It's debateable whether the OS FW has fulfilled its purpose there. It intends to filter out about unwanted packets, and can look at the application layer , filter out certain HTTP content, and thus it is a bit like a rubbish IDS. But with the FW, The operator does the detection instead of prewritten stored signatures that an IDS would have.
I guess maybe compromise is the wrong word. So, "circumvent?" No doubt security is being compromised. I think you kind of agree that the OS FW can be got around 'cos you later mention an IDS instead.
thanks
yes
but tunneling involves encryption, so what can even the external IDS do there? And especially if regular communication is tunneled anyway.
By the way.. Something I was wondering about - I read that tunneling encrypts the packet(not just the data in the packet).. And so It adds an intermediate source and dest ip . Isn't that pointless between 2 machines when there's no intermediate machines whose source/dest ip will be used? May as well just encrypt the data, rather than encrypt the whole packet and use the same source/dest ip as was encrypted. VPNs encrypt the packet (or so i've read) so I would have the same objection there.
thanks
But until then it's reliable.
Anomaly analysis.
You respond to that with a "Huh?". I wouldn't even respond to your claim with a "HUH ???" because its plain meaning is so absurd. And no other meaning is apparent.
you don't think people rely on an IDS behaving correctly. You think it doesn't matter if it doesn't do its job correctly.
I've never heard of any part of a network or part of a computer, that is not meant to be reliable.
Even trains in london are meant to be reliable - even though they are not. Maybe you meant that there are degrees as to which the IDS can do its job. Like a AV checker. It aims at having a good database which can't be complete but intends to be. As well as the operator setting it up well - which also can't be perfect. This is really unnecessarily philosophical. Of course it should be reliable.
Can't you see that you didnt' explain yourself?
( And of course a host based IDS - I believe what is meant there is 'non dedicated IDS' or workstation IDS. Is more vulnerable than an external - dedicated - headless -one. )
It doesn't even look no different, one could even build provably secure tunnels (at least as secure as the RSA cryptosystem).
It intends to filter out packets according to a ruleset.
If the attacker is clever: nothing at all. Some guys have been claiming that you could shut down all possible tunnel endpoints by whitelisting hosts, but understanding that every sufficient advanced website can be such an endpoint (f.e. by transfering cookies and/or login states), this is rather stupid.
Hehe. :-)
Well, you can man-in-the-middle attack encrypted connections and enforce a clean behaviour on your machines.
This isn't even necessary.
Can, doesn't need to.
I still wonder what "behaving correctly" means in terms of anomaly analysis.
A host-based IDS submits correct data until the host is compromised. Afterwards, it's not reliable any more.
Doesn't matter, because anomaly analysis is supposed to differ very well between normal and faked behaviour.
Right. However, it also collects a lot of useful data like processes, filesystem actions, data acccess and performance statistics, which help analyzing behaviour.
So it submits correctly that all is OK, until nothing is OK. From then on it submits incorrectly that all is OK in spite of nothing being OK.
:-P
Yours, VB.
You're describing SOAP ;-)
No.
Maybe.
It depends.
Yours, VB.
The point with anomaly analysis is that it cannot easily submit reasonably normal data from a system that is maliciously influenced. F.E. you cannot easily scan the harddisk for 30 GB of confidential data without increasing disc access volume by 30 GB.
But an IDS isn't only about detecting successful attacks, but about identifying attack attempts. At least this function of an IDS can function properly in the wake of unsuccessful attacks.
Also "success" isn't an all or nothing thing. An intruder can gain partial access, without necessary being able to compromise the IDS.
And if you consider tools in the tripwire family, a full host compromise can still be detected (since enough information is kept on a read-only storage device (typically a CD).)
So I do not consider a host-based IDS useless. But I'm jumping in late into this discussion, and maybe I've missed the point.
-j
Cabling-Design.com Forums website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.