• rkhunter finds something suspicious

    From Przemek Jagielski@21:1/5 to All on Thu May 7 19:30:02 2020
    Hello,

    Are you check your system manually? Are you see any process which isn't
    default for your system? Are you see any open port in netstat?

    W dniu 07.05.2020 o 19:14, shirish शिरीष pisze:
    Dear all,

    Today my system was slowing much more than ever. Hence decided to run rkhunter. It seems to have found some issues, could somebody take a
    look and see if these are false positives or what ?


    I don't know the hash sums it quotes are current or off-date from the
    one debian provides. I did see #651119 but it will be better if
    somebody better than me can see if everything is good or off.

    --
    Pozdrawiam,
    Przemysław Jagielski
    Tel.: 793-641-503

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From =?UTF-8?B?c2hpcmlzaCDgpLbgpL/gpLDgp@21:1/5 to shirishag75@gmail.com on Fri May 8 13:10:01 2020
    at bottom :-

    On 07/05/2020, shirish शिरीष <shirishag75@gmail.com> wrote:
    Dear all,

    Today my system was slowing much more than ever. Hence decided to run rkhunter. It seems to have found some issues, could somebody take a
    look and see if these are false positives or what ?


    I don't know the hash sums it quotes are current or off-date from the
    one debian provides. I did see #651119 but it will be better if
    somebody better than me can see if everything is good or off.

    --
    Regards,
    Shirish Agarwal शिरीष अग्रवाल
    My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com

    E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C


    First of all thank you for responding so quick. Although it would have
    been better if you had also CC'ed me as well, it would have lead to
    better discussion.

    Anyways, I don't really know much about netstat hence used ss which is
    a utility to investigate sockets. Fortunately the version of iproute2
    has version 5.6.0-1 which gives the option of doing something like -

    # ss -p

    The commend marries/shows all local opened ports with a particular
    service or something. For e.g. I never knew firefox opened up so many
    ports for the web-content,
    This I guess is because of firefox using the sandboxing as a security
    feature [1]

    What I need si something similar to meld [2] or something similar
    which will cancel out the common ones or the ones known and leave out
    the ones unknown/any interesting ones. If you or somebody knows
    something which does something similar please share.

    1. https://wiki.mozilla.org/Security/Sandbox
    2. https://tracker.debian.org/pkg/meld

    --
    Regards,
    Shirish Agarwal शिरीष अग्रवाल
    My quotes in this email licensed under CC 3.0 http://creativecommons.org/licenses/by-nc/3.0/ http://flossexperiences.wordpress.com

    E493 D466 6D67 59F5 1FD0 930F 870E 9A5B 5869 609C

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Fri May 8 14:40:02 2020
    I always use
    netstat -atupn
    That shows all open tcp and udp ports. Invoke this before you start
    Firefox. The list should be empty or only contain sockets on the
    loopback network interface (127.0.0.*, ::1). To disable unnecessary
    network daemons use:
    systemctl disable avahi-daemon/other-daemon
    systemctl stop avahi-daemon

    For init opening RPC sockets you may need:
    systemctl disable rpcbind.socket
    systemctl stop rpcbind.socket

    You may also uninstall unnecessary software:
    apt-get remove kdeconnect

    View all processes with
    ps ax
    That may also be of help:
    pstree -p

    To identify the executable of a process
    ls -l /proc/1234/exe

    And to identify the package an executable belongs to:
    dpkg -S /bin/bash

    If rkhunter should once not yield the desired results then use
    debcheckroot: https://www.elstel.org/debcheckroot/

    Also helpful:
    systemctl -t service -a

    If you have a rootkit that does f.i. infect system libraries like glibc
    you will not see anything in the netstat nor in the ps ax output because
    these utilities can be replaced by utilities that do not return things belonging to the rootkit. To be sure that your system is clean you will
    need to use debcheckroot as rkhunter only knows a certain set of well
    known rootkits. However in this case rkhunter may have found something
    though.


    Am 08.05.20 um 13:08 schrieb shirish शिरीष:

    Anyways, I don't really know much about netstat hence used ss which is
    a utility to investigate sockets. Fortunately the version of iproute2
    has version 5.6.0-1 which gives the option of doing something like -

    # ss -p


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Fri May 8 16:00:01 2020
    Take care when you try to analyze the rootkit: You should install new
    into another partition/ boot from live cd first and then look at the
    files without executing them (otherwise your new system may get
    infected). The rootkit may be altered, removed or your activity may be monitored and/or inhibited if you try to analyze fromout of an infected
    system.

    Am 08.05.20 um 15:48 schrieb Elmar Stellnberger:
    Am 07.05.20 um 19:14 schrieb shirish शिरीष:
    Dear all,

    Today my system was slowing much more than ever. Hence decided to run
    rkhunter. It seems to have found some issues, could somebody take a
    look and see if these are false positives or what ?


    I don't know the hash sums it quotes are current or off-date from the
    one debian provides. I did see #651119 but it will be better if
    somebody better than me can see if everything is good or off.


      Looks like a kernel rootkit as programs like init, modprobe and
    systemd are reported to be manipulated. That should make sense if
    additional kernel modules and/or daemons are loaded. Since rkhunter
    seems to only report altered files where the locally stored hash has not
    been attacked but not additional files in your system you may
    additionally want to run debcheckroot to find out about such files (https://www.elstel.org/debcheckroot/). Anyway, you should reinstall
    your system. You could try to look at the mtime (modification time) of
    the files that are reported to be manipulated and search for other files
    with approximately the same date. Use the find utility to do so:
    find / -printf "%Y %p # %TY-%Tm-%Td_%TH:%TM %AY-%Am-%Ad %CY-%Cm-%Cd\n"
    and:
      There are three timestamps: modification time (m), inode modification time (c) - file attributes/creation, and last access time (a). Take care
    of the last access time: even running find on the files may change that without using -noatime or sth. the like.


    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Elmar Stellnberger@21:1/5 to All on Fri May 8 15:50:01 2020
    Am 07.05.20 um 19:14 schrieb shirish शिरीष:
    Dear all,

    Today my system was slowing much more than ever. Hence decided to run rkhunter. It seems to have found some issues, could somebody take a
    look and see if these are false positives or what ?


    I don't know the hash sums it quotes are current or off-date from the
    one debian provides. I did see #651119 but it will be better if
    somebody better than me can see if everything is good or off.


    Looks like a kernel rootkit as programs like init, modprobe and
    systemd are reported to be manipulated. That should make sense if
    additional kernel modules and/or daemons are loaded. Since rkhunter
    seems to only report altered files where the locally stored hash has not
    been attacked but not additional files in your system you may
    additionally want to run debcheckroot to find out about such files (https://www.elstel.org/debcheckroot/). Anyway, you should reinstall
    your system. You could try to look at the mtime (modification time) of
    the files that are reported to be manipulated and search for other files
    with approximately the same date. Use the find utility to do so:
    find / -printf "%Y %p # %TY-%Tm-%Td_%TH:%TM %AY-%Am-%Ad %CY-%Cm-%Cd\n"
    and:
    There are three timestamps: modification time (m), inode modification
    time (c) - file attributes/creation, and last access time (a). Take care
    of the last access time: even running find on the files may change that
    without using -noatime or sth. the like.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)