Koozali.org formerly Contribs.org

Changes in spam attacks

Offline holck

  • *
  • 274
Changes in spam attacks
« on: May 14, 2019, 07:58:42 AM »
A year ago or so, for me, most spam attacks were caught by blacklists and fail2ban. But I'm seeing a new behavior. Now most spam attacks are login-attempts to the smtp-server, and they come from a very broad range of IP-addresses. So fail2ban can't help much, unfortunately.

Here are some stats from my server:
Code: [Select]
Queued:       133 (2 marked as spam)                                                                                                                                                                                         
Denied:      2318                                                                                                                                                                                                             
  Failed Authentication:    1934 (83 %)                                                                                                                                                                                       
  SSL failed:                129 ( 6 %)                                                                                                                                                                                       
  DNSBL:                     112 ( 5 %)                                                                                                                                                                                       
  FQDN required:              40 ( 2 %)                                                                                                                                                                                       
  RHSBL:                      39 ( 2 %)                                                                                                                                                                                       
  Early Talker:               22 ( 1 %)                                                                                                                                                                                       
  Invalid DMARC:              13 ( 1 %)                                                                                                                                                                                       
  Resolvable fromhost:        11 ( 0 %)                                                                                                                                                                                       
  Spamassassin:               10 ( 0 %)                                                                                                                                                                                       
  Relaying Denied:             7 ( 0 %)                                                                                                                                                                                       
  URIBL:                       1 ( 0 %)

Blacklists:                                                                                                                                                                                                                   
  Spamhaus:           116 (76 %)                                                                                                                                                                                             
  Uribl.com:           29 (19 %)                                                                                                                                                                                             
  Barracuda:            4 ( 3 %)
  Surbl.org:            3 ( 2 %)

Most active IP addresses:
  134.209.248. 73:   189
  185.222.209. 47:   176
   45.227.253.101:   160
  185.222.209. 56:   124
  165.227.218.191:    89
  165. 22. 95.116:    88
   46.232.112. 23:    73
  141. 98. 80. 46:    48
  219.154. 17.117:    45
   45.227.253.100:    42

                                                                                                                                                                               
                                           
......

Offline mmccarn

  • *
  • 2,415
Re: Changes in spam attacks
« Reply #1 on: May 14, 2019, 02:21:03 PM »
I was seeing the same thing until I modified the 'helo' plugin https://forums.contribs.org/index.php?topic=53223.15 to block connections during 'helo' instead of allowing them to attempt authentication first.  This works for me, but could block roaming or remote users in some instances.

I've also implemented the emerging threats blocklists on my server along with the firehol update-ipsets block lists on my firewall. (My notes on this are somewhat tangled at present, and might not be particularly useful...)

Here are my recent stats:
Code: [Select]
Queued:      1374 (2 marked as spam)
Denied:       589
  HELO/EHLO rfc:             408 (69 %)
  Greylisting:                76 (13 %)
  Naughty (DNSBL):            72 (12 %)
  Early Talker:               16 ( 3 %)
  RHSBL:                      10 ( 2 %)
  Failed Authentication:       3 ( 1 %)
  Resolvable FromHost:         3 ( 1 %)
  Relaying Denied:             1 ( 0 %)
  SMEOptimizer:                0 ( 0 %)
  Naughty:                     0 ( 0 %)
  DNSBL:                       0 ( 0 %)
  URIBL:                       0 ( 0 %)
  Invalid Host:                0 ( 0 %)
  Spamassassin:                0 ( 0 %)
  Virus:                       0 ( 0 %)
  TLS/SSL Problem:             0 ( 0 %)
  Unrecognized Commands:       0 ( 0 %)
  Server Overloaded:           0 ( 0 %)

