ICANN ICANN Email List Archives

[gnso-ff-pdp-may08]


<<< Chronological Index >>>    <<< Thread Index >>>

Re: [gnso-ff-pdp-may08] Improving network visibility/netflow

  • To: jose@xxxxxxxxx
  • Subject: Re: [gnso-ff-pdp-may08] Improving network visibility/netflow
  • From: Joe St Sauver <joe@xxxxxxxxxxxxxxxxxx>
  • Date: Wed, 6 May 2009 09:33:28 -0700

Jose mentioned:

#at a technical level this requires them to know the IPs/ports of the 
#motherships to do robust flow-based identification. in the absence of that 
#every random web server on a broadband line looks suspect even though very 
#few are fluxing.

Actually, fast flux hosts tend to have very distinctive traffic flows
that are completely different from what you'd see from a normal (non-botted)
customer. This is the same point that I made to MAAWG in March of 2005, see
"Spam Zombies and Inbound Flows to Compromised Customer Systems,"
http://www.uoregon.edu/~joe/zombies.pdf and this notion of "looking upstream"
is on which Microsoft described successfully using in October 2005, see
http://www.microsoft.com/presspass/features/2005/oct05/10-27Zombie.mspx

However, even if you don't want to use traffic analysis to *identify* fast
flux hosts, netflow still provides crucial tools for use in *verifying*
abuse reports received from third parties -- if you don't have netflow
(or the equivalent) and someone says, "Hey, your user at 12.34.56.78 is
currently acting as a fast flux node," how would ISPs be able to verify 
that accusation? Answer, typically they wouldn't be able to do so, unless
they did a truck roll, and that costs $$$, and thus generally won't happen.
Netflow thus plays just a crucial role...

Other folks are also Netflow proponents, e.g., see: "Netflow. Use it." at
http://threatchaos.com/2009/02/netflow-use-it/ and the comments that 
follow.

Regards,

Joe



<<< Chronological Index >>>    <<< Thread Index >>>

Privacy Policy | Terms of Service | Cookies Policy