Bot Protection: fail2ban and Redis Scoring System

Bot Protection: fail2ban and Redis Scoring

Your site is under bot attack — CPU at 100%, server lagging, legitimate users can't log in. We deploy a system that blocks suspicious IPs, cutting off 99% of attacks before they reach the application. With over 7 years of web security experience, we've protected 50+ projects from bots, scanners, and brute force. Our approach—combining fail2ban and Redis scoring—reduces server load by 60% and cuts malicious requests by 10x. This yields 40–60% savings on hosting resources, typically saving $500–$1,500 per month. Implementation costs start at $2,000, with ROI seen within 2 months. Contact us for a consultation on securing your site today.

What Problems Does IP Blocking Solve?

Typical attack scenarios:

• Brute force on admin panels — up to 1000 requests per minute from one IP.
• Vulnerability scanning (access attempts to .env, wp-admin, phpMyAdmin).
• Content scraping and spam submission through contact forms.

Without automatic blocking, these activities drain server resources and can lead to denial of service. Our solution stops them early.

Redis-Based Scoring System

Each suspicious action assigns points to the IP, stored in Redis with TTL. When a threshold (e.g., 100 points) is reached, the IP is blocked for 24 hours. Thresholds and block durations are configurable per risk profile. Typical actions and their weights:

Why Combine fail2ban and Redis?

The fail2ban tool operates at kernel level, blocking IPs before traffic reaches the application — reducing server load 5x compared to application-level blocking. According to fail2ban documentation on Wikipedia, iptables rules process in microseconds. Redis scoring accounts for complex behavior: honeypot, sessions, custom rules. The combination is far better than either alone, handling both simple and sophisticated attacks.

How We Configure fail2ban for Your Application

Fail2ban analyzes web server logs (Nginx, Apache) and blocks IPs at the iptables level. Example configuration for Nginx:

# /etc/fail2ban/filter.d/nginx-scan.conf
[Definition]
failregex = ^<HOST> .* "(GET|POST|HEAD) /\.env.*" .*$
            ^<HOST> .* "(GET|POST) /wp-admin.*" .*$
            ^<HOST> .* ".*\.php\?" .*$

# /etc/fail2ban/jail.d/nginx-custom.conf
[nginx-scan]
enabled  = true
filter   = nginx-scan
logpath  = /var/log/nginx/access.log
maxretry = 5
findtime = 60
bantime  = 86400   # 24 hours
action   = iptables-multiport[name=nginx-scan, port="http,https"]
           %(action_mwl)s  # + email notification

Fail2ban outperforms isolated Redis blocking because it blocks traffic before application processing. But it misses complex behavior — that's where Redis helps.

Redis-Based Blocking in the Application

The Redis scoring system flexibly responds to anomalies within the code. Example middleware in Laravel:

// app/Http/Middleware/BlockSuspiciousIp.php
class BlockSuspiciousIp
{
    public function handle(Request $request, Closure $next)
    {
        $ip = $request->ip();

        // Check Redis blacklist
        if (Cache::has("blocked_ip:{$ip}")) {
            abort(403, 'Access denied');
        }

        // Check suspicion counter
        $suspicionKey = "suspicion:{$ip}";
        $score = (int) Cache::get($suspicionKey, 0);

        if ($score >= 100) {
            Cache::put("blocked_ip:{$ip}", true, now()->addHours(24));
            Log::warning("IP blocked: {$ip}", ['score' => $score]);
            abort(403);
        }

        return $next($request);
    }
}

// Suspicion scorer service
class SuspicionScorer
{
    public function increment(string $ip, int $points, string $reason): void
    {
        $key = "suspicion:{$ip}";
        Cache::increment($key, $points);
        Cache::put($key, Cache::get($key), now()->addHour());

        Log::info("Suspicion score", ['ip' => $ip, 'points' => $points, 'reason' => $reason]);
    }
}

// Usage
$scorer->increment($ip, 20, 'failed_login');
$scorer->increment($ip, 50, 'honeypot_triggered');
$scorer->increment($ip, 10, 'rate_limit_exceeded');

Integration with AbuseIPDB and Honeypot

AbuseIPDB is a reputation database containing millions of malicious IPs. We integrate via API: on incoming request, we check the confidence score. If above 50%, the IP is blocked immediately. We cache the result for one hour to reduce API load.

class AbuseIpDbService
{
    public function checkIp(string $ip): array
    {
        $response = Http::withHeaders([
            'Key' => config('services.abuseipdb.key'),
            'Accept' => 'application/json',
        ])->get('https://api.abuseipdb.com/api/v2/check', [
            'ipAddress'    => $ip,
            'maxAgeInDays' => 90,
        ]);

        return $response->json('data');
    }

