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 (Premier Network Access Control (NAC) Solutions & Security | Fortinet).
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.
