FTP logs?

[Paul McGauran]

Folks,

Completely new this firmware, I have FTP setup under vsftpd and DDNS. I want to know, are there any logs available to tell me who/was is connected?

Thanks
Paul
 

[Joao Cardoso]

On Wednesday, February 3, 2016 at 9:27:36 PM UTC, Paul McGauran wrote:

Folks,

Completely new this firmware, I have FTP setup under vsftpd and DDNS. I want to know, are there any logs available to tell me who/was is connected?

Yes.

By default most logs use syslog. You can use System->Utilities->Logs, System Log, then filter by ftp, or use 'logread | grep ftp' from the command line.

However, syslog is keept in memory, and for memory saving its only 32KB long, so old log entries might disappear. If you want a persistent log, you have to edit and change /etc/vsftpd.conf.

Notice that  If using the alternatives "file" based logs, /var/log/xferlog  and/or /var/log/vsftpd.log, the logs grown without bounds, and as /var/log is keep also in memory the system might run out of memory. That's the reasoning behind the Service->System->Cleanup service, that keeps each log file under /var/log under 32KB.

Damn, not even a simple question has a simple answer!

Thanks
Paul
 

[Paul McGauran]

Hi Joao, thanks for this info. just what i was looking for.

One more question though if you don't mind. If i wanted to make the log persistent, what changes do i need to make in the vsftpd.conf

Many thanks
Paul

[João Cardoso]

On Thursday, 4 February 2016 17:05:55 UTC, Paul McGauran wrote:

Hi Joao, thanks for this info. just what i was looking for.

One more question though if you don't mind. If i wanted to make the log persistent, what changes do i need to make in the vsftpd.conf

Relevant excerpts from googling 'man vsftpd.conf'. On linux (but not Alt-F), 'man' is your friend, not google:

       syslog_enable

              If  enabled,  then  any log output which would have gone to /var/log/vsftpd.log goes to

              the system log instead. Logging is done under the FTPD facility.

              Default: YES in the default Alt-F configuration

      dual_log_enable

              If enabled, two log files are generated in parallel, going by default to /var/log/xfer-

              log and /var/log/vsftpd.log.  The former is a wu-ftpd style transfer log, parseable  by

              standard tools. The latter is vsftpd's own style log.

              Default: NO

       vsftpd_log_file

              This option is the name of the file to which we write the vsftpd style log  file.  This

              log  is only written if the option xferlog_enable is set, and xferlog_std_format is NOT

              set. Alternatively, it is written if you have set the option dual_log_enable.  One fur-

              ther  complication  -  if you have set syslog_enable, then this file is not written and

              output is sent to the system log instead.

              Default: /var/log/vsftpd.log

       xferlog_file

              This option is the name of the file to which we write the wu-ftpd style  transfer  log.

              The  transfer log is only written if the option xferlog_enable is set, along with xfer-

              log_std_format.   Alternatively,  it  is  written  if   you   have   set   the   option

              dual_log_enable.

              Default: /var/log/xferlog

There are other log-related configuration settings (there are 126 total options, 8  with 'log' on their names)

So you might want to add

vsftpd_log_file=/mnt/xxx/vsftpd.log # where xxx is your filesystem name such as md0, sda2,...

[Paul McGauran]

Hi João,

Many thanks again for this info, will have a play around with it shortly and see what works best for me.
Going off topic here completely, but how are you on security?

Going through the sys log again and found some interesting failed login events. Is someone trying to gain access to the FTP? Im guessing the first one listed below was someone trying to get access but not sure about the rest.

Many thanks again for all your help
Paul

Jan 30 14:04:20 NAS ftp.warn vsftpd[1467]: [ftpuser] FAIL LOGIN: Client "202.153.39.52" About 50 attempts from this IP, only one attempt from the rest

Feb  1 01:37:45 NAS ftp.warn vsftpd[2115]: [user] FAIL LOGIN: Client "14.140.250.66"

Feb  1 10:00:01 NAS cron.info crond[616]: crond: USER root pid 3518 cmd /usr/bin/news.sh
Feb  1 10:04:50 NAS ftp.warn vsftpd[3664]: [guest] FAIL LOGIN: Client "178.89.243.75"

Feb  2 06:06:25 NAS daemon.info sysctrl: temp=39.5	pwm=63 fan=3000
Feb  2 06:10:18 NAS ftp.warn vsftpd[1322]: [server] FAIL LOGIN: Client "83.149.35.4"
Feb  2 08:29:01 NAS daemon.info sysctrl: temp=38.5	pwm=63 fan=3000

[João Cardoso]

On Thursday, 4 February 2016 19:35:11 UTC, Paul McGauran wrote:

Hi João,

Many thanks again for this info, will have a play around with it shortly and see what works best for me.
Going off topic here completely, but how are you on security?

My knowledge? average

The Alt-F webUI? I was not concerned with security when developing it.

running servers? As good as they are by themselves. 

It is *not* advisable to expose the Alt-F webUI to the internet. As a matter of fact there is one reported successful attack and infection attempt, search the forum. The infection was not successful because of the particular nature of Alt-F, a embedded, flashed firmware system without a disk root filesystem.

If you need to expose a service (ftp/ssh) to the internet, run the server in standalone (server) mode, not under inetd control.

Going through the sys log again and found some interesting failed login events. Is someone trying to gain access to the FTP? Im guessing the first one listed below was someone trying to get access but not sure about the rest.

It looks so. The 50 repeated attempts might be the result of an breach attempt. inetd will happily launch a new server whenever a new connection is established, so making DOS attacks is pretty easy.

Take care, only expose what you absolutely need to, use strong passwords and disable guest accounts.