    public function isSuspicious(string $ip): bool
    {
        $data = Cache::remember("abuseipdb:{$ip}", 3600, fn() => $this->checkIp($ip));
        return $data['abuseConfidenceScore'] > 50;
    }
}

Honeypot routes — URLs that real users never visit. Any request to them assigns high suspicion points. Examples:

// Routes never hit by real users
Route::any('/wp-admin', function(Request $request) {
    app(SuspicionScorer::class)->increment($request->ip(), 80, 'honeypot_wp_admin');
    abort(404);
});

Route::any('/.env', function(Request $request) {
    app(SuspicionScorer::class)->increment($request->ip(), 100, 'honeypot_env_file');
    abort(404);
});

How to Avoid False Positives

To minimize false positives, we add a whitelist for trusted subnets: Cloudflare, Googlebot, internal IPs, known partners. Blocks are temporary — with TTL (e.g., 24 hours). After the block expires, the IP can work normally if it doesn't repeat attacks. Example command to clean expired blocks:

// Command to clean expired blocks
class CleanExpiredBlocksCommand extends Command
{
    protected $signature = 'security:clean-blocks';

    public function handle(): void
    {
        // Redis TTL handles this automatically
        // For database storage:
        BlockedIp::where('expires_at', '<', now())->delete();
    }
}

// Whitelist for known sources
$whitelist = ['10.0.0.0/8', '192.168.1.0/24', '1.2.3.4'];
// Cloudflare IP ranges — never block

What's Included

After implementation, we deliver:

• Full architecture documentation
• fail2ban configuration with custom filters
• Redis scoring system with AbuseIPDB and DNSBL integration
• Honeypot routes
• Monitoring dashboard with block statistics
• Training for your engineers
• One month of technical support after deployment

Implementation Process

1. Audit current stack — analyze logs, load, attack types (1 day).
2. Configure fail2ban — custom filters for your application (1 day).
3. Develop Redis scoring system — integrate into code, connect AbuseIPDB and DNSBL (3–5 days).
4. Create honeypot routes — decoys for bots (1 day).
5. Test and monitor — dashboard with statistics, train your engineers (1–2 days).

Results and Metrics

Comparison of approaches:

After implementation, we guarantee a 80–99% reduction in malicious traffic and at least a 60% reduction in server load. Contact us to discuss the details of securing your project.

Web Application Security: HTTPS, CSP, XSS, CSRF, WAF, DDoS Protection

A website breach rarely looks like in movies. More often it's: a bot finds an unprotected /admin/export endpoint, downloads the customer database, and closes the connection. Or: through an outdated WordPress plugin, a web shell is uploaded, and the server starts sending spam. Or quieter: an XSS in a comment field allows stealing admin session cookies, unnoticed for months. We have analyzed dozens of such cases — each vulnerability could have been fixed at the development or audit stage.

Web application security is not a single setting. It's layers of protection, each closing a separate class of attacks. Order an audit — we'll assess the project and deliver a turnkey plan within 2–4 weeks.

How do we ensure comprehensive web application security?

HTTPS and Proper TLS Configuration

HTTPS is the minimum mandatory level. But having an SSL certificate and having a properly configured TLS are different things.

In Nginx/Apache configuration we check:

• Protocols: only TLS 1.2 and TLS 1.3, SSLv3 and TLS 1.0/1.1 are disabled
• Cipher suites: prefer ECDHE (Forward Secrecy), remove NULL, RC4, DES, 3DES
• HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) — browser will never make insecure requests
• OCSP Stapling — speeds up certificate revocation check
• Redirect 301 from HTTP to HTTPS — both in server config and code (double redirect causes SEO weight loss)

Check: SSL Labs (ssllabs.com/ssltest) should show A or A+. If B, the configuration is weak.

Let's Encrypt + Certbot for production is standard. Automatic renewal via certbot renew in cron. Wildcard certificates for subdomains via DNS-01 challenge.

Content Security Policy: The Most Powerful and Complex Protection

CSP is an HTTP header that tells the browser which sources are allowed to load resources. A properly configured CSP completely blocks most XSS attacks, even if the vulnerability exists in the code.

The problem: breaking the site with an incorrect CSP is easy. default-src 'none' — and fonts, images, JS stop working. So we start with Content-Security-Policy-Report-Only — CSP logs violations but does not block anything. We monitor reports for 2–4 weeks, refine the policy, then switch to enforcement mode.

