| ac on 23 Oct 2016 17:29:31 -0700 |
[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]
| Re: [PLUG] spamassassin help: create a rule to score by sender TLD |
Keith, You are still confused. You are also, still confusing the issues. I will try to say it in another way, to try educate/help you: ****************************************************************** Blocking the entire .me TLD is extremely random thing to do. There is no technical or any other reason to block a TLD Except your feelings. So, if you, like Rich, "feels" that you need to do that, this is fine, but there is not reason to tell other tech's that this is a good idea... As it is not. Be honest and truthful, say" It is an emotional issue for me, I do not like the .me TLD because it has two letters or it looks ugly... etc. ****************************************************************** Then, blocking 116 ranges is something that we are also doing at the moment, they are also routing rogue AS, look the the RR lists... hth Andre On Sun, 23 Oct 2016 19:01:10 -0400 (EDT) "Keith C. Perry" <kperry@daotechnologies.com> wrote: > "The problem here is that you cannot argue one issue by commenting on > another as it only serves to confuse and obtuse. > > What he is EXACTLY WRONG about is to randomly block TLD's - or any > NAME because he "feels" something." > > It wasn't my intent to confuse but I am being very exact in my > statement and in that regard, my statement is ONLY about that point I > commented on. > > You are also right as singular point. I haven't been tracking this > thread that closely. I will say that "randomly" does not imply > "understand their own operational needs" as Rich points out so I > think both those state can be true at the same time but Rich can > comment for himself. > > For me, I will say that my iptables rules dynamically block and > throttle sources all the time so in that regard I have "random" > blocking going because unless I check it I don't know what source are > being blocked- nor does it matter because it blocks are specific to > the exact source and they expire on their own. The only major wide > static block is one particular class A net in India (61/8). I could > probably remove it since the dynamic rules would clip any abuse. > > FWIW my more consistent source being blocked right now in is 116/8 > (some host in China's Guangdong province). Mostly China some Vietnam > nets but I get why people would just block 116/8 or similar. > > > > ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ ~ > 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: "ac" <ac@main.me> > To: "Keith C. Perry" <kperry@daotechnologies.com> > Cc: "Philadelphia Linux User's Group Discussion List" > <plug@lists.phillylinux.org> Sent: Sunday, October 23, 2016 3:04:37 PM > Subject: Re: [PLUG] spamassassin help: create a rule to score by > sender TLD > > On Sun, 23 Oct 2016 14:42:44 -0400 (EDT) > "Keith C. Perry" <kperry@daotechnologies.com> wrote: > > > 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. > > > > And you are also right. > > The problem here is that you cannot argue one issue by commenting on > another as it only serves to confuse and obtuse. > > What he is EXACTLY WRONG about is to randomly block TLD's - or any > NAME because he "feels" something. > > So, just because I can say, with confidence that 1+1 = 2 > > This does not mean that it proves that 1+4 = 7 > > As it does not. > > No matter how long you write about 1+1 being equal to two - as nobody > is saying that people should not "analyze and understand their own > operational needs" > > but what is being said is that blocking an entire TLD like for > example .me - which You also seem to have no problem with... actually > makes any technical, reasonable or any other type of sense. > > AS YOU SHOULD NOT BE BLOCKING RANDOM NAMES just because you think your > spam comes from .me > > Factually: > > TLD's do not send email. > > An IP number does. > > When you stand up and throw your weight behind any sill argument that > it is okay to start blocking random names, what does this say about > you and what you think and what you support? > > You say you have been involved in the Internet since inception as > well? > > I only received my first spam in 1986, so I am not asgrey as you are, > and I am not yet senile either. > > Andre > > > > > > > > > > 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 > > ___________________________________________________________________________ > 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 ___________________________________________________________________________ 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