Discuss April 2013

discuss@lists.centos.org

168 participants
148 discussions

Vsftpd configuration problem
by Max Pyziur 02 Apr '13

02 Apr '13

Greetings, Beginning today, I started to receive the following when ftp'ing to my CentOS 6 machine: ncftp /home/pyz2 > dir connect failed: No route to host. connect failed: No route to host. connect failed: No route to host. Falling back to PORT instead of PASV mode. I can make a connection, but I can't get a directory listing or transfer data/files. I'm flummoxed. What I had been doing is adding more directives to my /etc/hosts.deny file, today to include certain categories of ip addresses for the vsftpd service. I unwound that after I saw the problem starting to occur, and have restarted vsftpd several times. That hasn't changed the above issue. And yes, I've googled. My firewall setting has port 21 open. I can remotely telnet to hostname 21 and I get a response indicating that the port is open. Any advice would be appreciated. Much thanks. Max Pyziur pyz(a)brama.com

2 1

Re: [CentOS] Vsftpd configuration problem
by Max Pyziur 02 Apr '13

02 Apr '13

On Mon, 1 Apr 2013, lists-centos wrote: > > > ------------ Original Message ------------ >> Date: Monday, April 01, 2013 07:12:53 PM -0400 >> From: Max Pyziur <pyz(a)brama.com> >> To: centos(a)centos.org >> Cc: >> Subject: [CentOS] Vsftpd configuration problem >> >> >> Greetings, >> >> Beginning today, I started to receive the following when ftp'ing >> to my CentOS 6 machine: >> ncftp /home/pyz2 > dir >> connect failed: No route to host. >> connect failed: No route to host. >> connect failed: No route to host. >> Falling back to PORT instead of PASV mode. >> >> I can make a connection, but I can't get a directory listing or >> transfer data/files. >> >> I'm flummoxed. >> >> What I had been doing is adding more directives to my >> /etc/hosts.deny file, today to include certain categories of ip >> addresses for the vsftpd service. >> >> I unwound that after I saw the problem starting to occur, and have >> restarted vsftpd several times. >> >> That hasn't changed the above issue. >> >> And yes, I've googled. >> >> My firewall setting has port 21 open. >> >> I can remotely telnet to hostname 21 >> >> and I get a response indicating that the port is open. >> >> Any advice would be appreciated. >> >> Much thanks. >> >> Max Pyziur >> pyz(a)brama.com > > ftp uses port 21 for the "connection" and port 20 for the "data", > which includes directory listings as well as the file transfer > proper - see /etc/services. so if you have port 20 blocked that > would explain your problem. Does port 20 have to be open in the firewall? If so, this would be the first machine where I have explicitly set this. > - Richard > > > Max

1 0

Re: [CentOS] Vsftpd configuration problem
by Max Pyziur 02 Apr '13

02 Apr '13

On Tue, 2 Apr 2013, Reindl Harald wrote: > > > Am 02.04.2013 01:12, schrieb Max Pyziur: >> Beginning today, I started to receive the following when ftp'ing to my >> CentOS 6 machine: >> ncftp /home/pyz2 > dir >> connect failed: No route to host. >> connect failed: No route to host. >> connect failed: No route to host. >> Falling back to PORT instead of PASV mode. >> >> I can make a connection, but I can't get a directory listing or transfer >> data/files >> >> My firewall setting has port 21 open >> >> I can remotely telnet to hostname 21 > > and you understood that ftp needs also a data-channel > and not only the control-connection? I assume that you are referring to the following vsftpd configuration file setting: # Make sure PORT transfer connections originate from port 20 (ftp-data). connect_from_port_20=YES Btw, When ftping to another user on the same machine, there is no problem in making a connection or in transferring data; it's connections that our outside the box. > http://slacksite.com/other/ftp.html > > MP

1 0

[Possibly OT] - General question: state of internet traffic
by Max Pyziur 02 Apr '13

02 Apr '13

Greetings, I've read reports that there has been degradation in Internet traffic over the last month. Until today, I haven't experienced any. However, getting bank record data from chase.com here in NYC seems impossible. I also noticed erratic ftp behavior today; connections can be made but data can't be transferred. This isn't consistent, though. (I have a machine in LA while being in NYC; ftp traffic is difficult to establish westbound; no problem eastbound). I haven't done any sort of consistent test, so I am not sounding alarms. I'm just trying to get a sense of where this is happening. And is there a reliable source of information. Much thanks Max Pyziur pyz(a)brama.com

