Created attachment 551026 [details] proftpd.service with spaces deleted Description of problem: The spaces in proftpd.service are causing certain directives to be silently ignored by systemd. If you have security measures being enabled by -DMY_SECURITY_MEASURE in /etc/sysconfig/proftpd then you are exposed. Version-Release number of selected component (if applicable): 1.3.4-1 How reproducible: Turn on -DDYNAMIC_BAN_LISTS in /etc/sysconfig/proftpd and configure the MaxLoginAttempts to 2 in the mod_ban section. Try 3 times to log in from the same host with bad credentials. You will not be banned. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Philip, does your patched service file make any difference here? systemd seems to be doing the right thing for me: * "systemctl show proftpd.service" shows systemd correctly identifying the EnvironmentFile parameter * If I enable ftpdctl support in proftpd.conf and do "ftpdctl lsmod" on the running server, it shows mod_ban.c if -DDYNAMIC_BAN_LISTS and not otherwise * I have a CentOS 5.7 box with sysv init where I noticed yesterday that mod_ban seems not to be having any effect Perhaps the problem lies elsewhere?
(In reply to comment #1) > * I have a CentOS 5.7 box with sysv init where I noticed yesterday that > mod_ban seems not to be having any effect In this case it was an SELinux issue. I needed the following additional policy: # Proftpd needs shared memory for mod_ban allow ftpd_t self:shm create_shm_perms; allow ftpd_t self:tcp_socket lock;
(In reply to comment #0) > How reproducible: > > Turn on -DDYNAMIC_BAN_LISTS in /etc/sysconfig/proftpd and configure the > MaxLoginAttempts to 2 in the mod_ban section. > > Try 3 times to log in from the same host with bad credentials. You will not be > banned. When you say "Try 3 times to log in", do you mean "3 username/password combinations in a single connection", "1 username/password combination in each of three connections", or something else? Just to clarify mod_ban operation: if you have set up a mod_ban configuration to trigger with MaxLoginAttempts happening twice, this means that the "MaxLoginAttempts" event (which by default means 3 username/password combinations in a single connection, causing disconnection - http://www.proftpd.org/localsite/Userguide/linked/config_ref_MaxLoginAttempts.html) has to happen twice within the given time to cause a ban, which would be a total of 2 disconnections caused by a total of 6 username/password combinations. So I wouldn't expect 3 login attempts to trigger a ban unless you meant three sets of disconnections for 3 login attempts each, and if mod_ban was working it should have prevented any login attempts after the second disconnection anyway.
(In reply to comment #2) > (In reply to comment #1) > > * I have a CentOS 5.7 box with sysv init where I noticed yesterday that > > mod_ban seems not to be having any effect > > In this case it was an SELinux issue. I needed the following additional policy: > > # Proftpd needs shared memory for mod_ban > allow ftpd_t self:shm create_shm_perms; > allow ftpd_t self:tcp_socket lock; I have raised Bug #772205 regarding this.
(In reply to comment #3) > (In reply to comment #0) > > How reproducible: > > > > Turn on -DDYNAMIC_BAN_LISTS in /etc/sysconfig/proftpd and configure the > > MaxLoginAttempts to 2 in the mod_ban section. > > > > Try 3 times to log in from the same host with bad credentials. You will not be > > banned. > > When you say "Try 3 times to log in", do you mean "3 username/password > combinations in a single connection", "1 username/password combination in each > of three connections", or something else? One connection, with 3 username/password connections... the 3rd attempt doesn't go through because the IP address is blacklisted after the 2nd failure.
(In reply to comment #4) > (In reply to comment #2) > > (In reply to comment #1) > > > * I have a CentOS 5.7 box with sysv init where I noticed yesterday that > > > mod_ban seems not to be having any effect > > > > In this case it was an SELinux issue. I needed the following additional policy: > > > > # Proftpd needs shared memory for mod_ban > > allow ftpd_t self:shm create_shm_perms; > > allow ftpd_t self:tcp_socket lock; > > I have raised Bug #772205 regarding this. I had a different selinux related issue, not affecting mod_ban but incoming/ instead: ---- time->Thu Jan 5 16:42:09 2012 type=SYSCALL msg=audit(1325806929.984:1650): arch=c000003e syscall=2 success=no exit=-13 a0=a78530 a1=241 a2=1b6 a3=3a377361a0 items=0 ppid=9214 pid=9310 auid=4294967295 uid=0 gid=50 euid=14 suid=14 fsuid=14 egid=50 sgid=50 fsgid=50 tty=(none) ses=4294967295 comm="proftpd" exe="/usr/sbin/proftpd" subj=system_u:system_r:ftpd_t:s0-s0:c0.c1023 key=(null) type=AVC msg=audit(1325806929.984:1650): avc: denied { write } for pid=9310 comm="proftpd" name="incoming" dev=sda2 ino=393219 scontext=system_u:system_r:ftpd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:public_content_rw_t:s0 tclass=dir so I had to change the context of ~ftp/incoming to public_content_rw_t and then set: allow ftpd_t public_content_rw_t:dir write; but that's a different issue.
Here's the snippet from sealert: ***** Plugin allow_anon_write (53.1 confidence) suggests ******************* If you want to allow /usr/sbin/proftpd (deleted) to be able to write to shared public content Then you need to change the label on /var/ftp/incoming to public_content_rw_t, and potentially turn on the allow_httpd_sys_script_anon_write boolean. Do # semanage fcontext -a -t public_content_rw_t /var/ftp/incoming # restorecon -R -v /var/ftp/incoming # setsebool -P allow_ftpd_anon_write 1
(In reply to comment #5) > (In reply to comment #3) > > (In reply to comment #0) > > > How reproducible: > > > > > > Turn on -DDYNAMIC_BAN_LISTS in /etc/sysconfig/proftpd and configure the > > > MaxLoginAttempts to 2 in the mod_ban section. > > > > > > Try 3 times to log in from the same host with bad credentials. You will not be > > > banned. > > > > When you say "Try 3 times to log in", do you mean "3 username/password > > combinations in a single connection", "1 username/password combination in each > > of three connections", or something else? > > One connection, with 3 username/password connections... the 3rd attempt doesn't > go through because the IP address is blacklisted after the 2nd failure. I'm still not understanding here. There's a disconnection after (default 3, don't think you've changed it) MaxLoginAttempts username/password tries. So after your 2nd failure above I'd expect a disconnection but not a blacklisting. mod_ban counts the disconnections. So if you've set it up to ban on 2 MaxLoginAttempts events, the blacklisting should happen after the second disconnection, not the second username/password attempt. Does this happen for you with the daemon started with the original service file? I expect it to.
With MaxLoginAttempts set to 2, I see: # ftp ftp Connected to ftp (192.168.1.3). 220 FTP Server ready. Name (ftp:root): guest 331 Password required for guest Password: 530 Login incorrect. Login failed. Remote system type is UNIX. Using binary mode to transfer files. ftp> user guest 331 Password required for guest Password: 530 Login incorrect. Login failed. ftp> user guest 421 Service not available, remote server has closed connection Login failed. ftp> quit Does that answer your question?
(In reply to comment #9) > With MaxLoginAttempts set to 2, I see: > > # ftp ftp > Connected to ftp (192.168.1.3). > 220 FTP Server ready. > Name (ftp:root): guest > 331 Password required for guest > Password: > 530 Login incorrect. > Login failed. > Remote system type is UNIX. > Using binary mode to transfer files. > ftp> user guest > 331 Password required for guest > Password: > 530 Login incorrect. > Login failed. > ftp> user guest > 421 Service not available, remote server has closed connection > Login failed. > ftp> quit > > Does that answer your question? Well that's the expected disconnection behaviour for MaxLoginAttempts, but nothing to do with mod_ban. If you've enabled mod_ban with the Fedora package using the default mod_ban configuration, the IP you connected from should get blacklisted after you've done the above sequence twice (i.e. you've been disconnected twice). I believe that will work with the existing proftpd.service too.
(In reply to comment #10) > Well that's the expected disconnection behaviour for MaxLoginAttempts, but > nothing to do with mod_ban. If you've enabled mod_ban with the Fedora package > using the default mod_ban configuration, the IP you connected from should get > blacklisted after you've done the above sequence twice (i.e. you've been > disconnected twice). > > I believe that will work with the existing proftpd.service too. Not sure we're on the same page. Looking at the .conf: # Dynamic ban lists (http://www.proftpd.org/docs/contrib/mod_ban.html) # Enable this with PROFTPD_OPTIONS=-DDYNAMIC_BAN_LISTS in /etc/sysconfig/proftpd <IfDefine DYNAMIC_BAN_LISTS> ... # If the same client reaches the MaxLoginAttempts limit 2 times # within 10 minutes, automatically add a ban for that client that # will expire after one hour. BanOnEvent MaxLoginAttempts 2/00:10:00 01:00:00 ... </IfDefine> the banning happens because that (core) event serves as the trigger.
(In reply to comment #11) > (In reply to comment #10) > > Well that's the expected disconnection behaviour for MaxLoginAttempts, but > > nothing to do with mod_ban. If you've enabled mod_ban with the Fedora package > > using the default mod_ban configuration, the IP you connected from should get > > blacklisted after you've done the above sequence twice (i.e. you've been > > disconnected twice). > > > > I believe that will work with the existing proftpd.service too. > > Not sure we're on the same page. Looking at the .conf: > > # Dynamic ban lists (http://www.proftpd.org/docs/contrib/mod_ban.html) > # Enable this with PROFTPD_OPTIONS=-DDYNAMIC_BAN_LISTS in > /etc/sysconfig/proftpd > <IfDefine DYNAMIC_BAN_LISTS> > ... > # If the same client reaches the MaxLoginAttempts limit 2 times > # within 10 minutes, automatically add a ban for that client that > # will expire after one hour. > BanOnEvent MaxLoginAttempts 2/00:10:00 01:00:00 > > ... > </IfDefine> > > the banning happens because that (core) event serves as the trigger. The event is the client reaching the MaxLoginAttempts limit (i.e. being disconnected). If this happens twice within ten minutes, the ban is then activated. I believe this works as intended with the existing service file, complete with spaces. Is it not working like that for you?
(In reply to comment #12) > The event is the client reaching the MaxLoginAttempts limit (i.e. being > disconnected). If this happens twice within ten minutes, the ban is then > activated. I believe this works as intended with the existing service file, > complete with spaces. Is it not working like that for you? What I know is this: I had set MaxLoginAttempts to 2, and I was loading mod_ban.c, but neither was being effective: Dec 23 14:41:04 localhost proftpd[1934]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:06 localhost proftpd[1936]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:07 localhost proftpd[1938]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:07 localhost proftpd[1939]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:08 localhost proftpd[1943]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:09 localhost proftpd[1946]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:10 localhost proftpd[1947]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:11 localhost proftpd[1948]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:12 localhost proftpd[1949]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:12 localhost proftpd[1951]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:13 localhost proftpd[1952]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:14 localhost proftpd[1953]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:15 localhost proftpd[1954]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-consulting: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:42 localhost proftpd[1955]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:43 localhost proftpd[1956]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:44 localhost proftpd[1957]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:45 localhost proftpd[1960]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:45 localhost proftpd[1962]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:46 localhost proftpd[1963]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:47 localhost proftpd[1964]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:48 localhost proftpd[2029]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:49 localhost proftpd[2031]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:50 localhost proftpd[2033]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:51 localhost proftpd[2034]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:51 localhost proftpd[2035]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21 Dec 23 14:41:52 localhost proftpd[2036]: 192.168.1.3 (200.98.197.7[200.98.197.7]) - USER redfish-solutions: no such user found from 200.98.197.7 [200.98.197.7] to 192.168.1.3:21
Was there anything in /var/log/proftpd/ban.log? Did changing only the service file make any difference? I'm having a hard time believing that the spaces in the service make any difference; I've tried it locally with the standard service file and it works perfectly here.
(In reply to comment #14) > Was there anything in /var/log/proftpd/ban.log? > > Did changing only the service file make any difference? > > I'm having a hard time believing that the spaces in the service make any > difference; I've tried it locally with the standard service file and it works > perfectly here. There was a ban.log file and it did have messages about: Jan 05 17:09:41 mod_ban/0.6[9686]: obtained shmid 655360 for BanTable '/var/run/proftpd/ban.tab' but that was all.
In line with the upstream ticket, I'm going to close this one. It seems that whatever the issue was, it was related to an upgrade from F-15 to F-16 and as such, nobody looking for an existing bug for that is likely to look at this one. I think a separate bug should be opened in that event.