Re: [Fail2ban-users] Reversing fail2ban (or, success2welcome)

[Tom H. <to...@wh...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/04/2013 04:43 PM, Fabian Wenk wrote:
> 
> If this works, then something like this should happen:
> 
> 1. user logs in to the web authentication 2. fail2ban sees the
> entry in the logfile and executes the actionban (to open the
> firewall) 3. user can use the service (short delay, as fail2ban
> needs a moment to see the log entry) 4. the bantime is reached and
> fail2ban executes the actionunban (to block again, but the shell
> scripts does delay its execution) 5. the web authentication does
> the refresh 6. fail2ban sees the entry in the logfile and executes
> the actionban (to open the firewall) again 7. the shell script
> checks the fail2ban.log for the just done actionban and does abort
> (else it will block the client) 8. again run step 4. to 7. until
> the user does close the web authentication 9. the user has closed
> the web authentication 10. the bantime is reached and fail2ban
> executes the actionunban (to block again, but the shell scripts
> does delay its execution) 11. no refresh from the web
> authentication, so from fail2ban's view it stays in unban 12. the
> shell script checks the fail2ban.log, but there is no new actionban
> entry, so it finally executes the actionunban and blocking the port
> again for this IP address

This might be overdone. Since you actually vcan trust the remote ip
generating the access request initiated by the web interface, I don't
see a reason to leave the firewall open for a longer period of time,
f.i. 3 or 8 hours. Then unban/close fireqwall action from f2b would
then serve as a cleanup action only.

For insecure environments, you could implement a 'logout' action in
the access request interface, that triggers another f2b action that
explicitly closes the firewall again.

Anyway, the more I think of this, the more I get the feeling that f2b
is not the right tool for the job. An access request webpage that
simply executes iptables commands itself, and a cronjob to cleanup
leftover connections seem a less error-prone solution for me: less
components involved, lower risk that something fails...

- --
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJREMNSAAoJEJPfMZ19VO/1LHoP+QEf7e5F9kPRP0iwXoeKTS1m
pHTMe0Xe6HRsV5alZedlUd8C6YEhoO6ziKUPATg13GhSbzPU+dTb+TCXx+mDZ4r/
6pDWh0KT48lR4qwr1l0py4TBMpxFCQHfJ40nvgwwMgdwuNX2JuQc6z2XtasuadmN
/E7WJYRZxNKQYMfkQQW340/W7LIMmeESWviJ3XzwAz0VD0re+NpIYekz6Vo6d/zC
jve1yjXSD/SDjCfm0HtG2BXMpFvAOZD/lTmVSPfLbsXlmV9csITjBUWqZOm5ZJ5O
6P+rO96UIFbLwjQ1SC4QPbO6gQbyia67vUPHcnGqIMx2aFtFD5tvol5BDrOcurhl
pqJjXITQcfOEY0PJJuEr0qa8yR4FLq/0qjuE37NCJqWaAqMik2m7tCgEAi0F2ebl
kbn1p3FBPZi1WxUN43gWzHKJMokLD17dftbZlZIQhJYk5a5Be6f9WdV12YVJ9bNz
WHG+5bmCrOkaOQaYBD/sA4n5I8MqMaomMekc8+qTF60EkA5VOxEtXTbiVxMSNH39
uvTorwcWnmgnks9NA2XtQ+yIaMSxrgmuvVbhTSHtJoWjaJsMcNDQqohVc3+cJwAb
eeGqKBNiGR6TbPaNH2f3ROyLi2JqHa7W8mPtD0TxA0bEgmCFEMalUkI9H/fJlPf4
Epw4DUiC5ACJtxpOCf5H
=1RuE
-----END PGP SIGNATURE-----