MVC应用可疑活动追踪：日志显示内网IP的原因与应对疑问

Hey there, let's work through your questions step by step—this sounds like a classic automated attack scenario, so let's break it down:

Why are you seeing private 172.31.#.# IPs? #

Those IPs are AWS EC2 private network addresses, not from users using VPNs. The most likely reason is your MVC app sits behind a reverse proxy or load balancer (like AWS Application Load Balancer/NLB). When requests come in, they first hit the proxy, which then forwards the request to your app. So Request.UserHostAddress picks up the proxy's private IP instead of the real client's public IP.

If you're not seeing the real client IP in X_FORWARDED_FOR, it's probably because your proxy isn't configured to pass that header through to your app. Many proxies require explicit settings to inject the original client IP into headers like X-Forwarded-For or X-Real-IP.

Is your IP logging method incorrect? #

Your current code has a couple of gaps:

1. X_FORWARDED_FOR can be a comma-separated list: If requests pass through multiple proxies, this header will have multiple IPs (e.g., client-ip, proxy1-ip, proxy2-ip). You need to extract the first non-proxy IP in the list.
2. Don't trust X_FORWARDED_FOR blindly: Clients can forge this header if they're not going through your trusted proxy. You should first verify the request is coming from your known proxy IP range (like 172.31.0.0/16 for AWS) before using this header.

Here's a more robust approach for logging:

string clientIp = Request.UserHostAddress;
// Define your trusted proxy IP ranges (adjust based on your infrastructure)
var trustedProxyPrefixes = new List<string> { "172.31." };

// Only check X_FORWARDED_FOR if the request comes from a trusted proxy
if (trustedProxyPrefixes.Any(prefix => clientIp.StartsWith(prefix)))
{
    var forwardedFor = Request.ServerVariables["X_FORWARDED_FOR"];
    if (!string.IsNullOrWhiteSpace(forwardedFor))
    {
        // Split the list and take the first valid client IP
        clientIp = forwardedFor.Split(',')
                               .Select(ip => ip.Trim())
                               .FirstOrDefault(ip => !trustedProxyPrefixes.Any(p => ip.StartsWith(p))) ?? clientIp;
    }
}

// Combine with user info for logging
string userIdentifier = SessionSecurity.CurrentNameFromCookie() ?? "Unknown User";
string logContent = $"User: {userIdentifier}, IP: {clientIp}";

How to effectively block these attacks? #

The behavior you're seeing—scanning for non-existent paths (like /wls-wsat/CoordinatorPortType, a known WebLogic vulnerability endpoint) and brute-force login attempts—is definitely automated attack traffic (likely from botnets looking to exploit vulnerabilities or install crypto miners). Here are actionable steps to block them:

• Enable a Web Application Firewall (WAF): Tools like AWS WAF can automatically detect and block common attack patterns (path scanning, brute force) using pre-built rules. This is the most effective first line of defense.
• Rate limit login attempts: Implement a rule that blocks an IP after N failed login attempts (e.g., 5 attempts in 10 minutes). You can use libraries or built-in features in your MVC framework to handle this.
• Block suspicious IPs: Manually or automatically add IPs that repeatedly scan paths or attempt brute-force logins to a firewall blacklist. Many cloud providers let you manage IP rules at the network level.
• Hide sensitive response details: Don't expose your MVC framework version or server info in HTTP headers—this removes clues attackers use to target specific vulnerabilities.
• Return generic 404s: For non-existent paths, return a simple 404 without detailed error messages. Avoid giving attackers feedback about what paths might exist.

Is this just internal application errors, or actual attacks? #

This is 100% automated attack traffic, not internal errors. Internal application issues would generate consistent, repeatable errors tied to your app's functionality—not random scans for obscure endpoints or mass attempts to log in with unknown usernames. The /wls-wsat/ path is a dead giveaway: it's a target for older WebLogic vulnerabilities, and attackers scan the internet en masse looking for unpatched servers.

内容的提问来源于stack exchange，提问作者JED