TL;DR

Pingbacks ask your site to contact a remote page and confirm that it links to one of your posts. WP fail2ban Premium can keep XML-RPC blocked generally while allowing only the pingback method. This access policy suits a site that wants pingbacks but has no full XML-RPC client.

When pingback logging is enabled, WP fail2ban Free records accepted pingbacks as soft events and failures as hard events. A fail2ban jail using the soft filter can limit how often one source makes your site send those requests.

That does not eliminate pingback abuse. It gives a site that values pingbacks a pragmatic compromise: preserve the feature without leaving your server freely available to send requests on an attacker's behalf.

Expose the method, not the whole interface

A site may want pingbacks for the conversations and references they create without using XML-RPC for remote publishing or management.

Premium lets you make that policy explicit. The general XML-RPC block remains in place, but WordPress exposes the pingback method needed for the feature.

You preserve the capability you chose without accepting the rest of the interface as an accidental consequence.

Pingbacks-only is an alternative to allowing Jetpack or another trusted source. Do not combine the policies: limiting XML-RPC to pingbacks prevents a full client from using the other methods it needs.

Put a limit on accepted pingbacks

To verify a pingback, WordPress contacts the page that supposedly contains the link. The request leaves your server and reaches that other site. An attacker can exploit the mechanism by making many WordPress sites contact the same target.

When pingback logging is enabled, WP fail2ban records an accepted pingback as a soft event. A fail2ban jail using the soft filter can allow occasional use and act when the same source repeatedly makes your site initiate that traffic.

The rate limit helps protect the remote target by reducing how readily your site can be used to send it requests. You choose the threshold that preserves normal activity without treating every successful pingback as hostile.

Give failures a stronger meaning

WordPress knows when a pingback fails and why. WP fail2ban records the failed operation as a hard event with the source and target involved, giving fail2ban a stronger signal than a successful pingback.

The firewall policy can therefore act when WordPress rejects the operation, helping stop the caller from making your server contact the remote target again.

Keep acceptance and moderation separate

Your XML-RPC policy decides whether the pingback method is available. WP fail2ban records what WordPress does with the request. Marking an accepted pingback as spam is a later moderation decision covered by the comments and spam policy.

WP fail2ban preserves those stages as different events. A pingback that is accepted and later marked as spam can be enforced through the comments and spam policy without making every pingback a spam event from the outset.

More about blocking spam comments, pingbacks, and trackbacks.

Choose the compromise deliberately

Rate limiting reduces how readily your server can be recruited into an attack on another site. It does not remove every risk associated with accepting pingbacks.

If pingbacks are the only reason your site exposes XML-RPC and they add no value, close the endpoint instead. If you do value them, selective exposure and rate limiting make allowing them a defensible policy rather than unrestricted access.

More about XML-RPC policy.