From: Oli K. <du...@nc...> - 2015-02-04 15:03:43
|
Hi all, We are seeing strange log entries recently: proftpd[31071]: 192.168.22.104 - Fatal: unable to open incoming connection: Transport endpoint is not connected This happens when we scan the server with "nmap -sT SERVER" from a fast client, it does however not happen when being scanned from a slow client or a virtual machine. Other software (i.e. https://zeromq.jira.com/browse/LIBZMQ-585 or https://code.google.com/p/pyftpdlib/issues/detail?id=100) say that this is a kind of race condition "since the connection is closing before we can get the peername with getpeername()" and only nmap or similar software is able to close the TCP connection so fast. The customer thinks that the performance of the server is affected (i.e. normal clients fail to establish a session) when being scanned 1: As this is a fatal error, our logs are filled with it - we seem to be scanned very often recently. Is there a way to prevent this from being logged at all? 2: Does it affect client limits by IP? I assume this in a very early stage of the protocol handshake and thus no client address is even present to work on with mod_limit/mod_ban/.. Cheers, -ok |