cannot access ftp server -- getpeername (in.ftpd): Transport endpoint is not connected

Hello,

maybe one of you can help me with this problem. I am posting it here
because it seems to be caused by a security mechanism.

The ftp server on a web/mail/inet-gateway machine I am taking care of can
no longer be accessed, ever since one of the secretaries decided to
switch it off and on again because she could not access her files on a
Windows server. I have made some changes on the ipchains rules since
then, but ftp is open on the internal interface.

Anyway, access is possible neither from the LAN, nor from the machine
itself when I am logged on via ssh.

I get this message on the shell:
***
# ftp localhost
Trying ::1...
ftp: connect to address ::1: Connection refused
Trying 127.0.0.1...
Connected to localhost.
421 Service not available, remote server has closed connection.
***

and this turns up both in /var/log/warn and /var/log/messages:
***
May 17 13:01:01 server in.ftpd[12726]: warning: can't get client address:
Invalid argument
May 17 13:01:01 server ftpd[12726]: getpeername (in.ftpd): Transport
endpoint is not connected
May 17 13:01:01 server inetd[813]: /usr/sbin/tcpd: exit status 0x1
May 17 13:01:01 server in.ftpd[12727]: warning: can't get client address:
Invalid argument
May 17 13:01:01 server ftpd[12727]: getpeername (in.ftpd): Transport
endpoint is not connected
May 17 13:01:01 server inetd[813]: /usr/sbin/tcpd: exit status 0x1
May 17 13:01:01 server in.ftpd[12728]: warning: can't get client address:
Invalid argument
May 17 13:01:01 server ftpd[12728]: getpeername (in.ftpd): Transport
endpoint is not connected
May 17 13:01:01 server inetd[813]: /usr/sbin/tcpd: exit status 0x1
May 17 13:01:01 server inetd[813]: ftp/tcp server failing (looping),
service terminated
***

.... repeated over and over again, with rising pids.
Trying other ftp servers (by changing inetd.conf) resulted in the same,
with in.ftpd changed to proftpd etc.
BTW, the name of the machine is included in /etc/hosts.

Have any of you had that problem? Please help, running out of time...
Looking for old threads that included these error messages only turned up
tons of hacking-related questions.

Thank you!

Matthias

On 2004-05-17, Matthias Hupp <mhupp.nospampls@gmx.de> wrote:

> The ftp server on a web/mail/inet-gateway machine I am taking care of can
> no longer be accessed, ever since one of the secretaries decided to
> switch it off and on again because she could not access her files on a
> Windows server. I have made some changes on the ipchains rules since
> then, but ftp is open on the internal interface.
>
> Anyway, access is possible neither from the LAN, nor from the machine
> itself when I am logged on via ssh.
>
> I get this message on the shell:

> ftp: connect to address ::1: Connection refused

> May 17 13:01:01 server ftpd[12726]: getpeername (in.ftpd): Transport
> endpoint is not connected
> May 17 13:01:01 server inetd[813]: /usr/sbin/tcpd: exit status 0x1
> May 17 13:01:01 server in.ftpd[12727]: warning: can't get client address:
> Invalid argument

> May 17 13:01:01 server inetd[813]: /usr/sbin/tcpd: exit status 0x1
> May 17 13:01:01 server inetd[813]: ftp/tcp server failing (looping),
> service terminated
> ***
>
> ... repeated over and over again, with rising pids.
> Trying other ftp servers (by changing inetd.conf) resulted in the same,
> with in.ftpd changed to proftpd etc.
> BTW, the name of the machine is included in /etc/hosts.


Hmmm...you say you changed FTP servers, but what about removing tcpd out of
the mix? It seems like something's going on with it, possibly something to
do with what's in /etc/hosts.deny/allow? The tcpd server can be compiled
with different security flags on by default, on up thru "paranoid", which
may also play a part (this is in the tcpd man page). You said you ssh'ed in-
what about if you sit down at the server and connect localhost - localhost,
no ssh involved? I'd turn up the debugging features on the ftp server,
verify that it was operating correctly, then work backwards from there. I'm
curious about tcpd being removed. "Transport endpoint is not connected" is a
very popular error message which usually means that the target machine can't
be reached- either due to some phyiscal reason, or, possibly here, a bad
allow/deny rule. You may want to try a few runs of tcpdmatch:

tcpdmatch -i /etc/inetd.conf in.ftpd <address to check out>

Listing your iptables rules might shed some light too.

Sorry I can't say without a doubt what it is, but maybe something I touched
on here might get you looking in the right place.




--
[jayjwa]======[SkyNet.cz]SystemsMutex===VxL@Atr2====

> Hmmm...you say you changed FTP servers, but what about removing tcpd
> out of the mix? It seems like something's going on with it, possibly
> something to do with what's in /etc/hosts.deny/allow?

Indeed, proftpd in standalone works. I am using this as a workaround now;
ftp is only open to the LAN anyway. Gonna have a look at inetd and
related files (tcpd) when I have more time. And, if possible, use
pureftpd or so.


> The tcpd server
> can be compiled with different security flags on by default, on up
> thru "paranoid", which may also play a part (this is in the tcpd man
> page). You said you ssh'ed in- what about if you sit down at the
> server and connect localhost - localhost, no ssh involved?

I wouldn't know. That server is a bit too far away right now...

> I'd turn up
> the debugging features on the ftp server, verify that it was operating
> correctly, then work backwards from there. I'm curious about tcpd
> being removed. "Transport endpoint is not connected" is a very popular
> error message which usually means that the target machine can't be
> reached- either due to some phyiscal reason, or, possibly here, a bad
> allow/deny rule. You may want to try a few runs of tcpdmatch:
>
> tcpdmatch -i /etc/inetd.conf in.ftpd <address to check out>
>
> Listing your iptables rules might shed some light too.

It's a 2.2 system, so ipchains. Which ones, the ones for ftp?

>
> Sorry I can't say without a doubt what it is, but maybe something I
> touched on here might get you looking in the right place.

Thanks, I will follow your hints eventually.

Cheers,

Matthias

On 2004-05-24, Matthias Hupp <mhupp.nospampls@gmx.de> wrote:
>> Hmmm...you say you changed FTP servers, but what about removing tcpd
>> out of the mix? It seems like something's going on with it, possibly
>> something to do with what's in /etc/hosts.deny/allow?
>
> Indeed, proftpd in standalone works. I am using this as a workaround now;
> ftp is only open to the LAN anyway. Gonna have a look at inetd and
> related files (tcpd) when I have more time. And, if possible, use
> pureftpd or so.

I don't think it's even an ftp daemon issue...it seems like you got it going
w/o tcpd, so I'd tend to think it's a hosts.deny/hosts.allow rule or the way
tcpd was compiled that is to blame. Anyway, if you're checking out ftp
servers, the newest proftpd (1.2.10rc1, as of this writing) is quite nice.
I've been running it here, trying out some of the contributed modules.
ftpdctl is quite nice.


>> Listing your iptables rules might shed some light too.
>
> It's a 2.2 system, so ipchains. Which ones, the ones for ftp?

General system rules, eg, incoming & outgoing rules for all connections


--
[jayjwa]======[SkyNet.cz]SystemsMutex===VxL@Atr2====
Your computer is called a *machine*, not a *box*. A
*box* is a term for computers reserved for the likes
of programmers, hackers, and developers.