Blacklists:
  Spamhaus:            46 (56 %)
  Gbudb:               21 (26 %)
  Dnsbl:               12 (15 %)
  Spamcop:              2 ( 2 %)
  @400000005cd4f9f921dafff4 28796 (deny) logging::logterse: ` 73:    1 ( 1 %)

Most active IP addresses:
  108.174.200.214:   291
  192.168.200.  1:    20
   89. 38.150.163:    10
   94.177.241.246:     6
   89. 36.213. 74:     6
   94.177.240.167:     5
  187. 60.216.196:     4
   92. 87. 41. 93:     4
  201.158. 37.116:     4
  105.228.132. 92:     4

(The oddball entry under 'blacklists' is due to a misconfiguration of the barracudacentral DNSBL service, I hope...)


My current theory on failed login attempts goes like this:
- Criminal organizations, governments, or others maintain databases of internet-accessible system fingerprints - what services are running, what versions, etc.  These databases will accrete information from any system that leaks information to which the monitoring organization has access.  If they can hack your ISP, the database would include logs of online services visited from your network, possibly usernames, email correspondents, etc.  They might use google or facebook ads, or compromised websites, to harvest information on your systems and users for their database.  It is important to realize that none of this may be targeted specifically at you - the objective is 'google-esque' - gather information from everywhere, correlate what can be correlated, and save the rest in case it correlates with some other data in the future.

- These orgs then setup processes to monitor the systems and users cataloged in their database - the monitoring system generates the failed logins while serving several simultaneous functions:
  1) allowing a slow-motion dictionary attack
  2) allowing compromised credential databases to be targeted where appropriate (since they could have harvested your users' facebook usernames and associated email addresses, if they get their hands on facebook's password database they can immediately try your users' facebook usernames and passwords on your server)
  3) development of a 'social network' for your server - who communicates with whom and what they talk about.  This information can be used in social engineering attacks ("hey jim - check out this PDF", etc)
  4) monitoring that the identified services remain accessible so that new data or vulnerabilities can be applied immediately.
  5) attack debugging -- if the database includes 1000 systems with the same service exposed, an attack under development can be debugged against a small subset of systems, fine-tuned, re-tried on another subset, etc.

- When a zero day vulnerability surfaces, or a new credential database is hacked, your server (if vulnerable) or users (if included in the credential database) will be attacked according to the priority that has been assigned to your resources in the attacker's database.  Minutes or hours, rather than days or weeks as we are accustomed to thinking.

My conclusions from this paranoid theoretical scenario:
- security patches must be installed as quickly as possible (within hours of release, if possible)
- fail2ban may not be quick enough to block an attack -- if an attacker already has a profile of my server and becomes aware of a new vulnerability the attacker may need only a single connection to effect a compromise.
- IP blocklists such as emergingthreats and the firehol update-ipsets lists give me the best chance to block traffic from malicious hosts based on the experience of others before the attackers get around to my server.
- Traditional passwords cannot be trusted to provide real security. 2FA or device fingerprinting plus passwords should be implemented as quickly as feasible.
- Users must be trained to identify social engineering attempts

[apologies for hijacking your post...]

Offline ReetP

  • *
  • 2,054
Re: Changes in spam attacks
« Reply #2 on: May 14, 2019, 06:11:05 PM »
Quote
Users must be trained to identify social engineering attempts

That is the single best line of defence that you have for any attack.

Invest in your users. Help train them to spot stuff. They are smarter than any piece of software (surprisingly !)

I have done this for years and it has been the most cost effective method.

Makes the user feel good about themselves when they call me and say "I just saw this fishing attack - trashed the bastard" or whatever.

Yeah, the easy thing is to pretend they're stupid and just throw software at the issue.

IMHO that is the IT industry letting itself, and its users down (probably just for more profit).

My 2c worth :-)
...
1. Read the Manual
2. Read the Wiki
3. Don't ask for support on Unsupported versions
4. I have a job, wife, and kids and do this in my spare time. If you want something fixed, please help.

Bugs are easier than you think: http://wiki.contribs.org/Bugzilla_Help

If you love SME and don't want to lose it, join in: http://wiki.contribs.org/Koozali_Foundation