-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/646/matasano-security-recommendation-001-avoid-agents/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
Specific to my article, I was just saying that to perform a pre-admission NAC test, sometimes for a variety of reasons, agentless is not going to do the job. At that point, a decision has to be made regarding the risk to use an agent (and all the risk that entails) or do the best you can agentlessly and maybe use some reduced access to mitigate risk. At the end of the day it all comes down to your risk threshold.
Wait, we already did that with Blink Professional. V3.0, which comes in the next few weeks, consolidates about 10 different agents into a single agent, hardened from exploitation and managed using a secured architecture.
Thomas is right in the principle of 'less is more' when it comes to agents. I like the idea of having as few agents as possible running, but with systems management, software distribution and the need to secure the underlying OS and applications, it becomes a need to balance risk against functionality.
I can't disagree that customers should look at reducing the number of agents, since Big Fix produces an agent that can (and does) manage just about anyone else's software. And we do that with ONE agent, not by adding slave agents, etc... For example, we will take care of code and sig updates for I think 6 or more AV vendors.
Any further rebuttal would require some sort of architecture documentation, which I'm still behind on.
I'll reiterate that we haven't looked at BigFix. BigFix might have excellent security. But if it does, it will be an anomaly.
I wouldn't be even close to surprised to find that eEye has the strongest agent implementation on the market; you have an excellent team. But you should be able to document what you did to secure Blink.
I especially like the recommendations to not make programming errors and create bad protocols.
Oh wait, the sarcasm got turned back on there again for a sec, sorry. ;)
How do you know what applies to you or doesn't apply to you unless you've tested? And if you've tested, can't you just explain what you tested, how you tested it, and what it means for the security of your design?
agreed. this stuff is scary. i take it you're not talking about munin, nagios, or net-snmp agents.
also did you miss Ross Brown's point about consolidation of agents or did you choose to not respond to it yet on purpose?
for the client-side, can't we load up netcat to bind to a tcp or udp port on localhost and send enterprise traffic to it (make the management station setting in the client equal to 127.0.0.1), which then pipes to stunnel? and then stunnel sends the traffic to the real management station? and then the management station listens with stunnel and sends the traffic on localhost to the real management application?
there's a certain `consolidation of agents' in a nutshell.
maybe it would be a good idea to write the gluelayer that is netcat/stunnel, make it work well with windows, and document it and release it to the public? this would secure the traffic on the wire.
for now, i'll call it simply, "gluelayer", since it doesn't exist.
but there is still a problem of the listeners on the enterprise mgmt apps. if you can't shut them off easily (note that i don't trust firewalls), maybe you could completely intercept them assuming they don't bind to every address+socket and also use SO_REUSEADDR, SO_EXCLUSIVEADDRUSE, or enhanced socket security. hijacking a server socket is as simple as binding to a specific IP address (again, gotta love that netcat). another gluelayer project, but this one doesn't work in every situation and has a lot of requirements and dependencies.
i hate to use the words "layer-3 switches at the access-layer and firewall every port", but i don't trust software firewalls (however, http://force.coresecurity.com is NOT bad).
but COME ON, TOM. you know that MITM is a much worse attack than attacking the listener since ARP poisoning is so prevalent still. and don't tell me you didn't teach your kids how to use Cain (http://www.oxid.it) yet, because anybody can use this stuff. maybe i should provide some links to DHCP snooping, IP/MAC source guard, and dynamic arp inspection (Cisco's DAI).
oh crap i just said Cisco, nevermind everything i said. make sure to also set port-security to 1 static and 1 dynamic per port as well to prevent CAM table overflow. and 3,000 other "also's / as well's".
in reality though people - somebody has already thrown ettercap and openssl into post-phatb0t code (no wait, openssl was in the original phatb0t). downgrade attacks (i could use netsed for this) work great as well. i'm sure Matasano uses more advanced techniques than just these. they probably read chapters 4 and 5 of "hunting security bugs (Microsoft Press)".
oh and i spelled phatbot wrong. it doesn't have a zero... that was for random self-post-bumping.
your strategies are great! i guess future recommendations you might want to incorporate would be using consolidated agents, implementing DAI in the network, and/or possibly moving to IPv6.
http://ryanlrussell.blogspot.com/2006/12/nothin...
It's not practicable to keep 1000 diverse machines secure. Forget it. It's not going to happen. Now you're in a spot where, when any one of those machines happens, everything you've attempted to do to protect the management server is nullified.
"It's the application, stupid!"
You know, the irony is that there are other impacts as well. BigFix's agent may be able to manage other software but it has a massive hit on battery life due to the way it is constantly hitting the disk. It also listens all the time and hence is available no matter what network I'm on.
I can't speak to Blink 3.0 but I can observe that there is more than just having a kick-ass agent, you have to have a decent central console among other things. Though I have to admit, I have greater hopes that Blink would not have the typical vulnerabilities than other agents.
McAfee's collection of agents take up more RAM between them than many applications. I can always tell when McAfee is updating because it pegs my processor and kills all response. Now they are trying to integrate it with ePO which just makes me feel all warm and fuzzy...
You need both. Anyone who tells you otherwise has an agenda. I agree that organizations need to limit the amount of agents deployed, there are far too many fighting for control of system resources. But this doesn't mean you do not need any.
So the advice is really to eliminate redundant and insecure agents and realign disparate agents into a common management infrastructure.
Advising organizations to place a high-value assets on syst3ems with no agents it not good advice.
I'm sorry it seems disingenuous. It isn't.
Well written. You are not coming to market soon with a product that will prove to be a panacea to this issue, are you?
-al
We just don't think people are thinking about agent security enough.
However, the sad truth is that sometimes you cannot do it without an agent or you can but you'd open a bigger-than-agent security hole in the process...
In the end its just the same thing and you don't want redundant, complex and bloated services that provide a larger attack surface either right?
ok, ok, lets not be picky... Berkeley r*
DNS, NFS, NDS, AD...
So what's my point? Agents are not an intrinsically bad idea, the design (and implementation) of their current incarnations are. All these technologies were thought off following the paradigms of the previous decades: client/server architectures, centralized control on star-topology or hierarchical networks, monolithic code, centralized databases, etc.
Distributed databases, mobile code, reputation-based systems and P2P networks are all alien concepts (or at least "interesting research ideas") to the current vendors of agent-based products, if you add to that software bloat, agent complexity and poor security development practices you can easily justify aversion to all agent-based technology but I would not dismiss all of it just because all current, well-known vendors lack the imagination and guts to build things differently and show that they are forward-thinking organizations, at the possible expense of cannibalizing their business.
It's a matter of what the culture of the company is. Government tends towards appliance solutions because the security group can use it to establish a beachhead in the data centre and extend their influence outward over the various IT silos by offering a service.
Smaller companies, particularly ones with large mobile sales forces will go for the agent solution because they can actually manage the security of the laptops via the agents, and they have the authority to get the agent on all the machines. This is exceedingly difficult in government systems, though it is occasionally done.
The minutae of different sectors comes into play to determine which solution is more suitable to them, however, few will ever make the decision of which technology to deply based on the esoteric (albeit important) arguments raised in this discussion.
Be seeing you....