Re: [cobalt-users] ftp security

[Goetz Lohmann <goetz.lohmann@xxxxxx>]

Dave's List Addy schrieb:

>On 9/5/03 6:32 PM, "Jim Dory" wrote:
>
>  
>
>>(looking at Axis cameras as they have their own
>>webservers, use linux, etc.) But,
>>    
>>
>
>Great product, one of our clients is using it to monitor their office and
>property
>  
>
>>My first question is should I be paranoid about leaving the ftp server
>>running in its pretty much unaltered state, and
>>second: if yes, what security steps can be taken to lock things down.
>>
>>I will spend some time in the archives since I remember some discussion
>>of this.. but it was usually something like chroot jail or something
>>that seemed over my head at the time - and probably still is. Just
>>wondering how much time I should spend on looking for a solution for
>>security - if it is even a concern - regarding ftp. Just casting for a
>>quick answer.
>>    
>>
>
>You could do a hosts.allow on the IP
>
>in.proftpd: 123.123.123.123
>
>In the hosts.deny
>
>in.proftpd: ALL
>
>That's what I would do, I am sure others have some better ways.
>  
>
Ok ... with proftpd you have two common security problems to deal with.
1.) username authentication will use clear text paswords like in telnet :-(
2.) most hacks try to do a buffer overflow in proftpd

to the first you could prevent this by running proftp version 1.28 or above which
could use SSL/TLS security authentication like SSH. You might easalie update it
with RPM or compile it by your own. The pretty way of this is, that it still works
with the cobalt admin interface, cause the needed changes to the proftpd.conf
are untouched :-)

to the second ... you could compile it with a stackguard compiler which includes
checks for bufferoverflows in the code.
By the way ... the hosts.deny method lacks if you use a dial in line to manage
the server. Another point is, that a script kiddy which will blast your proftpd
will use a script which acts blind with a faked IP. You could write a script
which clames to come from 123.123.123.123 and instead comes from 66.66.66.66
cause you know what the answer from the server is you do not need to check the
answer. When the script finished inserting the backdoor all your pretty
host.deny was helpless cause after the reboot it is owned without his lines.
This all to do will took less than some seconds :-(

so I guess ... get proftpd-1.2.8 source tarball ... compile it with a stackguard
enabled gcc and change the existing proftpd-1.2.4 (???) to the new one.