Linux – Unexplained files found in home folder

fileslinuxSecurity

For background information, I'm running openSUSE 13.2 and KDE 5.

Today I found a number of unexplained files and folders in my home folder which state they've been edited 3 days ago. I do not remember doing anything that day that may have generated these files, nor did I download them as I don't even know what these files are or why they're there.

The names of the unexplained files can be seen below:

apr_crypto_openssl.so
apr_dbm_db.so
apr_dbm_gdbm.so
berkeley_db_svc-4.2
cpio
db_archive-4.2
db_archive-4.8
db_checkpoint-4.2
db_checkpoint-4.8
db_deadlock-4.2
db_deadlock-4.8
db_dump185-4.2
db_dump185-4.8
db_dump-4.2
db_dump-4.8
db_hotbackup-4.8
db_load-4.2
db_load-4.8
db_printlog-4.2
db_printlog-4.8
db_recover-4.2
db_recover-4.8
db_sql-4.8
db_stat-4.2
db_stat-4.8
db_upgrade-4.2
db_upgrade-4.8
db_verify-4.2
db_verify-4.8
errno.h
fcntl.h
float.h
floatingpoint.h
hoststat
ld-elf.so.1
libalias.so
libapr-1.so
libarchive.so
libaria2.so
libasn1.so
libauditd.so
libavl.so
libbegemot.so
libbiconv.so
libBlocksRuntime.so
libbluetooth.so
libbsdxml.so
libbsm.so
libbsnmp.so
libbsnmptools.so
libbz2.so
libcalendar.so
libcam.so
libcom_err.so
libcrypto.so
libcrypt.so
libc.so
libctf.so
libcurses.a
libcurses_p.a
libcurses.so
libcursesw.a
libcursesw_p.a
libcursesw.so
libdb-4.2.so
libdb-4.2.so.2
libdb-4.8.so
libdb-4.8.so.0
libdb-4.so
libdb_cxx-4.2.so
libdb_cxx-4.2.so.2
libdb_cxx-4.8.so
libdb_cxx-4.8.so.0
libdb_cxx-4.so
libdb_cxx.so
libdb.so
libdevinfo.so
libdevstat.so
libdialog.so
libdtrace.so
libdwarf.so
libedit.so
libelf.so
libexpat.so
libfetch.so
libform.so
libformw.so
libftpio.so
libgcc.a
libgcc_p.a
libgcc_s.so
libgcj.so
libgdbm.so
libgeom.so
libgettextlib.so
libgettextpo.so
libgmp.so.10
libgmpxx.so
libgmpxx.so.4
libgnuregex.so
libgomp.so
libgpib.so
libgssapi_krb5.so
libgssapi_ntlm.so
libgssapi.so
libgssapi_spnego.so
libhdb.so
libheimntlm.so
libhistory.so
libhx509.so
libiconv.so
libintl.so
libipsec.so
libitm.so
libjail.so
libkadm5clnt.so
libkadm5srv.so
libkafs5.so
libkiconv.so
libkrb5.so
libkvm.so
liblwres.so
liblzma.so
liblzo2.so.2
libmagic.so
libmd.so
libmemstat.so
libmenu.so
libmenuw.so
libmilter.so
libmpc.so
libmpfr.so
libmpfr.so.4
libmp.so
libm.so
libmudflapth.so
libncp.so
libncurses.so
libncursesw.so
libneon.so
libneon.so.27
libnetgraph.so
libngatm.so
libnvpair.so
libodialog.so
libopie.so
libpam.so
libpanel.so
libpanelw.so
libpcap.so
libpcre16.so
libpcre32.so
libpcreposix.so
libpcre.so
libpkg.so
libpmc.so
libproc.so
libprocstat.so
libpthread.a
libpthread_p.a
libpthread.so
libpython2.7.so
libradius.so
libreadline.so
libroken.so
librpcsec_gss.so
librpcsvc.so
librtld_db.so
librt.so
libsbuf.so
libsdp.so
libserf-1.so
libserf-1.so.1
libsmb.so
libssh.so
libssl.so
libssp.so
libstdbuf.so
libstdc++.so
libsupc++.so
libsvn_client-1.so
libsvn_client-1.so.0
libsvn_delta-1.so
libsvn_delta-1.so.0
libsvn_diff-1.so
libsvn_diff-1.so.0
libsvn_fs-1.so
libsvn_fs-1.so.0
libsvn_fs_fs-1.so
libsvn_fs_util-1.so
libsvn_ra-1.so
libsvn_ra_local-1.so
libsvn_ra_local-1.so.0
libsvn_ra_serf-1.so
libsvn_repos-1.so
libsvn_subr-1.so
libsvn_wc-1.so
libsvn_wc-1.so.0
libtacplus.so
libtermcap.a
libtermcap_p.a
libtermcap.so
libtermcapw.a
libtermcapw_p.a
libtermcapw.so
libtermlib.a
libtermlib_p.a
libtermlib.so
libtermlibw.a
libtermlibw_p.a
libtermlibw.so
libthread_db.so
libthr.so
libtinfo.a
libtinfo_p.a
libtinfo.so
libtinfow.a
libtinfow_p.a
libtinfow.so
libufs.so
libugidfw.so
libulog.so
libumem.so
libusbhid.so
libusb.so
libutempter.a
libutempter_p.a
libutempter.so
libutil.so
libuutil.so
libvgl.so
libwrap.so
libxml2.so.2
libypclnt.so
libzfs_core.so
libzfs.so
libzpool.so
libz.so
linker_set.h
log.0000000001
mailq
ncurses.h
newaliases
nologin
pam_chroot.so
pam_deny.so
pam_echo.so
pam_exec.so
pam_ftpusers.so
pam_group.so
pam_guest.so
pam_krb5.so
pam_ksu.so
pam_lastlog.so
pam_login_access.so
pam_nologin.so
pam_opieaccess.so
pam_opie.so
pam_passwdqc.so
pam_permit.so
pam_radius.so
pam_rhosts.so
pam_rootok.so
pam_securetty.so
pam_self.so
pam_ssh.so
pam_tacplus.so
pam_unix.so
perl
perl5
pgrep
pkg-config
pkill
poll.h
purgestat
sched.h
_semaphore.h
sendmail
snmp_atm.so
snmp_bridge.so
snmp_hast.so
snmp_hostres.so
snmp_mibII.so
snmp_netgraph.so
snmp_pf.so
snmp_target.so
snmp_usm.so
snmp_vacm.so
snmp_wlan.so
stdarg.h
stdint.h
strange_files.7z
svnpubsub
svnwcsub
Sync
syslog.h
tar
ucontext.h

