On 2 Oct 2016 at 14:45, Gordon Messmer wrote: Subject: Re: Problem with firewalld/iptables and ftp access list? To: Community support for Fedora users <users@xxxxxxxxxxxxxxxxxxxxxxx> From: Gordon Messmer <gordon.messmer@xxxxxxxxx> Date sent: Sun, 2 Oct 2016 14:45:23 -0700 Send reply to: Community support for Fedora users <users@xxxxxxxxxxxxxxxxxxxxxxx> > On 10/02/2016 04:48 AM, Michael D. Setzer II wrote: > > The modeprobe nf_conntrack_ftp doesn't output any messge or error? Not > > sure what it is suppose to output. > > It shouldn't output anything. In your iptables rules you find these: > > -A INPUT -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT > -A IN_public_allow -p tcp -m tcp --dport 21 -m conntrack --ctstate NEW > -j ACCEPT > > When an FTP client connects to your server, it connects to port 21 which > is allowed by the second rule quoted above. The purpose of the > nf_conntrack_ftp module is to examine FTP traffic to determine which new > connections should be allowed by the former rule. When a client makes a > PASV mode connection, it will make additional connections to high > numbered ports for data transfers (including retrieving the output of > commands like "LIST"). That connection should be RELATED, and so > allowed by the former rule. It seems that for some reason, your system > isn't allowing such connections. > > I'll note several things. > > First, I'm unable to reproduce the problem on a mostly up-to-date Fedora > 24 system (still running kernel 4.7.4-200.fc24.x86_64 until I reboot). > Don't know when it exactly started, since I was off-Island for the summer and had remotely upgraded the systems from Fedora 23 to 24. Think I noticed the ftp issue originally in late August or Early September. I generally update machines often, so are currently running the latest kernels with all updates. On main machine, I have a script that uses plink to connect to the other systems and run the updates to keep all machines updated. Some of its options use ftp to download updated files to other systems. > Second, your iptables rules are a mess. For some reason, there are > multiple rules allowing connections to TCP ports 21 and 22 in the > IN_public_allow chain. I don't know any reason that would be a problem > per se, but it probably indicates that something else is wrong with the > system. > After I noticed the ftp wasn't working, I tried manually adding the ports to see if it was an issue with the ftp option not doing something, but it made no difference, and just didn't undo it? I had also tried on another system to activate vsftpd and got the same results, so it wasn't something on the main machine? > Third, you definitely should not be running both the iptables and > firewalld services, simultaneously. I was thought that firewalld was actually a front-end to iptables?? When I checked status they are generally both running, but sometimes I seen one listed as dead, but don't recall which one it was or if it may have been both at times. > > Fourth, the reason that removing "-A INPUT -j REJECT --reject-with > icmp-host-prohibited " from your rules fixes the problem is that > removing that rule allows all traffic. firewalld rules, generally, > allow traffic indicated by policy first, and then REJECT everything > else. When you remove the rule that REJECTS everything else, you're > allowing the traffic that's allowed by policy and all other traffic hits > the policy which is ACCEPT. Removing that rule is the same as turning > off the firewall, except that you still spend the CPU time examining > traffic for not reason. > The systems are I7 machine with quad cores and hyperthreading and 8G of Ram running on a 1G ethernet in classroom. > The problem has been confirmed by Ed and by Alfonso, who opened the bug > report, but it isn't universal, since it doesn't affect the one system I > tested. More details are needed. If it's actually a problem with > nf_conntrack_ftp, your kernel version would be helpful, for one. It may > also be helpful to get a network capture. I used "ngrep" to capture the > following FTP sessions, one PASV and the other PORT. > > > > > #### > T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] > 220 (vsFTPd 3.0.3).. > ## > T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] > FEAT.. > ## > T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] > 211-Features:.. > # > T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] > EPRT.. EPSV.. MDTM.. PASV.. REST STREAM.. SIZE.. TVFS.. UTF8..211 End.. > ## > T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] > OPTS UTF8 ON.. > # > T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] > 200 Always in UTF8 mode... > # > T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] > USER ftpuser.. > # > T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] > 331 Please specify the password... > # > T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] > PASS ftpuser.. > # > T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] > 230 Login successful... > # > T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] > PWD.. > # > T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] > 257 "/" is the current directory.. > # > T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] > PASV.. > # > T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] > 227 Entering Passive Mode (10,1,10,94,114,151)... > #### > T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] > LIST.. > # > T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] > 150 Here comes the directory listing... > # > T 10.1.10.94:29335 -> 10.1.10.50:49489 [AP] > -rw-r--r-- 1 0 00 Oct 02 21:07 test.. > ##### > T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] > 226 Directory send OK... > # > T 10.1.10.50:39498 -> 10.1.10.94:21 [AP] > QUIT.. > ## > T 10.1.10.94:21 -> 10.1.10.50:39498 [AP] > 221 Goodbye... > ## > T 10.1.10.50:39498 -> 10.1.10.94:21 [R] > ...... > # > T 10.1.10.50:39498 -> 10.1.10.94:21 [R] > ...... > > > > #### > T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] > 220 (vsFTPd 3.0.3).. > ## > T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] > FEAT.. > ## > T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] > 211-Features:.. > # > T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] > EPRT.. EPSV.. MDTM.. PASV.. REST STREAM.. SIZE.. TVFS.. UTF8..211 End.. > ## > T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] > OPTS UTF8 ON.. > # > T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] > 200 Always in UTF8 mode... > # > T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] > USER ftpuser.. > # > T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] > 331 Please specify the password... > # > T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] > PASS ftpuser.. > # > T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] > 230 Login successful... > # > T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] > PWD.. > # > T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] > 257 "/" is the current directory.. > # > T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] > PORT 10,1,10,50,142,235.. > # > T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] > 200 PORT command successful. Consider using PASV... > # > T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] > LIST.. > #### > T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] > 150 Here comes the directory listing... > # > T 10.1.10.94:20 -> 10.1.10.50:36587 [AP] > -rw-r--r-- 1 0 00 Oct 02 21:07 test.. > ##### > T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] > 226 Directory send OK... > ## > T 10.1.10.50:39500 -> 10.1.10.94:21 [AP] > QUIT.. > # > T 10.1.10.94:21 -> 10.1.10.50:39500 [AP] > 221 Goodbye... > #### > T 10.1.10.50:39500 -> 10.1.10.94:21 [R] > ...... > # > T 10.1.10.50:39500 -> 10.1.10.94:21 [R] > ...... > # > T 10.1.10.50:39500 -> 10.1.10.94:21 [R] > ...... > I had used wireshark to monitor while doing the connection, but wasn't seeing any traffic between the ls command and the failure. What process were you using to capture the above information?? Again, Thanks for the time. I'm assuming, that this isn't a 100% problem, but might be some specific combinations of things that are causing the issue. I was originally using UnixWare long ago, at the college, and then started with Redhat 9, and have gone thru versions to the latest Fedora 24. > _______________________________________________ > users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx +----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:mikes@xxxxxxxxxxxxxxxx mailto:msetzerii@xxxxxxxxx Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +----------------------------------------------------------+ http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) BOINC@HOME CREDITS ABC 16613838.513356 | EINSTEIN 114625025.788695 ROSETTA 49527492.658188 | SETI 92927032.772384 _______________________________________________ users mailing list -- users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to users-leave@xxxxxxxxxxxxxxxxxxxxxxx
