Prev: ethtool and offload support (gro/gso)
Next: What happens after a packet is captured?
From: Moe Trin on 29 Mar 2010 15:32
On Mon, 29 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in
article <hoq9un$13k1$1(a)news.ett.com.ua>, Big Bill wrote:

>Keith Keller a �crit :

>> Moe Trin <ibuprofin(a)painkiller.example.tld.invalid> wrote:

>>> Use a ``valid'' username when you're connecting.

>> If you use a valid username but bad password too many times,
>> DenyHosts will block you, unless you're in the allowed-hosts file.

Below

>The ID used with Filezilla is a registered user of the system and
>not the admin'.

That may be, but the server application you are trying to connect to
doesn't like it and is putting an error message in the logs.
DenyHosts sees this error, and is configured to block all systems
that cause the error. Fix the server application or the client
username/authentication to something the server likes.

>Before firestarter, I could access the server by it's name (pingouin),
>now it's only available by it's ip. No big deal. Filezilla could
>transfer without a problem.

Bad DNS or missing entry in the _client_ hostfile? Or are you
depending on some magic dynamic or multicast DNS?

>Since Denyhosts, no transfers. I can access the server with putty,
>winscp, scp, all using admin id but not filezilla who uses another id.

Fix the server. The application does not like the authentication
associated with that "other" ID (or doesn't like the ID) and is
complaining in the logs. Denyhosts sees the logs and is ``protecting''
you from that bad client --> BUT <-- see the 'restricted-usernames'
function in denyhosts which can cause additional problems.

>Logins have been modified in filezilla to reflect the rules of
>firestarter but still no success.

Firestarter isn't the problem - it's the server application that
doesn't like the username/authentication that the client application
is using.

>At the very first try, denyhosts blacklists the address.

Yup - _self_ denial of service attack. You've also got it set much
tighter (DENY_THRESHOLD_INVALID) than is wise.

>Is there more controlable utility that I could use instead ? Something
>light preferably as it's not a commercial server and I'm not a pro OP.

The FAQ that Keith listed (http://denyhosts.sourceforge.net/faq.html)
mentions "similar" Self Denial Of Service applications in question 1.19
but they're going to have the same results. The server application you
are connecting to doesn't like the username/authentication that the
client is using, and is bitching in the logs. Any of these Self Denial
Of Service applications is going to react by blocking access from that
bad client. Please read the logs (perhaps /var/log/secure or
/var/log/messages) and see what the application is complaining about,
and fix _that_ problem.

Old guy
From: Moe Trin on 29 Mar 2010 15:35
On Mon, 29 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in
article <hoqghh$169p$1(a)news.ett.com.ua>, Big Bill wrote:

>I've finally found what was wrong.
>
>A mispelled user in vsftpd conf files.

Yup - that will do it every time.

>Now filezilla works and denyhosts doesn't complain anymore.

denyhost wasn't complaining - vsftpd was. denyhost was merely
blocking what vsftpd was complaining about. Even without denyhost,
you wouldn't be able to connect.

Old guy
From: Big Bill on 29 Mar 2010 18:26
Moe Trin a �crit :
> On Mon, 29 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in
> article <hoqghh$169p$1(a)news.ett.com.ua>, Big Bill wrote:
>
>> I've finally found what was wrong.
>>
>> A mispelled user in vsftpd conf files.
>
> Yup - that will do it every time.
>
>> Now filezilla works and denyhosts doesn't complain anymore.
>
> denyhost wasn't complaining - vsftpd was. denyhost was merely
> blocking what vsftpd was complaining about. Even without denyhost,
> you wouldn't be able to connect.
>
> Old guy
Right.

Thanks
First  |  Prev  | 
Pages: 1 2
Prev: ethtool and offload support (gro/gso)
Next: What happens after a packet is captured?