[Novalug] Informed system/network administration [was: dynamic symbolic links]

Derek LaHousse dlahouss@mtu.edu
Mon May 4 12:10:27 EDT 2015


It's not quite enough to "have enough bars, locks, and dogs protecting
yourself that the crooks and casual trespassers go bother your
neighbor instead."  First they came for the X, then they came for the
Y, then they came for you.

Instead, think along the lines of a Neighborhood Watch.  Not just
"I've blocked that network," but "here are the indicators of an attack
coming from that network so you can block it too."

STIX - Structured Threat Information Expression
TAXII - Trusted Automated eXchange of Indicator Information

Yes, there are huge policy issues as to who you trust to tell you
what's an indicator and so on.  You don't want to blackhole google
because a malware uses 8.8.8.8 to check for network connectivity.  I
don't have a simple guide.

On Mon, May 4, 2015 at 7:44 AM, Rich Kulawiec via Novalug
<novalug@firemountain.net> wrote:
> On Sun, May 03, 2015 at 03:16:22PM -0400, James Ewing Cottrell III via Novalug wrote:
>> And to tell you the truth, these days we're Pretty Secure. It's not
>> like it was back in 1988 in The Worm Days.
>
> You've got to be kidding.  We (for a value of "we" meaning "all
> Internet-connected operations") are FAR less secure than we were back then.
>
> We've dramatically increased the aggregate attack surface while
> correspondingly decreasing the aggregate clue level.  There are people
> running major computing operations today who have failed system and
> network admin 101.
>
> Let me give one tiny example out of tens of thousands I could cite --
> one from Amazon's cloud.  Actually, even tinier than that: one IP address
> in Amazon's cloud and traffic from it to one port on one system.
>
> Here is a partial breakdown of what showed up one day from that IP address on
> port 22 on a certain system which logs and classifies all such connections:
>
> ssh     address         hostname
> ---     -------         --------
> 32621   96.127.61.212   ec2-96-127-61-212.us-gov-west-1.compute.amazonaws.com
>
> That's 32,621 failed attempts against ssh.
>
> I can quite clearly see that traffic coming in.  Why can't Amazon see
> it going out?  It's not like it's subtle.  Rudimentary netflow analysis
> would reveal it: heck, even that level of sophistication isn't necessary.
>
> A competent operation would have noticed this, quashed it, dealt with
> the abuse, looked up the hostname that traffic was going to, and sent
> a report -- with an apology -- to the security/abuse role addresses for
> the domain involved.  A *really* competent operation would have anticipated
> this kind of abuse and would have architected its services in such a manner
> as to make this far more difficult to execute.
>
> Not only did Amazon fail to do any of that, they failed to operate
> a working "abuse" role address.  And not only did they fail to do that,
> but abuse reports submitted through their onerous and nearly-unusable
> web-based reporting form simply disappear.  No acknowledgement.
> No followup.  No resolution.  No apology.  Nothing.
>
> Well, alright, not *quite* "nothing.  There's this:
>
> ssh     address         hostname
> ---     -------         --------
> 18598   54.64.224.99    ec2-54-64-224-99.ap-northeast-1.compute.amazonaws.com
>
> and a few hundred more I won't burden you with.  At least their
> incompetence and negligence is consistent.  The gift that keeps
> on giving.  Yay.
>
> Amazon *could* fix this in a week or two by using the chump change
> in Bezos' pocket.  Staff a 24x7 abuse response center with senior engineers,
> charter them with stuffing a sock in this, give them carte blanche, turn
> them loose.  But they won't.  And because they won't, the costs of dealing
> with this are being forcibly thrust *on the entire rest of the Internet*.
>
> Every one of you is paying for this, whether you realize it or not, because
> every service you use has to pay for anti-DoS, anti-bruteforce, anti-spam,
> anti-* mechanisms and the people to run them.  And they have to do that
> because this stuff is coming from Amazon and Rackspace and Yahoo and AOL
> and Verizon and Comcast and every other operation that blathers at length
> about its "security" while spewing a non-stop flood of sewage onto the
> Internet 24x7 for years at a time.
>
> So just as everyone that lives downstream of a factory discharging
> untreated toxic waste into a river has to assume the costs of coping
> with it, everyone on the Internet has to deal with this.
>
> This (massive abuse and cost-shifting) is the norm now.  If you're
> not seeing it at your operation, then either (a) you're dropping a
> heck of a lot of packets or (b) you're not looking.
>
> And what does this have to do with security?  Secure operations DO NOT
> emit abuse on a chronic and systemic basis. Point problems?  Sure.
> Temporary problems?  Sure.  We all screw up.  Stuff happens.  But an
> operation which emits abuse on a chronic and systemic basic is putting
> conclusive proof on table that *it is not secure*.
>
> At least not for any value of "secure" that I'm willing to accept.
>
> This is partly a technical problem, but frankly, it's mostly a people
> problem.  While some forms of abuse are subtle and difficult to detect
> and stop, this -- and easily 99% of the rest that I observe -- isn't.
>
> And it's that people problem which shows no sign of resolution.  All
> the bug fixes to SSL and enhancements to firewalls and everything else
> are great, but until the people running systems and networks decide to
> show competence, diligence, professionalism, and responsibility, it
> won't matter.
>
> One Upon A Time, that was the norm.  Until it's the norm again, security
> (and privacy and abuse &etc.) problems will just get worse.
>
> ---rsk
> **********************************************************************
> The Novalug mailing list is hosted by firemountain.net.
>
> To unsubscribe or change delivery options:
> http://www.firemountain.net/mailman/listinfo/novalug



More information about the Novalug mailing list