3 2

Don't understand how to re-partition this setup or why it was made like this
by Yves S. Garret 01 Apr '13

01 Apr '13

Hello, I did df -h on my CentOS 6.4 machine. $ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vg_ysg-lv_root 47G 8.8G 36G 20% / tmpfs 948M 372K 947M 1% /dev/shm /dev/sda1 485M 62M 398M 14% /boot /dev/mapper/vg_ysg-lv_home 4.6G 2.7G 1.7G 63% /home What I don't understand is why is /home so tiny and how can I re-partition this without having to nuke and rebuild my machine?

5 5

Re: [CentOS] DNS forwarding vs recursion
by Les Mikesell 01 Apr '13

01 Apr '13

On Mon, Apr 1, 2013 at 2:54 PM, Michael H. Warfield <mhw(a)wittsend.com> wrote: >> > AFA how BIND should be shipped... Last time I looked (just a couple of > days ago) BIND ships in a fairly secure manner (local caching resolver > listening on localhost only) and the default IP tables blocks DNS > queries and response that are not on-session. The OP mentioned that his > name server was an "authoritative" name server (it was servicing a zone > for which it was configured). That's NOT a shipped configuration. You > have to configure it for a zone. Sooo... We are NOT talking about OOB > (Out Of the Box) configurations here at all. Someone had to > configuration it this way, post installation. So everyone has to add your own zones. I don't see how that leads to the conclusion that it is shipped with appropriate defaults to force/encourage separation of authoritative/recursive instances. >> > I don't think that's the answer either. >> > Establishing best practices and discouraging people from misconfiguring >> > applications would seem to be a better option and best current practices >> > now were not always considered best practices 20 years ago. It's a >> > challenge. It's a BIG challenge in my business. >> >> OK, but of course it is a challenge if you advocate using tools that >> most people don't have or understand - or don't work universally. > > Don't have: Disagree - most have. Where? I'd say it is much more common for firewalls to be separate entities that don't know much about routing. > Don't understand: I'll grant you that. They don't understand the tools, > they don't understand the problem, and they don't understand best > current practices. You got me on that one. There in lies the problem > and the challenge. Exactly. If you can't clearly define the problem or a required topology you can't expect people to re-arrange things. >> > Asymmetric >> > routes (aka triangular routing) should be severely discourage and is >> > generally considered a configuration error unless it's heavily >> > justified. > >> I don't think BGP shares this opinion. > > I'm not sure I follow you on that statement. BGP is a protocol and I've > done some coding on that (I'm the author of the MD5 signature code in > bgpd of the Quagga suite). The crowd on NANOG (North American Network > Operators Group) generally frowns upon asymmetric routing as something > that is occasionally necessary and unavoidable but not admitted to > loudly in public, much akin to an aunt that like to sit in the corner of > a room at a party and frequently farts loudly. Are you saying that something in BGP cares about anything except the best forward path seen at the moment? Or that as this changes dynamically it even tries to keep the reverse path symmetrical? > Asymmetric routing also breaks > stateful firewalls badly if they are in the way... Sure. Do you want reliability or control? Pick one. >> And I'd speculate that the >> simplicity of IP routing only needing to care about the forward route >> direction one hop at a time is the main reason that it became the >> network of choice. Well, that and a taxpayer funded directory service >> from the start. > > This was very true back then but proved to be as problematical as > spoofing attacks abusing the DNS resolvers. Both are rooted in the > early ages of the Internet. Fascinating that you bring up that point. Packets are packets - the concepts of widely distributed, widely available transports aren't going to change, we just do it faster now. > Counter point is in the policy routing present in modern systems and > that IPsec in particular is a policy oriented VPN where triangular / > asymmetric routing frequently break. Hence the continuing popularity of ssl-based VPNs that work better under real-world conditions. OpenVPN, Juniper's, etc. > I would concur with that. I think that's part and parcel of > establishing your nominal security perimeters anyways. Maybe - as organizations grow, merge, relocate, etc. it becomes hard to deal with perimeters or to assume that all the bad guys are outside. >> So you envision an internet where it is impossible to reach a >> recursive resolver outside of your own organization's control? > > Not "impossible" and not under "your own organizations control". > Certainly, ISPs provide recursers for their clients. Yeah, but they mostly do that so they can redirect failed lookups to their own search engines or link farms and show some ads. As though web browsers were the only clients for DNS. > But... What is > the purpose of an indeterminant anonymous client connecting to your > recursive server and making arbitrary queries? Use case: You provide a subscription service to institutions that like strict outbound firewalling. Your servers are located in a few contiguous ranges and you work with their firewall admins to permit access. Then you find out that the desktop clients in question don't have access to full internet DNS. > Yes, there are some of > us who are involved in Internet infrastructure and maintenance for which > some of that may be useful for diagnostic purposes but, to allow anyone > for any reason to anywhere? That's just inviting abuse. Sure, but there's not a reasonable way to distinguish a customer from anyone else at the time they need DNS. > Counter point is that some ISPs (AT&T in particular) have begun blocking > unrestrained DNS as much as they block unrestrained SMTP because of some > of the abuse that has taken place. Or because they make money when they redirect the errors... > Whatever your opinion is on THAT > debate (and I am decidedly NOT on their side, but I do agree with > organizations who do it) it's a fact and it is happening. They don't > even allow their clients to run their own name servers (unless you are a > "business client" and have an agreement to that effect) and force most > of their clients to use their name servers. And then they can charge more for the "business class" where they don't block stuff. -- Les Mikesell lesmikesell(a)gmail.com

1 0

DNS forwarding vs recursion
by John R Pierce 01 Apr '13

01 Apr '13

I have 2 CentOS servers that are both authoritative DNS for several domains and local resolvers. As configured, they are publicly visible resolvers, which I've known for awhile is not a good thing. whats the appropriate way of configuring the bind on CentOS 5.current to not allow recursion on queries from the public side, but still allow recursion locally? is it as simple as adding allow-recursion{} with the appropriate private subnets and localhost to named.conf ? -- john r pierce 37N 122W somewhere on the middle of the left coast

6 8

Re: [CentOS] DNS forwarding vs recursion
by Les Mikesell 01 Apr '13

01 Apr '13

On Mon, Apr 1, 2013 at 1:30 PM, Michael H. Warfield <mhw(a)wittsend.com> wrote: > > Actually, it's pretty easy with netfilter / iptables. Other firewalls > like pf filter on *BSD an proprietary work similar. If you know your > inside networks you merely add a rule to block incoming packets on your > external interface with source addresses that should be inside your > firewall. What does 'inside' mean to TCP/IP? Are you saying it can't work if you are all public? Or if you expect to use redundant public routing among all of your systems? > Do > we all drop BIND in favor of nscd for our authoritative name servers and > dnsmasq for our cachers? Well, first you have to come out and say that recursive resolvers are too fragile to survive in public. Or have too much potential for collateral damage and must be outlawed. Maybe define a way your network topology has to be arranged. Then move on to how BIND should be shipped. > I don't think that's the answer either. > Establishing best practices and discouraging people from misconfiguring > applications would seem to be a better option and best current practices > now were not always considered best practices 20 years ago. It's a > challenge. It's a BIG challenge in my business. OK, but of course it is a challenge if you advocate using tools that most people don't have or understand - or don't work universally. > Asymmetric > routes (aka triangular routing) should be severely discourage and is > generally considered a configuration error unless it's heavily > justified. I don't think BGP shares this opinion. And I'd speculate that the simplicity of IP routing only needing to care about the forward route direction one hop at a time is the main reason that it became the network of choice. Well, that and a taxpayer funded directory service from the start. > They're highly unreliable to begin with (you can forget > about getting through stateful firewalls). Where it can be justified, > then static rules allow it will cover things in ways that attackers can > not exploit. So what you need to establish first is the location of the firewalls in respect to recursive servers. > Perhaps. But I'm not quite so sure where the bad design is or if it's > merely a confluence of extremely powerful tools, like BIND, that can be > used in a multitude of ways. I might agree with you more if the "bad > design" you are referring to is the overall network design, > architecture, and layout. I've seen plenty of well designed tools > misused in badly designed networks. So you envision an internet where it is impossible to reach a recursive resolver outside of your own organization's control? -- Les Mikesell lesmikesell(a)gmail.com

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

Discuss April 2013