The file log.0000000001 was generated when I ran the executable db_printlog however I tried opening the log file in kwrite and was met with the error:

The file /home/(redacted)/log.0000000001 was opened with UTF-8 encoding but contained invalid characters. It is set to read-only mode, as saving might destroy its content. Either reopen the file with the correct encoding chosen or enable the read-write mode again in the menu to be able to edit it.

The files svnwcsub and svnpubsub are shell scripts and their contents are as follows:

svnwcsub:

#!/bin/sh
#
# PROVIDE: svnwcsub
# REQUIRE: DAEMON
# KEYWORD: shutdown

. /etc/rc.subr

name="svnwcsub"
rcvar=`set_rcvar`

load_rc_config $name

#
# DO NOT CHANGE THESE DEFAULT VALUES HERE
# SET THEM IN THE /etc/rc.conf FILE
#
svnwcsub_enable=${svnwcsub_enable-"NO"}
svnwcsub_user=${svnwcsub_user-"svnwc"}
svnwcsub_group=${svnwcsub_group-"svnwc"}
svnwcsub_pidfile=${svnwcsub_pidfile-"/var/run/svnwcsub/svnwcsub.pub"}
svnwcsub_env="PYTHON_EGG_CACHE"
svnwcsub_cmd_int=${svnwcsub_cmd_int-"python"}
svnwcsub_config=${svnwcsub_config-"/etc/svnwcsub.conf"}
svnwcsub_logfile=${svnwcsub_logfile-"/var/log/svnwcsub/svnwcsub.log"}
pidfile="${svnwcsub_pidfile}"

export PYTHON_EGG_CACHE="/var/run/svnwcsub"

command="/usr/local/svnpubsub/svnwcsub.py"
command_interpreter="/usr/local/bin/${svnwcsub_cmd_int}"
command_args="--daemon \
              --logfile=${svnwcsub_logfile} \
              --pidfile=${pidfile} \
              --uid=${svnwcsub_user} --gid=${svnwcsub_group} \
              --umask=002 \
          ${svnwcsub_config}"

run_rc_command "$1"

svnpubsub:

#!/bin/sh
#
# PROVIDE: svnpubsub
# REQUIRE: DAEMON
# KEYWORD: shutdown

. /etc/rc.subr

name="svnpubsub"
rcvar=`set_rcvar`

load_rc_config $name

#
# DO NOT CHANGE THESE DEFAULT VALUES HERE
# SET THEM IN THE /etc/rc.conf FILE
#
svnpubsub_enable=${svnpubsub_enable-"NO"}
svnpubsub_user=${svnpubsub_user-"svn"}
svnpubsub_group=${svnpubsub_group-"svn"}
svnpubsub_reactor=${svnpubsub_reactor-"poll"}
svnpubsub_pidfile=${svnpubsub_pidfile-"/var/run/svnpubsub/svnpubsub.pid"}
svnpubsub_cmd_int=${svnpubsub_cmd_int-"python"}
pidfile="${svnpubsub_pidfile}"

