1. TechSpot is dedicated to computer enthusiasts and power users. Ask a question and give support. Join the community here.
    TechSpot is dedicated to computer enthusiasts and power users.
    Ask a question and give support.
    Join the community here, it only takes a minute.
    Dismiss Notice

How to find what changed?

By jobeard
Mar 10, 2015
Post New Reply
  1. The following is a consequence of the post

    where the reported symptom was stated as:
    "installed Linux, but each time the OS got corrupt"​

    That's a very vague statement, but raises the question,
    just what is corruption and how might one find it?​

    The webpage http://www.windowsecurity.com/software/Intrusion-Detection/
    offers several approaches as possible solutions; from packet sniffing to Windows Event monitoring.

    The following is a direct approach in an attempt to discover
    "What got changed, and asserting that If it was unknowingly changed, then that's corruption or an infection".​

    It must be said, the following is NOT an antivirus tool - - just a simplistic means to discover WHAT CHANGED?

    CHANGE per se has an assumed time reference . . . since when? So how can we find CHANGE?
    so here's the outline:

    1) IDS
    2) Alternative solution
    3) A gift for Windows Users

    1) IDS: Intrusion Detection System

    Monitors file size, timestamp and frequently a hash producting an alert when current values mismatch the original baseline. The baseline is created when the IDS is configured and the data gathered is stored into a DBX database.

    Concept is: altered code will be detectable if either of these change from a known value

    Alerts are produced when the IDS rescans the filesystems, and typically cron(1) is used to
    trigger the frequency of scanning.(a)

    When maintenance is applied to the software, obviously the IDS will trip over these changes and
    raise alerts. After you see this occur a few times, you will soon get bored with the
    voluminous output and reset the baseline and keep the maintenance as a new 'known state'.

    When the cron invoked scan trips without any maintenance being applied, YOU'VE BEEN INFECTED.

    File timestamps have multiple values:
    Ctime Time file stored on hd(b)
    Mtime Time file last written
    Atime Time file last accessed; very resourse intensive and frequently disabled

    On most Linux distributions, the ls(1) tool shows the value of Ctime

    (b)Most systems actually display Mtime and at the command prompt, have little or no access
    to the others

    The best access to the {C,M,A}times is programmatically

    However Linux is not Unix and Unix systems {HPUX, Solaris, SGI, BSD} can have C3 Security implementations and interestingly, SO CAN WINDOWS. C3 Security requires access to the Atime value of all monitored files.
    [You might find "The Orange Book" on security interesting, at least to the defined levels and what is required to be so certified]

    Windows display of {C,M,A}times are controlled with the options
    /T which Controls which time field displayed or used for sorting timefield
    C Creation
    A Last Access
    W Last Written

    eg, these show different results
    dir /l /od /tc
    dir /l /od /tw

    2)(a) Alternative Solution
    For your choice of directories to be monitored (hint: certainly not the root '/')
    place a well-known file name to use as a trigger; eg _fence_.log and this file becomes the baseline for future reference.
    eg: cd $top; touch _fence_.log

    Then periodically, using cron(1) to trigger the scan, invoke

    today=`date -I`;

    ls -l _fence_.log >$log # document the reference timestampt
    find $top -newer _fence_.log -ls >>$log 2>1 # (c)

    $top will be the first directory to descend into looking for files changed AFTER _fence_.log

    As illustrated above, only the referenced $top dir and its subdirs will be scanned.
    A more precise, sparse scan could be easily built by creating a $list_of_dirs and
    using it as a control for a foreach invocation of the find(c) shown above.
    Consult man find(1) for conditions to limit the descent.

    This also demonstrates than a unique _fence_.log could be placed in each directory.

    It would also be better to produce ALL SCAN RESULTS into a known and controlled directory,

    find $top -newer _fence_.log -ls >>$IDS_DATA/$log 2>1

    3)(w) Gift for Windows users
    http://unxutils.sourceforge.net/ contains a set of scripts to memic the FIND and TOUCH commands
    shown above :grin:

    The precise invocation options may be different than those of Linux/Unix, but you will
    be able to complete the Windows Implementation I am sure.
  2. jobeard

    jobeard TS Ambassador Topic Starter Posts: 10,432   +801

    @Jskid for your consideration

Similar Topics

Add New Comment

You need to be a member to leave a comment. Join thousands of tech enthusiasts and participate.
TechSpot Account You may also...