[194642] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: Please run windows update now

daemon@ATHENA.MIT.EDU (valdis.kletnieks@vt.edu)
Tue May 16 02:06:40 2017

X-Original-To: nanog@nanog.org
From: valdis.kletnieks@vt.edu
X-Google-Original-From: Valdis.Kletnieks@vt.edu
To: "Aaron C. de Bruyn" <aaron@heyaaron.com>
In-Reply-To: <CAEE+rGrBQjWw0sT-sTvC=_=dVuuTD=vXKaiizALB+OFTF+d5vg@mail.gmail.com>
Date: Tue, 16 May 2017 02:06:30 -0400
Cc: North American Network Operators' Group <nanog@nanog.org>,
 Rich Kulawiec <rsk@gsp.org>, bzs@theworld.com
Errors-To: nanog-bounces@nanog.org

--==_Exmh_1494914789_2776P
Content-Type: text/plain; charset=us-ascii

On Mon, 15 May 2017 16:19:37 -0700, "Aaron C. de Bruyn via NANOG" said:

> Combine that with fail2ban.  When one user has more than 60 writes in
> 60 seconds *or* a write contains a well-known cryptolocker name (i.e.
> *DECRYPT_INSTRUCT*)

Oddly enough, we've seen *lots* of spammers that are *totally* able to
auto-tune their spew rate to whatever you set the knob to.  Set it to 3,293,
and it will quickly adjust to 3,250 or so.  Knock the knob down to 67, it will
tune down to 65. There's no reason to expect that the same methods won't
be used again.

If it's an entire network of vulnerable systems, it's perfectly reasonable for
malware to pick one system (the one with the least number of likely-valuable
files) as a sacrificial goat and burn it down, just to see where you've set the
knobs, and then fly under the radar for the rest of the network.

If malware waits till 5:01PM Friday or whenever it detects the user has left
for the weekend, and does a careful search of file extensions for files most
likely to be valuable enough to make the victim pay the ransom, and does them
at 3 per minute, how bad is the situation Monday morning?

So you restrict file change rate to 1 per hour or something draconian when the
user isn't at the keyboard.

What is the likely amount of time the malware can get away with doing 3 files a
minute in the background while the user *is* using the system, before they hit
an encrypted file and realize there's a problem (hint - avoid files modified in
the last few days and target more static files)?

What is the likely amount of time you can restrict the user to 2 files per
minute before they come looking for you with an ax?

Remember - the first rule of designing security is that if you haven't already
thought through the first several iterations of blatantly obvious ways to work
around your proposal, and dealt with them, it's guaranteed that the bad guys
will do so for you.

Remember this as well - the entire reason why Snowden walked away with so many
files was because the NSA was not using all the available security features
*because it put too much of a crimp in legitimate analyst activity*.  It's also
why almost nobody outside military and spook systems actually deploys MLS/MCS
security.

Given that we've been at this for well over 4 decades now, and we *still* can't
actually do it right, you should be *very* suspicious of any proposal that says
"Just count the number of opens, tie it to fail2ban, handwave yadda yadda
handwave *SECURE*".


--==_Exmh_1494914789_2776P
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Comment: Exmh version 2.8.0 04/21/2017

iQEVAwUBWRqW5Y0DS38y7CIcAQJHEwf/QGJ5YB2rgcy1z9GM01Ot7dBgNENt0YMR
HFNu382GNYeqEt+vmVUXOXqLXQQnjuZ6095PgVxmDRBqTPWNZrMRIJCjph0N4D6s
3Rzu0VesPB/BFqvOjFyaJcxNx82Q8WVyHxZFm+xi1q7QTaGxK8owLGR6U0tdDLyw
ifaOoiSb0PaaD2YiAMRaWYx7krS18guaNyeBWKOopNu9hZ1e7Z3gXIp6G0OII8Qf
Dg2T9Jj2yCrVdevFHCPLI7nObKrd1g2ZQVBk00y7c1rxkXEaeVPrJPs+ebffMX8a
X6tKNvqXa3lRFGcuidqXCS7IhmZyUTaKCyMKtcVknB7XzihGAvVmHA==
=b46L
-----END PGP SIGNATURE-----

--==_Exmh_1494914789_2776P--

home help back first fref pref prev next nref lref last post