export PYTHON_EGG_CACHE="/home/svn/.python-eggs"

command="/usr/local/bin/twistd"
command_interpreter="/usr/local/bin/${svnwcsub_cmd_int}"
command_args="-y /usr/local/svnpubsub/svnpubsub.tac \
            --logfile=/var/log/vc/svnpubsub.log \
            --pidfile=${pidfile} \
            --uid=${svnpubsub_user} --gid=${svnpubsub_user} \
            -r${svnpubsub_reactor}"


run_rc_command "$1"

If anybody can shed some light on what these files are, where they may have come from and what their purpose is, that'd be great. If you need any additional information just ask

Thanks

Best Answer

I do not remember doing anything that day that may have generated these files, nor did I download them as I don't even know what these files are or why they're there.

You can have a look at history, maybe there is a clue and you remember what could have caused this.

Since these files look a lot like they are part of your system, you can try to locate or find them. If they are part of your system, you can check with diff -a -q file1 file2 if they are the same. If you copied them unintentionally, they should be the same. Also, are those really files or just symbolic links? Symbolic links have arrows in ls -l:

$ ls -l /opt/bin
total 0
lrwxrwxrwx 1 root root 25 May  5  2013 ao -> /opt/audio-overload/ao2.0
                                           ^-- arrow

*.so files usually are shared objects used for programme parts which are used by several different programmes (like DLLs under Windows), some other files like "cpio", "hoststat" or "tar" look like they are executables, the .h are C header files. All of these files are likely to be somewhere else on your system. So, my guess is that you unintentionally copied them to . or ~.

If you suspect these files to be dangerous, you might upload them to sites like https://virusscan.jotti.org/ and see if they know something about them. Be aware that a negative result does not necessarily mean that they are harmless and a positive result does not necessarily mean that they are (part of) malware. But a positive result could at least give you hints in the right direction.

Related Solutions

security – Monitoring Activity on My Computer

You could use in-kernel mechanism inotify for monitoring accessed files.

First you should check if inotify is turned on in kernel:

pbm@tauri ~ $ zcat /proc/config.gz | grep CONFIG_INOTIFY
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y

Next thing to do is install inotify-tools. Instructions for various distributions you could find at project page - it should be in repositories of all major distributions.

After that inotify is ready to work:

inotifywait /dirs/to/watch -mrq

(m = do not exit after one event, r = recursive, q = quiet)

For example - output after ls /home/pbm

pbm@tauri ~ $ inotifywait /bin /home/pbm -mq 
/bin/ OPEN ls
/bin/ ACCESS ls
/bin/ ACCESS ls
/home/pbm/ OPEN,ISDIR 
/home/pbm/ CLOSE_NOWRITE,CLOSE,ISDIR 
/bin/ CLOSE_NOWRITE,CLOSE ls

Important thing is to properly set directories for watch:

don't watch / recursively - there is a lot of read/write to /dev and /proc
don't watch your home dir recursively - when you use apps there is a lot of read/write to application configuration dirs and browsers profile dirs

In /proc/sys/fs/inotify/max_user_watches there is configuration option that shows how many files can be watched simultaneously. Default value (for Gentoo) is about not so high, so if you set watcher to /home/ you could exceed limit. You could increase limit by using echo (root access needed).

echo 524288 > /proc/sys/fs/inotify/max_user_watches

But before that you should read about consequences of that change.

Options that could be interesting for you:

-d = daemon mode
-o file = output to file
--format = user-specified format, more info in man inotifywait
-e EVENT = what event should be monitored (for example access, modify, etc, more info in man)

Unix – Advantages of the Unix File System Structure

What seems to me the easiest-to-think-of advantage is that similar files live in the same directory tree. Configuration files live in /etc, log files and/or run-time trace files live in /var/log, executables live in /usr/bin, run-time information like PID files lives in /var/run. You want to know what's in the NTP configuration file? Change directory to /etc and do ls ntp*. You want to have some program watch executable files so that some traditional file system virus doesn't infect them? Everything in /usr/bin and /usr/local/bin needs watching.

The second advantage I can think of is that the Unix style of organization promotes a separation of data and executable. Executables live in a directory that's well away from where templates live (/usr/share, probably), and well away from where data lives. That separation might be a reason why Unix/Linux/*BSD have more resistance to file system viruses than Windows does, or the old Pre-OSX Mac had.

Best Answer

Related Solutions

security – Monitoring Activity on My Computer

Unix – Advantages of the Unix File System Structure

Related Question