We already have a spammer:member name => 《removed》. It may be a case of identity theft. This needs to be looked into in a serious way. The forum will very quickly become unusable if this is not dealt with soon. My suggestion is to limit the number of posts a member can make to begin with. Slow down automated spam by forcing small waiting periods between consecutive posts. Employ filters to flag typical spam words like viagra and alert moderators when these events occur.

EDIT 1: Inform regular users not to respond to spam posts.

EDIT 2: These first spam posts may be just to test the forum's defence capabilities. A DDoS (mass spam) attack may be being planned.

《Removed》

Admin edit: removed personal details pending investigation

True , i have see it , until now he had spawmed a lot of the same topic ....... Lets wait for a ADM

Hi Jason, thanks also for removing the details from my post. Once there's a report feature in place, it will be possible to alert a moderator privately. I love this forum already. :)

It looks like we have another active perpetrator right now. I'll save the details this time: in case you need me to point to the offending posts.

As well as reporting procedure, the admin should sensibly have a handling policy. This means they are unlikely to currently have one. Luckily, some of us have a clue.

What I suggest be done is first you take the IP used to sign up with, and whois it. If for some reason it returns rDNS instead of IP then "nslookup" (I think that's common across OS's) or ping will produce an IP from that. To use the IP I'm using to connect to here through as an example, it should return contents similar:

   [eyer@Supay ~]$ whois 149.255.98.121
 [Querying whois.arin.net]
 [Redirected to whois.ripe.net]
 [Querying whois.ripe.net]
 [whois.ripe.net]
 % This is the RIPE Database query service.
 % The objects are in RPSL format.
 %
 % The RIPE Database is subject to Terms and Conditions.
 % See http://www.ripe.net/db/support/db-terms-conditions.pdf

 % Note: this output has been filtered.
 %       To receive output for a database update, use the "-B" flag.

 % Information related to '149.255.96.0 - 149.255.99.255'

 % Abuse contact for '149.255.96.0 - 149.255.99.255' is 'abuse@openitc.co.uk'

 inetnum:        149.255.96.0 - 149.255.99.255
 netname:        OPENITC-20110817
 descr:          OpenITC
 country:        GB
 admin-c:        OPEN9-RIPE
 tech-c:         OPEN9-RIPE
 status:         ASSIGNED PA
 mnt-by:         SEAN-MNT
 mnt-lower:      SEAN-MNT
 mnt-domains:    SEAN-MNT
 mnt-routes:     GB10488-RIPE-MNT
 created:        2011-08-22T15:02:12Z
 last-modified:  2011-09-02T15:05:13Z
 source:         RIPE

 role:           OpenITC DBM
 address:        International House
 address:        24 Holborn Viaduct
 address:        CITY OF LONDON
 address:        London
 address:        EC1A 2BN
 address:        United Kingdom
 abuse-mailbox:  abuse@openitc.co.uk
 admin-c:        SEAN-RIPE
 tech-c:         SEAN-RIPE
 nic-hdl:        OPEN9-RIPE
 mnt-by:         SEAN-MNT
 created:        2011-08-18T10:19:36Z
 last-modified:  2016-05-08T17:01:06Z
 source:         RIPE # Filtered

 % Information related to '149.255.96.0/22AS20860'

 route:          149.255.96.0/22
 descr:          OpenITC
 origin:         AS20860
 mnt-by:         GB10488-RIPE-MNT
 created:        2011-08-30T09:52:30Z
 last-modified:  2011-08-30T09:52:30Z
 source:         RIPE

 % This query was served by the RIPE Database Query Service version 1.88 (ANGUS)

Of primary interest in that glob is the abuse mailbox. Any responsible provider will not tollerate abuse. Sending emails to that, with logs or extracts of highlighting abusive use usually results in swift action taking the offensive unit offline. If there is no abuse mailbox, or NOC contact listed, then you can usually trace one back from the firm that runs the operation. This serves two main purposes:

• It prevents it from being used again, here or somewhere else
• It costs these criminals money when they do not get a refund on the services they have paid for. Some services even incur additional charges on reciept of abuse reports.

Software like fail2ban can be tailored to perform this(and the following) action autonomously.

In the rare cases that this service was not expressly rented for this purpose and was compromised by hostile third parties for this purpose, then don't feel guilty about getting their serivces stamped on, they've just demonstrated why they are unworthy of operating these, and their incompetence forms a danger to everyone else.

After lodging abuse reports(your ticketing system should be used to track this from your end, additionally), then look at the email used to sign up with. Here I would suggest the use of software like "maltego" to graph the attacks and evidence behaviours. I've only seen manual spam runs on here so far, but it's only time before organised botnets. Commonly bots will generate usernames via an algorythm on 'tard services like gmail and other things with low to no signup verification, clock that algorythm and you can prevent signup to this service. I'd personally blacklist such providers, but I sense that's not an entirely viable option here with high numbers of "legitimate" accounts using. You could contact the abuse mail listed for the email services used and attempt to have them shut down services - most are not interested in promoting this sort of behaviour in their users.

After recording and reporting the confirmed hostile event, then the IP should be entered into pf - to assume a table already exists called "badhosts": pfctl -t badhosts -T add 1.2.3.4 should do the trick. I would suggest doing the entire range if the provider isn't residential. Ie for the example listed above, 149.255.96.0/22 will take out that block of the datacenter. Services exist that hoard known public access proxy addresses and TOR exit nodes etc. These should be regularly scraped(hourly or so) and used to augment local system firewall rules to prevent abuse as no-one with legitimate purposes will be using these services. If using something like fail2ban to actually perform this action then it should be possible to have it also keep the list pruned of stale adresses.

Then follow up on the abuse report, it's common to have a resolution in less than 48hrs, it's uncommon to get customer details without LEA credentials. Contacting LEA is somewhat advisable, but in honesty most hold little interest in actually doing anything - even if you highlight how they go about doing it.

I don't think this is a "test of defence capabilities" or it'd of been an automated run of steadily increasing intensity to find out the cut-out point set in IDS (lol, if there is even IDS running). However, I'd expect things like this sooner rather than later.

@EyeR Informative post. Thanks!

Client Fingerprints and honeypots will successfully protect this software for being spammed. All efficient 3rd-party service dependencies for content approval will slow down the overall performance of this forum.

Maintaining local firewall lists shouldn't decrease performances - I've had thousands of ranges with no detriment. Scraping third party sites for this data shouldn't be noticable either, especially if done with a wide update period, like hourly.

Client fingerprints are easily spoofed, for a case in point, what my client is reporting as when I compose this post. Nothing. But it's an applicable layer to deploy as counterance to those who only run on defaults. However, anyone worth worrying about will be adjusting reported to read in the whitelist.

"content approval will slow down the overall performance of this forum"

My suggestion was to introduce a time delay between the first few posts. This would limit the damage caused, because spammers don't tend to make any other kind of post: instead they attack as many public spaces as they can. It is generally very easy to spot these individuals. If there are better methods that avoid false positives, then there will be benefits in using them. The initial (however many) post limit gives genuine citizens time to report any type of transgression: not just spam. Such a measure will not impact functioning of the forum.

Limiting IP access will sooner or later exclude proxy users from the forums. Fingerprints wouldn't. But at the end, the solution is the combination of multiple approaches.

For generating fingerprints this might be useful: https://github.com/Valve/fingerprintjs2

Fingerprints can be easily spoofed by the client. The intent is to exclude proxy users as these services are only really employed in the persuit of something they shouldn't be doing, which is never a good start.