Re: [Full-disclosure] what can be done with botnet C&C's?

["Payam Tarverdyan Chychi" <payam () bhsecurity com>]

 I’ve been reading on this subject for the last several weeks and it seems
as if everyone just like to come up with out of the box ideas that are
not realistic for today’s network environments

> > J.Oquendo, thanks for the Smurf example … as there are still
admins/engineers at large networks that have no clue as to what they
are doing… so QoS is for sure out of the question.. at least at this
time.

Depending on agents to take actions and protecting our networks is even a
bigger joke. Back in late 90s where kiddies were using the simplest types
of C&C, open wide irc networks with visible Channels and no encryptions…
and agents couldn’t do anything unless the attack was big enough to take
down Amazon, yahoo, Microsoft or some other major provider with enough $$$
to start an investigation.

So what makes you think that agents are of any help in today’s world where
c&c have gotten so much more sophisticated, use backup private servers,
encryption, tunneling and much much more..

In my opinion, the only way to really start cracking down on c&c and put
an end to it is the cooperation of major ISP’s. I realize that most isp’s
cant/wont setup a security team to just investigate c&c / attacks (would
this really fall under the Abuse team?) but perhaps If all major networks
worked together and created a active db list of c&c found either on their
networks or attacking ones network… then it would be much much easier to
trace back c&c and dispose of them.

Unfortunately, we don’t live in a perfect world and most isp’s hate
sharing any information… I guess its better for them to have a bigger ego
than a safer / more stable network…

Please feel free to correct me if I am wrong…

-Payam

> > 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


-- 
-- 
Payam Tarverdyan Chychi
Network Analyst