Talk:Fail2ban
Need reference
As far as I understand, this is not possible anymore as the bug related to this has been fixed (http://www.securelist.com/en/advisories/56691[dead link 2020-04-02 ⓘ]): "Additionally, if the attacker knows your IP address, they can send packets with a spoofed source header and get you locked out of the server."
A reference is needed here. -- Siosm (Siosm) 13:05, 09 February 2014 (UTC)
- Spoofing IP is a known issue. There are many references, such as wikipedia:Spoofing_attack#Spoofing_and_TCP/IP, or Security#SSH. There are also defense lines, such as Sysctl#Reverse_path_filtering. Regid (talk) 08:33, 2 April 2020 (UTC)
- The
jail.confhas the optionignoreselfwhich is true by default. Isn't that enough ? Louson (talk) 13:46, 5 October 2022 (UTC)
- The
warning about log parse error
Hi, I just see the warning added: [1] I think it is very good that it was added in the first place. I have also followed the link, but I am not using the package so I cannot comment much on it. I think for the warning it would be useful to elaborate briefly in which circumstances (e.g. log facility, settings, applications, etc) that erroneous IP format in the logs did/could occur. The IP format (IPv4-port) the sshd logs show in the report don't match my journalctl log format, so much I see. IF it is the case that this can occur by choosing available options (e.g. in sshd.conf or for journalctl) with Arch default packages, it might also help other users by posting a brief description of the issue to the (new) mailing list: https://lists.archlinux.org/archives/list/arch-security@lists.archlinux.org/ or the bbs (I'm leaving a note for User:666threesixes666 with a link to this suggestion). --Indigo (talk) 18:07, 13 March 2014 (UTC)
- hi i dont actually use arch, so i am not sure if the problem occurs. regardless the regex to extract ip v4 addresses is improper, and breaks at pairing with port or process number, and possibly with ip.some.domain.com or xxx-xxx-xxx-xxx.some.domain.com. i signed up here to be friendly and cross reference a wiki i posted at gentoo that was not well covered here so that editors could take examples from it to make their lives easier. mm yeah monit wiki. i don't do mailing lists, sorry. take it easy arch friends. =D666threesixes666 (talk) 18:32, 13 March 2014 (UTC)
- Well, thanks for reporting it here in this case. But the point that it is unclear whether there exists a problem at all with fail2ban used with Arch repo packages did not really come through .. I have re-phrased it a little more generally. I moved the cross-link to sshguard at the top out of the warning too. It appears useful anyway to provide a contextual link between the two packages (our sshguard page has the to here). Have a look, if you are ok with it. --Indigo (talk) 22:58, 13 March 2014 (UTC)
- i do not mind 1 way or another, its a wiki and i expect merciless editing. i dont use arch, and its very well possible the issue doesnt affect arch as they said in the bug report upstream comes from a ssh patch. regardless if the regex breaks for me i know it will break again sooner or later especially since they refuse to correct their errors. sshguard should be preferred over fail2ban regardless as it is C and not interpreted. 666threesixes666 (talk) 09:39, 16 March 2014 (UTC)
- Anecdotal sidenote first: you might have read that 14th March was world PI-day. Fun fact: the first 144 PI digits add up to 666. ;)
- To the point: Ok, cool, so let's keep the warning like this. My personal preference is to do it simply with iptables and not an extra tool which runs with root. But that's not so versatile, if you need things like permanent blacklists or something else from the tools unarguably neat features. Anyhow, I guess you are right with your point about the regex.
- It would be helpful, if you could quickly note here in talk once your bug report has been resolved. Thanks.
- --Indigo (talk) 10:22, 16 March 2014 (UTC)
- i do not mind 1 way or another, its a wiki and i expect merciless editing. i dont use arch, and its very well possible the issue doesnt affect arch as they said in the bug report upstream comes from a ssh patch. regardless if the regex breaks for me i know it will break again sooner or later especially since they refuse to correct their errors. sshguard should be preferred over fail2ban regardless as it is C and not interpreted. 666threesixes666 (talk) 09:39, 16 March 2014 (UTC)
- Well, thanks for reporting it here in this case. But the point that it is unclear whether there exists a problem at all with fail2ban used with Arch repo packages did not really come through .. I have re-phrased it a little more generally. I moved the cross-link to sshguard at the top out of the warning too. It appears useful anyway to provide a contextual link between the two packages (our sshguard page has the to here). Have a look, if you are ok with it. --Indigo (talk) 22:58, 13 March 2014 (UTC)
Hardening errors
First of all, it seems like we have to have `/var/log/fail2ban` in
ReadWriteDirectories=/var/run/fail2ban /var/lib/fail2ban /var/spool/postfix/maildrop /tmp /var/log/fail2ban
On the other hand, it seems these rules causes problems--Xan (talk) 17:14, 3 November 2015 (UTC)
maildrop
It seems like the 'Service hardening' will also cause the maildrop to not work, specifically the NoNewPrivileges=yes will cause a permission denied issue ("warning: mail_queue_enter: create file maildrop/103313.473: Permission denied'")[2]. JDWUP (talk) 22:02, 5 March 2020 (UTC)
/run/xtables.lock error
When looking at fail2ban.log, once can see there is a problem with /run/xtables.lock that is not writable beacause /run is read-only. Then, fail2ban is simply not working ! So for a hardening solution, not only it does not harden but fail2ban fails to run !
To fix it, I changed ProtectSystem to full instead of strict. May be there is a better solution
—This unsigned comment is by Solstice (talk) 16:40, 21 December 2022. Please sign your posts with ~~~~!
- I've been seeing the same errors and got around by running
sudo touch /run/xtables.lockAssumetrue (talk) 21:02, 13 March 2023 (UTC)