Re: [PLUG] spamassassin help: create a rule to score by sender TLD

["Keith C. Perry" <kperry@daotechnologies.com>]

Rich said...

"I suggest, as I pointed in my long message, that people analyze and
understand their own operational needs, and block everything that they
don't need/want.  I happen to block .me *here* because careful, detailed
analysis showed that mail traffic arriving *here* from .me was almost
all spam."

...and he is EXACTLY right.

I've also been working on systems, networks and related security items since before the internet was the Internet and when I've taught this- from tech school classes to collegiate grad school classes to adult continuity education classes, the one thing I go through is the history of technology security, why it is important and why it can't be treated as an after thought.

Even today we still have communication protocols being put out that have have zero security mechanisms in their layers  or developer have no guidance how their protocols can be secured by existing mechanisms.  That is just ridiculous in 2016- look at most of the brand new shiny IoT stuff- no thank you.

What we have is technology at odds with the human condition.  On the one hand, we have come a long way since the 1990's and on the other hand, for all the good a more connected world is, it is also more connected for those that are on the fringes of social norms.

More specifically the technology issues are:

1) The many techs do not have a solid grasp of system and network security mechanisms.  They simply do not know what they do not know.  They also do not know how the identify active attacks or how to bring tools to bare to defend against them.

2) There is still a reluctance to implement strong security mechanisms.  For some reason, particularly in the US, being "secure" has a negative connotation.  There is an apprehension to do what it take to be safe from the physical layer on up because for [too many] people, this is an admission that something is by default not safe and oh-my-god-we-are-not-safe-but-I-though-this-was-America.  Its the person on tv who say "I can't believe THAT happened in MY neighborhood- things like THAT don't happen HERE".

I'll end my rant there but understand.  Until #2 is addresses, #1 won't be.


For me some basic best practices are:
1) Only allow ingress of services used
2) Put dynamic throttles on services used
3) Get intimate with your system and network- seriously... channel your inner Star Trek engineer- you should have a sense of how your "ship" is doing by "feel".  In the early days on my career I would spend so much time in front on equipment that is became second nature to have a sense of abnormal order by listening, looking, feeling and even using my sense of smell (don't laugh, most of us know what thermally damaged electronics smells like at this point).
4) Have a plan and then have another one- know what you are going to do if you need to "fight" attacks on your services.  That should include the "abandon ship" plan (aka your disaster recovery and continuity plan) for when you will need to rebuild after a situation gets out of your control.
5) Don't be afraid to say "No"- this is the hardest one.  One of the things that goes along with attempting to address human resistance to using strong security, is being ok with saying no.  Good security needs balance across the entire infrastructure and that is something that takes time to determine.  People don't like to be told they can't have something but there are times when that is exactly the right thing to do.  This is always a struggle with users and managers that don't get it.  If you're in that situation, I feel for you- document your rationale and see my above #4 so when something bad happens you'll be ready.  If and when you are asked why the bad thing happened, you will have the documentation as to why you were most vulnerable to the bad thing happening in the first place.  Issues like that tend to solve themselves because stalk holders (executives and owners) that have a firm grasp of their business will always put their needs to their business first.  For that reason, it is better to bias towards being more secure that being more open.

Protect your stuff :D

~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ 
Keith C. Perry, MS E.E. 
Owner, DAO Technologies LLC 
(O) +1.215.525.4165 x2033 
(M) +1.215.432.5167 
www.daotechnologies.com

----- Original Message -----
From: "Rich Kulawiec" <rsk@gsp.org>
To: "Philadelphia Linux User's Group Discussion List" <plug@lists.phillylinux.org>
Sent: Friday, October 21, 2016 4:40:26 PM
Subject: Re: [PLUG] spamassassin help: create a rule to score by sender TLD

On Fri, Oct 21, 2016 at 06:04:09PM +0200, ac wrote:
> congratulations on your book on mail systems defense, i truly hope you
> are not also suggesting, in a book, that people should block entire
> tld, like .me (for example about.me and so many SF startups use .me)
> like you have advocated here (and are doing yourself)

I suggest, as I pointed in my long message, that people analyze and
understand their own operational needs, and block everything that they
don't need/want.  I happen to block .me *here* because careful, detailed
analysis showed that mail traffic arriving *here* from .me was almost
all spam.  To five and a half 9's.  I don't block it elsewhere because
careful, detailed analysis there didn't show the same thing.  The same is
true of (nearly) every rule in the mail system configuration: they're all
customized based on analysis -- well, and an enormous amount of
personal experience with mail servers of many sizes and descriptions
and purposes.  *This* server has the entire country of China firewalled
out -- not just SMTP, but all IP traffic.  Another server I run has none
of it firewalled.  And another one maintains a separate MX solely for
traffic from China, which is treated differently than other traffic.
(Why?  Because they need it, but they've been frequently phished.
So it's special-cased in order to minimize the risk.  Not that hard
to do for a one-off, would be tedious if there were 50.)

So I'll say it one more time: analyze your logs.  You have to know
what your mail server is doing (or not doing) in incredible detail along
with what you *want* it to be doing in order to get it to actually
conform to your requirements.  But we are WAY past the time when
"allow everything and try to sanitize it" is workable, and frankly,
very few operations actually need it anyway.  (If you're GMail: sure.
If you're Bob's Donuts in Dubuque: no.)

---rsk


___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug
___________________________________________________________________________
Philadelphia Linux Users Group         --        http://www.phillylinux.org
Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce
General Discussion  --   http://lists.phillylinux.org/mailman/listinfo/plug