Jump to content

not_satisfied

Members
  • Posts

    4
  • Joined

  • Last visited

About not_satisfied

  • Rank
    Newbie
    Newbie

Profile Information

  • Location
    Germany
  1. You are certainly entitled to your opinion, but I'd really like to know the reasoning behind this. If you call something dumb at least give a how&why (besides ease of deleting a rule ... I mean 'cmon, that's really up to the program used and not an indicator whether it's cool to block anything), otherwise it's just plain stupid and ignorant. In case you mangled the important part while reading: We are talking about unknown outbound traffic (originating from svchost) here. In my book it's just a "dumb rule of thumb" to just block anything unknown or when you are unsure in this matter. It's the same as people deleting unknown files from their PC and afterwards wondering whether it could've been malware and why all of a sudden they get this weird errors on boot. Let's assume the originating process and traffic were indeed malicious, then it would do no good to just block it. Since it's outbound the system is already compromised and blocking or unblocking said traffic will not change anything about that. It can even create a totally false sense of security.* However, if we assume somewhat intelligent malware, which should be relatively common these days, or a directly attacking entity, even if very less likely, blocking the traffic will do two or three things a) alert the attacker that something is wrong and b) probably lead to the discovery of the security feature which put the block in place (in case the attacker didn't know this yet, but that's unlikely in this setup) and c) lead to a change in the attackers approach. c) is bad. It's very bad, because you can't predict what will happen. With this kind of access an attacker could for example disable your filtering capabilities without you even knowing. Or the attacker could hook into another process, which is already allowed to communicate outbound, like your browser, and you wouldn't be able to monitor this (if your HIPS fails at this point that is, but if he's already this deep in your system I'd say it has a pretty good chance at failing or at being subverted). Or an attacker could delete all his payloads from the system upon discovery, now you aren't any wiser and can only assume the system has been compromised based on circumstantial evidence at best. Since you don't know what he did or didn't do to the system the best thing would be to rebuild from scratch or use a backup ... but then again, if you don't know if something malicious (and what) had been on the system how are you sure it isn't in your latest backup? Bottom line, one can't know what would happen and if something evil is having a tea party with your svchost and chatting happily away, then it's quite too late to block anything. Even if it'd be spewing out all your passwords into the ether in this single request it doesn't matter, since you can't be sure what happened before and how the malware is structured. Therefore you should change all important details using a secure system anyway. You certainly won't be able to stop common malware infecting the system using host-bound outbound filtering, since most exploits will happen in the context of other applications, like your browser, which already have permission to establish inbound & outbound connections anyway. (Otherwise it'd be sad being that browser.) So, while blocking a malicious outbound request provides no real benefit in terms of system security it can make the aftermath and analysis of what happened to a system so much more complicated if you're dealing with an attack which reacts to such things (and you should assume this if it's an unknown event like described above). Things might look slightly different if the system is supervised by a NIDS, but then again you'd be more likely running NOD32 BE not ESS Home. Let's assume it is a privacy related incident. It would be reasonable to block this, however, in my book that'd be in a category somewhere between 'anticipated incident' and 'known problem', so you should be aware of what to expect/block beforehand. Even if you couldn't possibly know about any issues and there is unknown traffic from an unknown process in my opinion you should put system security above privacy concerns and act as if it's malware, since obviously you can't tell the difference. Let's assume the originating process and traffic were legitimate, it would do no good blocking it, but also it probably wouldn't do any harm blocking it short term. However, when you do your research and come to no conclusion, because there is so little information (or you are searching wrong) what do you do? Is uz5dz39x8xk8wyq3dzn7vpt670qmvzx0zd9zg4ldwldkv6kx9ft090.ns.yp.to good or malicious, what about 3.f.ix.de, elb020015-953005921.us-east-1.elb.amazonaws.com or hosted-by.illuminati.es for that matter (don't mind the examples.)? You could keep the block, just to be on the safe side...now we changed short to long term without a second thought. But then what if, for example, the legitimate traffic is actually belonging to an update routine, which now fails and does so silently and gracefully, because the programmer didn't anticipate someone blocking network communication? Now you build yourself a homemade security hole. It might seem unlikely but I've seen just too many people doing this, because they didn't know better. Blocking e.g. something like a1293.d.akamai.net seems to be popular, I can understand it, it looks like something dodgy, too (for some at least). Though it often won't really fail silently, but then again people don't seem to care that much or don't see the failure for one reason or another. In the end this doesn't matter for arguments sake, because even with legit traffic we're back to distinguishing unknown good from unknown bad traffic - as before. You can't and then you're are back to square one. And just because I find it unfathomably important I'll repeat it once: If there is real malicious outbound traffic originating from a very privileged process you can forget about blocking it, because it is already too late at this stage. Just halt and analyze the system to access what went wrong (and what was compromised if applicable) and revert to backup. Now you got more than my two cents of spare change. I frankly don't care if you block or unblock all unknown outbound traffic, whatever fits your sense of relative security, just don't have a false one. I have seen it backfire just too many times so for me it's a no-go. If you don't see any problems with the things I stated it's fine, whatever works for you. But if you declare something as 'dumb' at the very least give an explanation as to why it presumably is and in this context that'd be all the benefits of blocking all unknown outbound traffic. I see some (largely privacy related) merits, but imo they don't outweigh the possible cons of breached system security & thwarted analysis. _____________ *) It can even be very dangerous for some people who are not familiar with how software works, in that they assume blocking traffic would be equivalent to removing malware from their system. But that's a different story.
  2. You don't need software specifically from Tinet, because that wouldn't make any sense since software for the masses wouldn't be their business model. Tinet does (or yet better did) ip transit, bandwidth management, mpls and similar stuff. Wikipedia says (https://en.wikipedia.org/wiki/Tinet): "Tinet SpA and Neutral Tandem, Inc., provided voice, IP Transit, Ethernet and hosted services to carriers, service providers, and content management firms based in over 80 countries and six continents". Then Tinet was rebrandet as Intelliquent (https://en.wikipedia.org/wiki/Inteliquent), which did other routing related services, and then they sold the business to GTT which does pretty much the same. Wikipedia says (https://en.wikipedia.org/wiki/Global_Telecom_%26_Technology): "...is a multinational telecommunications and Internet service provider company headquartered in McLean, Virginia. GTT operates a Tier 1 network, and provides IP transit and MPLS transport services to enterprise, government, and carrier customers in over 80 countries" So, I wouldn't block that domain / IP as long as you aren't sure that you really don't have anything which would use a service which relies on any one of the services from said companies. I believe I remember someone on a french linux forum blocking stuff from (back then) Intelliquent and then some websites wouldn't work for them because back then those companies did some load balancing over their services or it was part of Akamai Caching or something. I'd really suggest researching that matter before blocking something prematurely (even if the domain sounds dodgy, I don't know why they'd register something like that. Maybe bored admins...). But that're just my two cents.
  3. Hi Marcos, yes, I believe it is ESET German, at least I used the German website and support form. PN send. Thanks.
  4. Well, topic title really says it all. I created a technical support ticket regarding license renewal on 24.10. and and haven't heard a word from customer support staff (besides the automated reply on ticket creation).
×
×
  • Create New...