vsftpd

Hi

vsftpd on a ubuntu 7.10 machine.
No anonymous loggin.
Is it possible to define time bands for transfers ?
i.e. transfers allowed from 9pm to 6 am only.


Thanks

Big Bill wrote:
> vsftpd on a ubuntu 7.10 machine.
> No anonymous loggin.
> Is it possible to define time bands for transfers ?
> i.e. transfers allowed from 9pm to 6 am only.

Not intrinsically in vsftpd.

You could use cron to start and stop the service, plus kill any children
at stop time.

Or you could use the iptables time modules to block connections.
Dropping ESTABLISHED ones at stop time would require some special care.

Hi Allen
I don't want to stop the service 'cause I use it when I'm away.
Iptables will block only known connections, suppose Joe gives his login
to his brother !?

There's a welcome banner_file that says that tfrs are only accepted from
9pm to 6am otherwise banished. But it's like income rules !!

I could limit the space on the server, or I could limit the size of
transfers but since it's something like a "family" server used for
exchanging images and videos of trips and the like, I just don't want to
end the ftp service.

If I could just block connections except mine during the day it should
be just perfect.

Allen Kistler a écrit :
> Big Bill wrote:
>> vsftpd on a ubuntu 7.10 machine.
>> No anonymous loggin.
>> Is it possible to define time bands for transfers ?
>> i.e. transfers allowed from 9pm to 6 am only.
>
> Not intrinsically in vsftpd.
>
> You could use cron to start and stop the service, plus kill any children
> at stop time.
>
> Or you could use the iptables time modules to block connections.
> Dropping ESTABLISHED ones at stop time would require some special care.

Big Bill wrote:
> Allen Kistler a écrit :
>> Big Bill wrote:
>>> vsftpd on a ubuntu 7.10 machine.
>>> No anonymous loggin.
>>> Is it possible to define time bands for transfers ?
>>> i.e. transfers allowed from 9pm to 6 am only.
>>
>> Not intrinsically in vsftpd.
>>
>> You could use cron to start and stop the service, plus kill any
>> children at stop time.
>>
>> Or you could use the iptables time modules to block connections.
>> Dropping ESTABLISHED ones at stop time would require some special care.
>>
> I don't want to stop the service 'cause I use it when I'm away.

I did say cron could start the service as well as stop it.

> Iptables will block only known connections, suppose Joe gives his login
> to his brother !?

iptables/netfilter would block *all* access (layer 3). Why do you think
netfilter cares about login IDs (layer 7)?

> There's a welcome banner_file that says that tfrs are only accepted from
> 9pm to 6am otherwise banished. But it's like income rules !!

Yeah, income is nice, but I don't understand what it's got to do with
vsftpd.

> I could limit the space on the server, or I could limit the size of
> transfers but since it's something like a "family" server used for
> exchanging images and videos of trips and the like, I just don't want to
> end the ftp service.

Both of those things are good, but neither would implement time limits.

> If I could just block connections except mine during the day it should
> be just perfect.

So *you* want 24 hour access, but everybody else is 9pm to 6am? Why not
use scp yourself 24/7 and turn vsftpd on and off for everyone else?

Or you could set up two user_list/ftpusers files (which *is* a vsftpd
thing and a pam thing - see the other recent thread on vsftpd in this
group) and use cron to swap them at 9pm and 6am. One file allows only
you and one allows you and anyone else you want. It's kludgey and won't
kick off people who are already on at 6am, but it should work otherwise.

>> Iptables will block only known connections, suppose Joe gives his
>> login to his brother !?
>
> iptables/netfilter would block *all* access (layer 3). Why do you think
> netfilter cares about login IDs (layer 7)?

Not login IDs but IPs.
One only have to reset his modem to change the IP making the iptable
useless.
>
>> There's a welcome banner_file that says that tfrs are only accepted
>> from 9pm to 6am otherwise banished. But it's like income rules !!
>
> Yeah, income is nice, but I don't understand what it's got to do with
> vsftpd.

Rules are meant to discourage one from doing unwanted things by
punishments enforcing . But they don't stop peoples from overspeeding.
My rule is : no xfers during working time ; my punishment is banishment.
But some overpass that.

What I observe is that authorized X puts something in his ftp space and
gives his login to unknown Z who grabs it. It's becomming a temporary
xchange facility. I don't care as long as it doesn't restrict my use of
the server, what it begins to do.

>
> So *you* want 24 hour access, but everybody else is 9pm to 6am? Why not
> use scp yourself 24/7 and turn vsftpd on and off for everyone else?
>
> Or you could set up two user_list/ftpusers files (which *is* a vsftpd
> thing and a pam thing - see the other recent thread on vsftpd in this
> group) and use cron to swap them at 9pm and 6am. One file allows only
> you and one allows you and anyone else you want. It's kludgey and won't

> kick off people who are already on at 6am, but it should work otherwise.
I know and that's the problem. One could start a big transfer at 5:58.