Example of a real policy for a site with Google Analytics, Google Fonts, and Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — a random string generated server-side per request. Inline scripts with the correct nonce are allowed; without nonce, they are blocked. This completely breaks XSS via <script>alert(1)</script>.

'unsafe-inline' in style-src is a compromise for inline styles. It's better to remove it by moving all styles to CSS files, but that requires refactoring.

Why XSS Remains the Most Common Vulnerability?

XSS (Cross-Site Scripting) — injection of JS code through user input. According to OWASP, XSS is in the top 3 web application vulnerabilities. Three types:

Protection: never insert user input into HTML without escaping. In PHP — htmlspecialchars() with ENT_QUOTES. In Laravel Blade templates — {{ $var }} is safe, {!! $var !!} is dangerous. In React — {variable} is safe, dangerouslySetInnerHTML is dangerous. For Rich Text — use htmlpurifier on PHP or DOMPurify in the browser.

CSRF: Protecting Forms and APIs

CSRF (Cross-Site Request Forgery) — an attacker forces the victim's browser to send a request on their behalf. Example: a user is logged into a bank, opens a malicious page, which makes fetch('https://bank.ru/transfer?to=evil&amount=50000') — if the bank is unprotected, money is transferred.

CSRF tokens — standard protection for forms: the server generates a random token, stores it in the session, and inserts it as a hidden field in the form. On POST request, the token is verified. The attacker does not know the token. Laravel does this automatically with @csrf.

SameSite cookies — modern protection: SameSite=Strict or SameSite=Lax prevents the browser from sending cookies in cross-site requests. Works in all modern browsers.

API without sessions (JWT, Bearer tokens) — CSRF is irrelevant if the token is not stored in a cookie (but in the Authorization header or localStorage). However, localStorage is vulnerable to XSS — so for sensitive data, HttpOnly cookies with SameSite are preferable.

WAF and DDoS Protection

WAF (Web Application Firewall) filters HTTP traffic for attacks: SQL injection, XSS, path traversal, known exploit patterns. Options:

• Cloudflare WAF — cloud-based, OWASP Top 10 rules out of the box, custom rules via expressions. Managed Rules automatically block new threats.
• ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Flexible but requires tuning and monitoring of false positives.
• AWS WAF — for infrastructure on AWS, integrates with CloudFront and ALB.

DDoS protection. Cloudflare at L3/L4/L7 is the de facto standard for most sites. Automatic mitigation of volumetric attacks, Under Attack Mode during active attacks. For critical infrastructure — Cloudflare Magic Transit or specialized solutions (Qrator, StormWall for the Russian market).

Rate Limiting at the application level — an additional layer. Laravel ThrottleRequests middleware: 60 requests per minute per IP for general endpoints, 5 for /login and /password/reset. Redis as a counter store — mandatory for horizontally scalable systems (otherwise limits are not synchronized between servers).

Other Mandatory Measures

Security headers. Besides CSP: X-Frame-Options: DENY (clickjacking protection), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (restrict browser API access: camera, microphone, geolocation).

SQL injection. Prepared statements everywhere. No concatenation of user input into SQL strings. ORM (Eloquent, Doctrine) protects by default. $wpdb->prepare() in WordPress is mandatory.

Dependency updates. composer audit and npm audit in CI/CD pipeline. Dependabot or Renovate for automatic PRs with updates. Critical CVEs — patch within 24 hours.

Secrets and configuration. .env — never in Git. Secrets in production — via CI/CD environment variables (GitHub Secrets, GitLab CI Variables) or HashiCorp Vault. Leak detection: git-secrets, truffleHog in pre-commit hooks.

How We Work

1. Audit — code scanning, configuration review, dependency analysis, manual business logic verification.
2. Planning — vulnerability remediation plan, stack selection (CSP, WAF, rate limiting).
3. Implementation — TLS setup, CSP configuration, headers, Rate Limiting, WAF.
4. Testing — re-penetration test, load testing, false positive check.
5. Deployment and Monitoring — enable production CSP, set up alerts, train the team.

What's Included

• Report with found vulnerabilities and recommendations (PDF + code snippets)
• Ready TLS configuration (Nginx/Apache)
• CSP policy with Report-Only and production versions
• WAF and Rate Limiting setup
• Dependency update plan
• Access to monitoring tools (Sentry, Datadog)
• 30 days of post-audit support (consultations, fixes)

Timeline and Cost

The budget is calculated individually — contact us for a project evaluation.