https://discord.umbraco.com logo
Powered by
The Bot That Shouldn’t Have Taken Down M...
# news
j
A client's site was recently taken down by a bot. Here's a post about what happened, and what we did to mitigate the attack. If you've got an Umbraco site with forms (Umbraco Forms, or surface controllers) you probably need this WAF rule. https://dev.to/jasonelkin/the-bot-that-shouldnt-have-taken-down-my-umbraco-site-and-the-waf-rule-that-fixed-it-36o6
m
Rate limiting is a great, surefire way to stop those bots in their tracks! Couple of parallel thoughts.. > Loadbalanced/autoscaling " In Umbraco, every log entry is a disk write operation by default" In a load balanced set up doesn't that file logging also get distributed to the webheads, so a little difficult to navigate and much better centralised into say 
application insights
or 
seq
? So we could mitigate some of the IO by disabling or curtailing the Native filesystem logging, (appsetting below)? Also with serilog (asp.net) we can utilise the provided 
RequestLogging middleware
to make serilog less chatty... Basically squashing multiple logs into a single request entry with all the same info as the multiple entries that would have occurred (the 
IDiagnosticContext
allows you to tailor to your own needs) https://github.com/serilog/serilog-aspnetcore?tab=readme-ov-file#request-logging
Copy code
json
"Serilog": {
  "MinimumLevel": {
    //Verbose|Debug|Information|Warning|Error|Fatal
    "Default": "Information",
    "Override": {
      "Microsoft": "Warning",
      "SixLabors.ImageSharp": "Warning"
    }
  },
  "WriteTo": [
    {
      "Name": "Async",
      "Args": {
        "configure": [
          {
            "Name": "Seq",
            "Args": {
              "serverUrl": "XXXXX",
              "apiKey": "XXXXX",
              "restrictedToMinimumLevel": "Information"
            }
          }
        ]
      }
    },
    {
      // can't place in async as UmbracoFile isn't a real sink implementation...
      "Name": "UmbracoFile",
      "Args": {
        "RestrictedToMinimumLevel": "Fatal"
      }
    }
  ]
},
Nice series here https://andrewlock.net/using-serilog-aspnetcore-in-asp-net-core-3-logging-mvc-propertis-with-serilog/ for enriching that 
IDiagnosticContext
Copy code
csharp
public class SerilogRequestLoggingComposer : IComposer
{
    // can move to prePipeline if we want to log static files.
    // in 13.1.1 can move to preRouting for just after static files 
    public void Compose(IUmbracoBuilder builder)
    {
        builder.Services.AddControllers(opts => opts.Filters.Add<SerilogLoggingActionFilter>());
        builder.Services.Configure<UmbracoPipelineOptions>(options =>
            options.AddFilter(
                new UmbracoPipelineFilter("SerilogRequestLogging", preRouting: app => app.UseSerilogRequestLogging(opt => opt.EnrichDiagnosticContext = SerilogRequestLoggingOptions.EnrichFromRequest))
                )
            );
    }
}
j
Yes, this is pretty much what we do with Application Insights - though we'd usually set the level to Error for the Umbraco File and work to eliminate 500's as much as possible.
This is really cool - thanks for sharing!
11 Views
PreviousNext
Powered by