Thenothing has asked for the wisdom of the Perl Monks concerning the following question:

Dear friends, hello again, I hope you are doing fine

This thread is not relation to problem with code, but relation to opinión about this idea I implement for fun and test if work, all end work.

the target, is detect unsuccessful logins from user ip, and show recaptcha after 15 Attempts

I was looking for a way to keep records of failed attempts, but all information about this was create a database and save the records, time, user, unsuccessful logins, in the end I not want to install a db aplication, then I remember how work Fail2ban (Fail2ban scans log files (e.g. /var/log/apache/error_log) and bans IPs that show the malicious signs)

So I implement this method with this feautures:

* auto create file, when the file does no exist

* used pure perl to read and write file with open function

* used regex to get timestamp, user, date, etc

* show recaptcha when unsuccessful logins are > of 15 in period of time of 5 minutes or less

* remove all data just the line relation to user and ip, etc, and reset the timestamp every 12 hours

what do you think about this is idea, is bad ?

All is working good, I have a dude relation what happend when multiple user conect to page login and do brute force attent, that mean the function open have to write in parallel ?

Replies are listed 'Best First'.
Re: Custom log file to alternative to db
by jimpudar (Pilgrim) on May 21, 2018 at 18:40 UTC

    I would probably use Fail2ban, but since you mentioned this is for fun here are a couple of ideas.

    Multiple processes all writing to the same file can step on each other if you use the normal print function due to buffering issues. I have used syswrite in the past to get around this and it works well. However in my experience if the log messages are short, Log4perl works fine with multiple processes all writing to the same file. I only ran into problems when printing multiline messages several KB in length at the same time.

    Another idea would be using a DBI driver that works with files instead of a full database such as DBD::CSV so you don't need to install a database but could easily drop one in later by switching to a different driver. However if you are on an OS without flock simultaneous writes may be an issue. I don't have any experience with this to share unfortunately. Looks like if you are using Linux you should be okay.

    If you get something working, I'm sure a lot of people would have feedback for you if you post it.

    Best,

    Jim

[reply]
[d/l]
[select]
Re: Custom log file to alternative to db
by Anonymous Monk on May 21, 2018 at 18:39 UTC
    in the end I not want to install a db aplication
    Have you considered DBD::SQLite? It does not require installing any C library headers (but it does require compilation of XS code and C code that it comes with) or separate applications; the whole database engine is just one library and every database is just one file. If probably scales better than parsing plain text log files (but make sure to always profile your specific implementations) and it solves the locking problem (i.e.: What if another worker process decides to append to the log file while you're parsing it? What if more than one worker process decides to write log file at the same time?) for you (though it just means that while one process/thread is writing to the database, others have to wait).
[reply]
    A reply falls below the community's threshold of quality. You may see it by logging in.

Back to Seekers of Perl Wisdom