smartinez87
New Fail2ban notifier
A fail2ban notifier that creates a log file with every exception so you can parse it with fail2ban.
See file comments for fail2ban configuration (which you can also add to the wiki, I'll try adding them myself, but not sure if I got perms).
This PR- references https://github.com/smartinez87/exception_notification/issues/205
Coverage decreased (-3.03%) when pulling 30b3302fd721a221fc83dc509f0114680124f78d on etdsoft:issue-205 into 8a8c6a4c1f48fa49aa98328b3379f5a4a5596b32 on smartinez87:master.
Coverage decreased (-1.43%) when pulling b13628c392f14c4511ea0e646aa80513114ef162 on etdsoft:issue-205 into 8a8c6a4c1f48fa49aa98328b3379f5a4a5596b32 on smartinez87:master.
Hey @etdsoft,
I was just reading your blog post on this and spotted a potential problem with the code, so thought I would report it here for your consideration:
Using the ActionDispatch::Request#remote_ip method to determine the acting IP is opening up the module for easy circumvention and potential Denial Of Service for legit users.
ActionDispatch::Request#remote_ip usually defers the IP detection to the ActionDispatch::RemoteIp Middleware, which does some magic detection of the remote IP by looking at various request headers, such as X-Forwarded-For, in case the application is sitting behind Nginx or another proxy. This usually makes sense to do, but it also makes it possible for a malicious client to spoof the origin of the request by adding the X-Forwarded-For header to their requests. This makes it relatively trivial to circumvent the banning by shuffling between random IPs. It also opens up the possibility for the attacker to actively deny access to legit users by flooding the server with malicious request and spoofing the legit user's IP or even a whole IP range.
