Subject: what can be done with botnet C&C's?
"I work on this [C&C] for 30 days, only to find out one of you took it down." -- US Federal Agent, two days ago, ISOI (DA Workshop).
Oddly agents have resources right in front of them to assist them (CALEA, and other totalitarian laws) and yet they fail to use these resources properly only optioning to promote newer and even more stupider laws.
And still, sticking to networking issues, as obviously we cannot yet depend on law enforcement to protect our networks for us, how do we handle C&C's?
Where in the rule book does it state that LEA's are here to protect any network. I say it begins with the CSO's, managers, engineers (both network and security engineers.) Bear in mind cross juridstiction across international boundaries.
When we kill them (and by "kill" I naturally mean "report our suspicion to the responsible authority so they can investigate, confirm and proceed according to their AUP") we kill them, but only to our knowledge. They immediately move elsewhere we do not know about in our space or someone else's, maybe misplacing an extremely smallish percentage of their population while they are at it.
Let's be realistic about this. Most providers in the US at least have some form of CALEA capabilities which can monitor what is coming from where in order to filter networks.
Okay, say I am right... What *can* we do?
Re-write AUP's from the ISP level blocking out and allowing out on a needed basis. For those BOTNETS utilizing IRC, they'll be nipped at the bud, for those in these networks truly utilizing IRC and other similar venues, an ISP could either set up their own server and link to other servers, or the IRC user themselves are almost always smart enough to figure out how to jump on an IRC server.
We can take advantage: 1. QoS and traffic limiting tools. Many tools created in recent years, and used exstensively by many ISP's, regardless of any Net Neutrality legislation, are at our disposal and already implemented on our networks.
QoS is a joke. The problem with QoS is a configuration issue. How many networks are still allowing broadcasts (Smurf). What makes one think that if they can't configure simple RFC filtering and containment of broadcast, they'd be able/capable/willing to configure QoS. Outside of this, the biggest argument will be a "not in my backyard" issue of "why are you filtering our traffic."
Much like, for business reasons, many of us would limit P2P, how about limiting the traffic to compromised users?
How, what and when is up to you.
Laziness. Come on now, and by the way greeting Gadi, you should know offhand the slack that comes from lazy admins unwilling to do squat but read this in the background and continue eating ho-ho's and donuts.
Watch the flows, block the users from communicating out to them. Watch these users and see where else they are communicating in comparison to other users, en-masse.
Breaking laws here if you ask me. Watching flows. Isn't this an illegal wiretap.
4. Stop internal network infections. It is unbelievable how the networks with the most bots are the networks that allow internal users to connect wherever they want within the network.
Re-read my lazy admin donut syndrome.
My answer is this, if you fail to remove a spy, as another would just take his place, wouldn't you rather know where that spy is and work to take him down for good?
One thing that will end up happening as is evident is, you will end up creating a smarter and smarter botnet. Filter from here, they move, filter this port, they jump. Most network admins know how to entirely block these things but they don't. How about a completely new approach via AUP. "Welcome to Foofoo Network's your ISP. We allow SMTP, HTTP, HTTPS, IM." Period. No need to keep the other 65531 ports open.
Do you know who your local fed is?
Definitely not on Clue Avenue. If they were there would be no need to try and impose LawB atop LawA which never worked in the first place.
I would like to hear some opinions on what networks can do, ecnomically, from people here. Please stick to network operations issues.
Gadi.
Here is my opinion... Responsibility on both ends. For the user and the provider. The One-Two punch 1) For an ISP something like Campus Manager would work wonders (http://www.bradfordnetworks.com/products/security.html). Configured in the background it can take machines and shove them into a non useable VLAN until they get their act together. 2) Client breaching Terms of Service agreements? Hold them accountable. Users are responsible for their own machines: <analogy> UserA buys a gun and keeps it in his house. UserA does not buy a safe or take necessary precautions to safeguard his gun. LuzerB uses that gun for a crime. LuzerC (UserA's son or daughter brings it to show and tell) LuzerD (UserA's neighbor blows his brain out via Russian Roulette) </analogy> In all of these instances UserA would still have to answer for not taking the necessary precautions. Why not implement the same procedures when signing up a new user via TOS agreements. I'm sure more people would be reluctant to just close their eyes after one warning followed by them having to pay for not taking precautions. Sure, argue about the clueless ones who don't know who to tie their shoes. 1) Would make them more aware. 2) Would make networks safer since their is accountability. My two cents for the moment. -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743 sil infiltrated . net http://www.infiltrated.net "How a man plays the game shows something of his character - how he loses shows all" - Mr. Luckey ----- End forwarded message ----- -- =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ J. Oquendo http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x1383A743 sil infiltrated . net http://www.infiltrated.net "How a man plays the game shows something of his character - how he loses shows all" - Mr. Luckey