I think I'll have to stop ftp for all but me and write a http transfer
page instead combined to .htaccess file. That way it'll be easy to deny
any transfers that will be too long even if they give their login to
others. Along with a rewrite rule to change the group and owner of the
uploaded file, no one but the authorized one (like me) could then do
what he wants with the file then discouraging non authorized loggers to
come and sip on the server.


What do you think of that ?

Big Bill wrote:
>>> Iptables will block only known connections, suppose Joe gives his
>>> login to his brother !?
>>
>> iptables/netfilter would block *all* access (layer 3). Why do you
>> think netfilter cares about login IDs (layer 7)?
>
> Not login IDs but IPs.
> One only have to reset his modem to change the IP making the iptable
> useless.

Typically "blocking" without qualification in iptables means all IPs.

>>> There's a welcome banner_file that says that tfrs are only accepted
>>> from 9pm to 6am otherwise banished. But it's like income rules !!
>>
>> Yeah, income is nice, but I don't understand what it's got to do with
>> vsftpd.
>
> Rules are meant to discourage one from doing unwanted things by
> punishments enforcing . But they don't stop peoples from overspeeding.
> My rule is : no xfers during working time ; my punishment is banishment.
> But some overpass that.

Ah. Language barrier. "Income" is money that you get, as opposed to
money that you spend (outgo). Rules as a verb is a synonym for reigns.

> What I observe is that authorized X puts something in his ftp space and
> gives his login to unknown Z who grabs it. It's becomming a temporary
> xchange facility. I don't care as long as it doesn't restrict my use of
> the server, what it begins to do.

Warez? You said this was a "family" server. If you've lost control of
who has usernames and passwords, that seems to go beyond just family.

>> So *you* want 24 hour access, but everybody else is 9pm to 6am? Why
>> not use scp yourself 24/7 and turn vsftpd on and off for everyone else?
>>
>> Or you could set up two user_list/ftpusers files (which *is* a vsftpd
>> thing and a pam thing - see the other recent thread on vsftpd in this
>> group) and use cron to swap them at 9pm and 6am. One file allows only
>> you and one allows you and anyone else you want. It's kludgey and won't
>> kick off people who are already on at 6am, but it should work otherwise.
> I know and that's the problem. One could start a big transfer at 5:58.
>
> I think I'll have to stop ftp for all but me and write a http transfer
> page instead combined to .htaccess file. That way it'll be easy to deny
> any transfers that will be too long even if they give their login to
> others. Along with a rewrite rule to change the group and owner of the
> uploaded file, no one but the authorized one (like me) could then do
> what he wants with the file then discouraging non authorized loggers to
> come and sip on the server.

I'd still say use scp for yourself. There's an AlowedUsers directive in
the ssh config. Stop and start vsftpd for everyone else using cron.
When you stop vsftpd, make sure to kill all the children, too.

ssh/scp also has the benefit that your username and password aren't
transmitted in the clear across the Internet. Presumably only you can
become root. Even better is to disable password authentication in favor
of public keys, which stops brute force attacks on your password. Of
course, the security of ssh/scp and vsftpd is a whole other topic.

Allen Kistler a écrit :

>> What I observe is that authorized X puts something in his ftp space
>> and gives his login to unknown Z who grabs it. It's becomming a
>> temporary xchange facility. I don't care as long as it doesn't
>> restrict my use of the server, what it begins to do.
>
> Warez? You said this was a "family" server. If you've lost control of
> who has usernames and passwords, that seems to go beyond just family.


It's rather films taken on the net. And yes it has gone beyond the family.


> I'd still say use scp for yourself. There's an AlowedUsers directive in
> the ssh config. Stop and start vsftpd for everyone else using cron.
> When you stop vsftpd, make sure to kill all the children, too.

And the server will be unaccessible to those who follow the rules !

> ssh/scp also has the benefit that your username and password aren't
> transmitted in the clear across the Internet. Presumably only you can
> become root. Even better is to disable password authentication in favor
> of public keys, which stops brute force attacks on your password. Of
> course, the security of ssh/scp and vsftpd is a whole other topic.

You're right concerning the protection.

I don't want to flush them all only because of a couple of selfish ones.
I'll keep your advice in mind and try to find a setup that will suit the
goods and the bads who come on the server.

Thanks

Hi Mark

Mark Hobley a écrit :

> Run the timed restricted service on the normal port, and have a second service
> on a different port number that recognizes only your login that runs 24/7.
>

It's a good idea. But while I was talking with Allen, I found that I
forgot to consider the good ones, the ones who only make small xfers
during the day. These I don't want to flush them.

So it raises the difficulty a bit higher and that's why I proposed a
http transfer page. That way, only a little php programming and I will
reject all transfers that would take too long to complete.

I can catch the IP along with the loggin to decide if I accept or reject
the connection thus identifying a loggin sharing. Then, evaluate the
transfer size to accept the transfer during the day.

Public key, as said Allen, are a good protection but also it's easy to
tick the pwds so they don't last longer then a month. That way it shoud
discourage a lot of non-authorized loggers. At least I think. But I'm
not a pro in server administration.