Config Server Exploit Scanner

CXS Security Scanner which give you protection from exploit for cPanel servers

ConfigServer eXploit Scanner (cxs) is a tool from Wey To The Web Limited that performs active scanning of files as they are uploaded to the server. CXS will scan files, directories and user accounts for suspicious files, potential exploits and viruses.

Note: cxs is not a rootkit scanner, though it can detect rootkits uploaded to user accounts.

SYNOPSIS

cxs [OPTION]... RESOURCE

 OPTION:
   -?, --help               Display the documentation
   -V, --version            Display the version
       --terms              Display the License Agreement
   -Z, --quiet              Quiet output
   -U, --upgrade            Upgrade to the latest version
       --mail [email]       Send scan report to email address [email]
       --smtp               Send emails via localhost SMTP instead of sendmail
       --report [file]      Write scan report to [file]
       --logfile [file]     Append scan report files to [file]
   -N, --cleanlog           Log clean Web script or FTP files with --logfile 
       --[no]virusscan      Do [not] perform virus scanning (default:on)
       --[no]exploitscan    Do [not] perform exploit scanning (default:on)
       --[no]summary        Do [not] display scan summary (default:on)
   -S, --sizemax [bytes]    Maximum text file size to scan (default:500000)
   -F, --filemax [num]      Skip dir if > than [num] resources (default:10000)
   -H, --timemax [secs]     Scan timeout per file in seconds (default:30)
   -C, --clamdsock [sock]   Location of the clamd socket
   -D, --delete             Delete suspicious files
       --force              Force scanning within restricted directories
   -K, --skipover [user]    Start scanning after [user] with --allusers
       --jumpfrom [user]    Start scanning from [user] (incl) with --allusers
       --jumpto [user]      Stop scanning to [user] (incl) with --allusers
       --ulist [file]       Scan users listed in [file] with --allusers
       --uidmin [uid]       Min UID for GENERIC with --allusers (default:1000)
       --uidmax [uid]       Max UID for GENERIC with --allusers (default:65535)
   -E, --deep               Perform a deep scan
       --debug              Print a LOT of debugging information
       --decode [file]      Decode PHP base64/rot13 encoded file
       --depth [num]        Decode to [num] depth for --decode
       --block              Block FTP IP addresses using csf
       --MD5                Display matched file md5sum
   -B, --background         Run scan as a background process
   -T, --throttle [num]     Sleep if load is greater than [num]
   -Q, --quarantine [dir]   Move suspicious files to [dir]
   -I, --ignore [file]      A file with more resources for scanning to ignore
   -X, --xtra [file]        A file with more resources for scanning to use
       --script [script]    Run [script] if a match is detected
       --tscripts [list]    When using --options [T] only detect these types
       --www                Only scan in public_html subdir (--allusers/--user)
       --generate           Generate --ignore [file] using --report [file]
       --wttw [file]        Report script to ConfigServer
       --voptions [mfhexT] Virus scan specified file types only
       --qoptions [mMfSGchexTEv] Quarantine specified file types only
       --options [mMOLfSGcChexdnwWTEDZRP] Exploit scan specified checks only

       --Wstart             Start the cxs Watch daemon
       --Wstop              Stop the cxs Watch daemon
       --Wmaxchild [num]    The number of Watch child processes (default:3)
       --Wadd [file]        A file with more directories for cxs Watch to scan
       --Wsleep [secs]      Sleep delay (default:3 secs)
       --Wloglevel [num]    cxs Watch daemon log file verbosity [0..2]
       --Wrefresh [days]    Restart cxs Watch daemon every [days] (default:7)

 RESOURCE:
       [file/directory]     A file or directory to scan, or
       --allusers           Scan all user login directories (alphabetical), or
       --user [user]        Scan [user] login directory

OPTIONS

--help

Displays this help page

--clamdsock [sock]

This should be the full path to the ClamAV Daemon socket if running. cxs will look for the socket at /tmp/clamd, /var/clamd, /var/run/clamav/clamd.sock and /var/run/clamav/clamd.ctl unless specified with this option.

--quiet

Does not display the progress of the requested scan. The progress indicator uses symbols to indicate particular file matches or a dot (.) for every 50 files scanned:

 m = regex pattern match
 M = fingerprint match
 v = virus
 O = socket
 L = symlink
 f = suspicious file
 F = skipped directory with too many entries
 S = SUID file
 G = GUID file
 c = core dump file
 C = core dump file deleted
 h = suspected exploit file
 e = Linux binary or executable file
 x = Windows binary or executable file
 d = suspicious directory name
 n = hidden directory owned by nobody user
 w = world writable directory
 W = world writable directory - chmod to 755
 T = script file - identifies PHP, Perl, and other script files as suspicious
 E = email script
 D = Decoded PHP encoded (e.g. base64) file scan match
 R = Match the PHP decode regex
 P = Search D/B config files and attempt user login via FTP. Match on success
 Z = compressed file - scan within zip, tar, tar.gz and tar.bz2 files
 ! = Scan timeout per file B<--timemax>
 [Zzzzzzz] = sleeping for 60 seconds as load average is > --throttle [num]

--ignore [file]

[file] points to a file containing resources that the scanning engine should ignore. Each entry in [file] should be on its own line and prefixed with one of the following (no spaces after the : separator):

 user:    - ignore user
 file:    - ignore file
 dir:     - ignore directory
 sym:     - ignore symlink
 script:  - ignore web script (ModSecurity/Suhosin hook)

 puser:   - regex of users to ignore
 pfile:   - regex of files to ignore
 pdir:    - regex of directories to ignore
 psym:    - regex of symlinks to ignore
 pscript: - regex of web script to ignore (ModSecurity/Suhosin hook)

 hfile:   - ignore file relative to a users homedir (With: --all, --user)
 hdir:    - ignore directory relative to a users homedir (With: --all, --user)
 hsym:    - ignore symlink relative to a users homedir (With: --all, --user)

 match:   - ignore regex pattern match
 md5sum:  - ignore file md5sum (See --MD5)

See /etc/cxs/cxs.ignore.example for examples.

[file] needs to have world read access (644) to allow Web script file upload scanning.

--script [script]

During a scan, if a suspicious file or resource is detected, [script] will be executed with the following passed as paramters:

 filename
 option triggered
 message reported
 account name (if --all or --user is used, i.e. not passed for ftp scans)

[script] must be the full path to the script.

The [script] will run under the context cxs is running (e.g. under the root account for manual and ftp scans, the nobody user for ModSecurity scans).

The [script] will be run for every hit against a file.

The [script] must be chmod +x and have a valid shebang line.

For example, [script] could contain code to suspend an account if the options v and M are detected against a file. That script would have to check whether the account has already been suspended (by a previous excecution) and that the context the script is running under has the permissions to suspend the account: /etc/cxs/cpanelsuspend.pl

Another example provided is /etc/cxs/htaccessdisable.pl which disables access via the web server to a directory using a .htaccess file

--tscripts [list]

If --options [T] is used, you can restrict which script types are always detected using [list] as a comma separated list from a selection of the following script types:

  php,perl,python,ruby,c,other

If --tscripts [list] is not used, all types will be detected. To omit one or more types use --tscripts [list] and don't include those that should not be detected in the list.

--xtra [file]

[file] points to a file containing a list of regular expression matches and filenames that cxs will additionally scan for:

 regall:   - regular expression match for all script files
 regphp:   - regular expression match for only php script files
 regperl:  - regular expression match for only perl script files
 regfile:  - regular expression match for a file or directory name
 file:     - file or directory name match (not a regex)
 md5sum:   - md5sum of a file to match as a known exploit (See --MD5)

See /etc/cxs/cxs.xtra.example for examples.

[file] needs to have world read access (644) to allow Web script file upload scanning.

--logfile [file]

This will append scan results per item found to [file]

If [file] is intended to log web script file uploads it must have world writable permissions.

It would be best to create [file] in advance with:

 # touch [file]
 # chmod 666 [file]
 # chattr +a [file]

This will then only allow appending to [file]. You will have to remove the a attribute to empty/delete/rotate [file].

--report [file]

This will (re)create [file] and write the full scan report to it

If [file] is intended to log web script file uploads it must have world writable permissions.

--options [mMOLfSGcChexdnwWTEDZRP]

By default --exploitscan will scan for all of the following, except C, W, T,P and E which need to be specified explicitly using this option.

Please read the separate sections for options C, W, T, P and E as these advanced options can be dangerous (change file permissions, delete files or identify innocent files as suspicious) and you should read and understand the documentation before enabling any of them.

If --options [mMOLfSGcChexdnwWTEDZRP] is also used then only the selected scanning options will be performed:

 m = regex pattern match
 M = fingerprint match
 O = socket
 L = symlink
 f = suspicious file
 S = SUID file
 G = GUID file
 c = core dump file
 C = core dump file deleted
 h = suspected exploit file
 e = Linux binary or executable file
 x = Windows binary or executable file
 d = suspicious directory name
 n = hidden directory owned by nobody user
 w = world writable directory
 W = world writable directory - chmod to 755
 T = script file - identifies all PHP, Perl, and other script files as suspicious
 E = email script
 D = Decode PHP encoded (e.g. base64) scripts
 R = Match the PHP decode regex
 P = Search D/B config files and attempt user login via FTP. Match on success
 Z = compressed file - scan within zip, tar, tar.gz and tar.bz2 files

(See the Exploit Scanning Reference for a detailed description for each option)

This option will only work with --exploitscan enabled.

--voptions [mfhexT]

By default --virusscan will scan all files. If --voptions [mMfhexT] is also used then only the selected file types will be scanned, from a choice of:

 m = regex pattern match
 f = suspicious file
 h = suspected exploit file
 e = Linux binary or executable file
 x = Windows binary or executable file
 T = script file

(See the Exploit Scanning Reference for a detailed description for each option)

This option will only work with --virusscan enabled.

This option is disabled when scanning uploaded Web script or FTP files as all uploads are virus scanned if --virusscan is enabled.

--qoptions [mMfSGchexTEv]

By default --quarantine [dir] will move all file matches. If --qoptions [mMfSGchexTEv] is also used then only the selected file types will be moved, from a choice of:

 m = regex pattern match
 M = fingerprint match
 f = suspicious file
 S = SUID file
 G = GUID file
 c = core dump file
 h = suspected exploit file
 e = Linux binary or executable file
 x = Windows binary or executable file
 T = script file - quarantines all PHP, Perl, and other script files
 E = email script
 v = virus

This option will only work with --quarantine [dir] enabled.

Care should be taken using this option scanning uploaded Web script or FTP files as any file types omitted by --qoptions [mMfSGchexTEv] will be allowed.

--delete

This option will delete an uploaded Web script or FTP file that matches an suspected exploit or virus. Caution should be exercised when using this options as it could cause confusion, or damage to user data. In such circumstances it would be better to consider using --quarantine instead.

This option can also be used on manual or scheduled scans, however since the likelihood of a false-positive is relatively high, this is not recommended.

Do not use --delete with --quarantine, the former takes precedence.

--force

If --force is not used then cxs will refuse to scan within the following directories:

  /usr /var /bin /lib /lib64 /boot

--jumpfrom [user], --jumpto [user]

With these options a start and end [user] can be specified for a scan used with --all to only scan those users between the two specified. The scan includes the start and end [user].

Additionally, a special value can be used for the from and to [user] using a single letter then a plus sign to scan those users whose name begins with the letter specified (not case sensitive). Again, this is inclusive. For example,to scan all accounts beginning with k through to g use --jumpfrom k+ --jumpto g+

--generate

This is a special option that requires the options --report [file] and --ignore [file], where --report [file] is taken as input and cxs will append ignore rules to --ignore [file]

When a cxs report is first run it is likely to show some false-positives. If you do not want to see those same files in subsequent reports, you can ignore them by adding appropriate records to an ignore file and using the --ignore [file] option with that file.

To help create such an ignore file from a report containing a large number of false-positives, you can use this --generate option which takes the report file as input and cxs will append correctly specified ignore rules to the ignore file listed. Subsequent scans using that ignore file will then ignore those listed files.

--wttw [file]

This option is available for submitting exploits to ConfigServer if cxs fails to detect it. The file is sent as an attachment via email.

Please do NOT:

 1. Send exploits that are detected by cxs using the default options
 2. Send exploits that are detected by ClamAV
 3. Send excessive numbers of exploit examples
 4. Send HTML defacement injections (e.g. iframe injections)
 5. Send files unless you are sure they are exploits

Failure to adhere to the above will result in your submissions being blocked.

--quarantine [dir]

This option will move an uploaded Web script or FTP file that matches an exploit or virus to [dir]. Only FTP, cxs Watch and manual scan files can be restored from quarantined through the UI.

It is not possible to restore a file for a web script as the destination filename is not known.

This option can also be used on manual or scheduled scans, however since the likelihood of a false-positive is relatively high, it is recommended that a strict --qoptions [mMfSGchexTEv] is used.

FTP files are moved to:

  /[dir]/ftp/{username}/{file}.{timestamp} 

Web script files are moved to:

  /[dir]/{username}/{file}.{timestamp} 

Manual scan files are moved to:

  /[dir]/scan/{file owner}/{file}.{timestamp} 

A restore file is also created in the same directory as the quarantined file for use through the UI as {file}.{timestamp}.restore

[dir] should always be chmod 1777

--deep

This option will scan all text files for all regex and fingerprint matches which will obviously take longer. The default, without --deep, checks for php and perl file extensions and file types (using file magic) and scans each appropriately.

--decode [file]

This option will attempt to recursively decode PHP [file] which contains base64 or rot13 encoded data that is passed through the eval() statement and display the result.

This is not a foolproof option and it may not produce meaningful results.

An additional option --depth [num] is included so that the final result can be stopped at a specific depth level rather than recursing to the end.

Once decoding is complete cxs will run a deep scan against the result.

--block

This option will enable cxs to block FTP connections uploading suspicious files.

Careful consideration should be made before using this option in cxsftp.sh as there is a significant risk of false-positives with using this option for two reasons:

1. It's relatively easy for an innocent user to upload a file that could trigger one of the scan results

2. The FTP IP address isn't completely reliable (see FTP IP addresses)

If you want to block web script upload IP addresses, use the appropriate option in the csf configuration: LF_CXS (for ModSecurity), LF_SUHOSIN

--MD5

This option will display the md5sum of a file that obtains a hit when --options [m] triggers a match during a scan.

Under those circumstances, an md5sum: entry in a --ignore [file] will ignore the file. An md5sum: entry in a --xtra [file will match the file as a known exploit, i.e. as an --options [M] hit.

Remember, because this matching is only peformed during --options [m] these features will only apply to text files. These will additionally need to also be script files, unless --deep is used.

--background

This option will force cxs to run as a detached background process. For this reason you must specify either --report or --mail when using this option otherwise you won't see any results.

The option can be used with interactive, cron or FTP upload scans, but not with web upload scans.

Note: If you use this option in cxsftp.sh it may help ftp performance, but it will likely add significant load to the server with high ftp throughput as scans will no longer be queued by the pure-uploadscript process.

--throttle [num]

This option will force cxs to sleep for 60 seconds if the one minute load average is greater than [num]. cxs performs the load check every 60 seconds.

If the load average on the server is continuously high when cxs is running the process will take much longer to complete, so care should be taken when specifying this option.

--sizemax [bytes]

This option will prevent scanning for regex matches in text files > [bytes] in size. This does not apply to virus scanning.

--filemax [num]

This option will prevent scanning of a directory and all its subdirectories if there are more than [num] resources contained within this directory level.

--[no]summary

If you want to disable summary statistics then use --nosummary. Doing so will also force cxs to only report accounts with suspicious files when using the --all and --mail [email] options. However, --report [file] will still display a full report.

--upgrade

If cxs is scheduled, via cron, to check for a new version daily, an additional check for new Exploit Fingerprints released since the last cxs version is performed. These will be downloaded and used on subsequent scans.

--options [T]

If you do not want to allow any script uploading via web scripts include this option which will identify: PHP, Perl, C and other scripts that use a shebang (#!)

Note: This could cause problems for people using a CMS to manage their site

You could also use this option when scanning vulnerable directories such as /tmp or /dev/shm

Warning: Using this option will report ALL scripts as suspicious. Be sure that you understand this before using it.

If you want to only detect some script types, use the --tscripts [list] option.

--options [E]

This option will match scripts that send out email using sendmail, exim or via SMTP.

This option requires that --options [m] is also specified.

--options [W]

This option will chmod all world writable directories found to 755. Use this option with care as it could prevent web scripts from functioning on non-suPHP or non-SUEXEC enabled systems

--options [D]

This is an option that puts any PHP scripts containing a eval() function that decodes base64/rot13 information through the --decode [file] option during a scan. This will then highlight the decoded result if it hits any regex,fingerprint or virus scan matches.

This option will add a performance and time overhead to any scans, which could be significant. However, it does make cxs much more effective.

See also the --decode [file] description.

--options [R]

This option will trigger a match for the inbuilt regex used by --options [D] when decoding PHP encoded (base64 etc) scripts

--options [P]

This option will search standard web application configuration files for MySQL database passwords. It will then attempt to login via FTP on localhost with the username of the account being processed and the detected password (it will attempt up to two password hits per configuration file). If the login is successful, the option will trigger a match.

The intention of this option is to help prevent exploitation of the server by uploaded exploits that trawl through web application configuration files for passwords that match user accounts and then gain access to that account via FTP or the server Control Panel.

Any matches should prompt you to have the user change either their database or Control Panel/user account password so that they are different to avoid this common exploitation method.

This option will use additional resources during the scan process as it tries FTP logins for config file matches.

This option can only be used with the --allusers or --user [user] options.

--Wstart

Starts the cxs Watch daemon, see cxs Watch Daemon

--Wstop

Stops any running cxs Watch daemon, see cxs Watch Daemon

--Wadd [file]

To add additional directories to watch you can specifically list them within [file] and the will be included when the cxs Watch daemon starts. If the file is changed, the cxs Watch daemon must be restarted.

For example, it would be a good idea to scan files in /tmp and /dev/shm, so you can add those to a file (e.g. /etc/cxs/cxs.wadd) and then use the --Wadd [file] option to also scan them (--Wadd /etc/cxs/cxs.wadd).

--Wchildren [num]

Use this option to increase the number of child processes started by the cxs Watch daemon to scan files. On a server with mostly static pages and little activity, you could reduce the number. On a very active server, increasing the number will mean that files are processed more quickly.

--Wsleep [num]

Wsleep forces the cxs Watch daemon to go to sleep for the number of specified seconds after each process run of modified files. A value of 0 means that files will be processed as soon as they have been modified. This is good because any suspicious files will be processed immediately. However, on a very busy server with a lot of continuous file updates, this would mean that files may be processed multiple times per second. In this case, it may be a good idea to set this value higher (e.g. 5) to allow file updates to accumulate before they are processed.

Additionally the --throttle [num] option can be used for the daemon process to help alleviate additional load if desired. However, this in turn can cause a backlog of files to scan.

--Wloglevel [num]

The higher the value of [num] the more verbose the log file information will be for the cxs Watch daemon in /var/log/cxswatch.log. By default the value is set to 0. For more detailed information, set to 1. For maximum detail set to 2.

Be aware that a log level of 2 will provide a great deal of information and the log file will grow in size rapidly on evenr the quietest of systems. So this setting is best set to 2 only for short periods.

--Wrefresh [days]

To keep the cxs Watch daemon up to date, it will restart every 7 days by default. To change this interval, you can set --Wrefresh [days].

OTHER FILES & INFORMATION

/etc/cxs/install.txt

The installation document for this application.

/etc/cxs/reference.txt - Exploit Scanning Reference

The Exploit Scanning Reference document that explains the different exploit scanning options reported by cxs.

/etc/cxs/cxs.fp

The database of exploit fingerprints.

The file needs to have world read access (644) to allow Web script file upload scanning.

/etc/cxs/cxs.defaults

If you create this file you can add default options for cxs. For example, you might want cxs to always use --clamdsock /some/other/path/to/socket

The file is a simple list of option=value statements, e.g.:

 clamdsock=/some/other/path/to/clamd.socket
 ignore=/etc/cxs/cxs.ignore
 virusscan=0

The file needs to have world read access (644) to allow Web script file upload scanning.

Note: Options used on the command line will override the default settings.

/etc/init.d/pure-uploadscript

Controls the startup of the daemon process that handles the socket interface between pure-ftpd and cxs.

If either of the following files exists the process will not start:

 /etc/ftpdisable
 /etc/cxs/ftpddisable

FTP IP addresses

FTP IP addresses are determined by scanning the relevant pure-ftpd log for the IP address, first by trying to find an account and file match, if not found the last successful login via pure-ftpd for the affected account. This could lead to false-positives, so care should be taken before blocking the IP addresses reported by cxs.

cxs Watch Daemon

This is an alternative to ftp and web script upload scanning. The cxs Watch daemon uses a separate process to constantly watch entire user accounts for new and modified files and scans them immediately. The scanning children use up significantly fewer resources than the ftp and web script upload scanning methods.

This feature requires:

  Redhat/CentOS v5+ (i.e. a kernel that supports inotify)
  Linux::Inotify2 Perl module

Systems that do not meet these requirements can continue to use the ftp and web script upload scanning methods. See the documentation for more information about this new option.

To use --Wstart and start the daemon you need to use it as if performing a normal cxs scan but include this option, e.g.:

  cxs --Wstart --www --all

However, it is recommened that instead of doing this directly, you should use the provided /etc/cxs/cxswatch.sh script to configurecxs Watch daemon and the /etc/init.d/cxswatch init script to control it. This is so you do not forget what options you use every time you start the daemon.

You should edit /etc/cxs/cxswatch.sh and change the command line to suit your requirements and then you can:

  1. Enable the init script so that cxswatch starts at boot time:
  
  chkconfig cxswatch on
  
  2. Start the daemon:

  /etc/init.d/cxswatch start

You can only have one cxs Watch daemon running at a time. If you make configuration changes you will need to restart the daemon, e.g.:

  /etc/init.d/cxswatch restart

To disable the cxswatch daemon after enabling it through the init script:

  chkconfig cxswatch off
  /etc/init.d/cxswatch stop

All of the relevant cxs scanning commands apply to the CLI for this option. See the limitations of the cxs Watch daemon in the Performance and Restrictions section.

The cxs Watch daemon logs scanning activity to /var/log/cxswatch.log

To enable monitoring the cxswatch daemon in cPanel servers, you should go into WHM > Service Manager > and tick both boxes for cxswatch, then Save. The cPanel tailwatchd daemon will then restart cxswatch if it is not running.

On cPanel servers, cxswatch will automatically start watching the directories of newly created accounts when using --allusers.

On other platforms, if you want to automatically have the cxs Watch daemon add new accounts when using --allusers you need to create an empty file in /etc/cxs/newuser with the username of the new account. cxs Watch scans that directory and on finding a new account name will start monitoring it. For example, to add a new account that has already been generated called "iamnew",you could use:

  touch /etc/cxs/newusers/iamnew

If cxs is upgraded to a new version and the cxs Watch daemon is running it will be automatically restarted with the same command.

If an ignore file us used with cxs Watch daemon and the ignore file is modified, cxs Watch will reload the ignore file and restart the child processes. However, after making a large number of changes to the ignore file or if adding puser: or user: to the ignore file, the cxs Watch daemon should be manually restarted.

Performance and Restrictions

We would recommend using --virusscan for the PHP, CGI and FTP uploads. There can be a performance overhead using ClamAV for multiple files which means that the scan will run for longer using more resources when performing user and large directory scans. For this reason it might be sensible to use --voptions for such scans. On systems where users store large amounts of email, it might also be sensible to use the example mail ignore regex provided in /etc/cxs/cxs.ignore.example for user scans.

PHP and Perl CGI web script scanning is performed on the temporary file created before the data is passed back to the initiating web script. This means that cxs cannot determine what the destination file will be as it is up to the calling script to determine that. This means that you will not be notified of the actual file that a web script creates with the data from the uploaded file. For this reason it would be sensible to enable the --delete or --quarantine option in /etc/cxs/cxscgi.sh. It is also for this reason it isn't possible to restore such files from quarantine.

The pure-ftpd file scanner scans files after they have been uploaded via FTP. This means that if the --delete option is used, the end user will not know that the uploaded file has been removed during the FTP session. It also means that cxs is deleting a file within the users account and so great care should be used when considering use of the --delete option here. Since in this case the destination file is known it may not be sensible to enable --delete in /etc/cxs/cxsftp.sh, though using --quarantine may be a good idea. You can restore such files from quarantine through the UI.

A much more efficient way to use cxs is via the cxs Watch daemon. This daemon process is able to perform file scanning using fewer server resources,more quickly and more comprehensively, and can process and remove all suspicious files regardless of how they are uploaded. The main disadvantages of this method are: inotify must be enabled for every directory being watched which could be a very IO intensive operation when starting the daemon and could take some time on servers with large amounts of data and/or large numbers of user accounts; there will be no feedback to the end-user with file uploads being quarantined or deleted (much the same as the ftp method); there is no way to block IP addresses; homedir ignore settings will not work for any files not owner by the user (e.g. the nobody user); the additional server requirements.

REQUIREMENTS

Redhat/CentOS/CloudLinux Linux

  Redhat/CentOSCloudLinux v4/5/6

  (Redhat/CentOSCloudLinux v5/6+ OS vendor kernel or custom kernel with inotify
  support for cxs Watch)

Perl modules:

  LWP::UserAgent
  File::Basename
  File::Copy
  File::Find
  File::stat
  IO::Socket
  Getopt::Long
  Time::HiRes
  Pod::Usage
  IPC::Open3
  Digest::MD5
  Archive::Zip
  Archive::Tar
  MIME::Base64
  Net::SMTP
  Net::FTP

  (Linux::Inotify2 for cxs Watch support)

ClamAV daemon process for virus scanning

mod_security v2+ for web upload script scanning (suhosin can be used instead for PHP script only scanning)

Pure-ftpd compiled with --with-uploadscript for ftp upload scanning

Note: web upload scanning can only be performed on files uploaded via the HTML ENCTYPE multipart/form-data

Note: mod_security and pure-ftpd are not required if using the cxs Watch daemon. See alternative requirements for this method above).

RECOMMENDATIONS

1. Create a quarantine location, e.g.:

  mkdir /home/quarantine
  chmod 1777 /home/quarantine

2. Use the example ignore file provided and amend to your needs:

  cp /etc/cxs/cxs.ignore.example /etc/cxs/cxs.ignore

3. Create a daily cron job to check for cxs updates and new Exploit Fingerprints, e.g.:

  0 4 * * * /usr/sbin/cxs --upgrade --quiet

4. Create a daily cron job via the UI to scan all user accounts for exploits, e.g.:

  /usr/sbin/cxs -Z --mail root --vopt mMfhexT -I /etc/cxs/cxs.ignore --qopt Mv -Q /home/quarantine --all

5. Enable ModSecurity cxs scanning (see install.txt) via /etc/cxs/cxscgi.sh, e.g.:

  /usr/sbin/cxs -Z --cgi --mail root --qopt Mv -I /etc/cxs/cxs.ignore -Q /home/quarantine  "$1"

6. If on a supported platform, run the cxs Watch daemon on all user html data via /etc/cxs/cxswatch.sh, e.g.:

  /usr/sbin/cxs --Wstart --mail root -Q /home/quarantine -I /etc/cxs/cxs.ignore --qopt Mv --www --all

7. If not on a supported platform for cxs Watch, or if preferred, Enable pure-ftpd cxs scanning (see install.txt) via /etc/cxs/cxsftp.sh, e.g.:

  /usr/sbin/cxs -Z --ftp --mail root --qopt Mv -I /etc/cxs/cxs.ignore -Q /home/quarantine  "$1"

8. We strongly recommend that you subscribe via RSS to our blog to stay informed of updates to cxs and our other applications:

  ConfigServer Blog: http://blog.configserver.com

EXAMPLES

These are examples of how you can run cxs on the command line with an explanation of what each example does:

1. Create a report file; do not virus scan; use the ignore file; only do selected scan options; scan all users:

  cxs -r /root/scan.log --novir -i /etc/cxs/cxs.ignore -o OLmMfSGChexdR --all

2. Create a report file; use the ignore file; only do selected scan options;only virus scan selected file types; scan all users:

  cxs -r /root/scan.log -i /etc/cxs/cxs.ignore -o mMfhexdR --vir --vop mMfhexT --all

3. Email scan report to root; use all scan options including "no scripts"; scan directory /tmp:

  cxs -m root -o mMOLfSGcChexdnwDZRT /tmp

4. Process /root/scan.log and append to ignore file /etc/cxs/cxs.ignore

  cxs --gen --rep /root/scan.log --ign /etc/cxs/cxs.ignore

Exploit Scanning Reference
==========================

m = Regular expression match = [regex]

cxs has a regular expression lookup table which it uses to identify suspicious
files. These regex patterns look for two types of text constructs. Firstly,
those of known exploits (a fingerprint approach). Secondly, generic text
constructs found in common between many types of exploit (a heuristic
approach). For example, one of the regex patterns looks for the use of base64
encoded data in PHP scripts. This method of obfuscation is typically used by
exploits to hide their true purpose. If this regex is matched from the text
in a file, then that file will be reported as suspicious. You can ignore
specific regex patterns using an ignore file and the match: prefix.

M = Known exploit = [Fingerprint Match]

cxs uses a lookup table of over 4500 exploit script fingerprints and matches
scripts that have an identical fingerprint value.

O = socket

A socket is typically used to transfer data between two separate processes. You
would not normally expect to find a socket within a web hosting account and its
presence is therefore regarded here as suspicious.

L = Symlink to [symlink]

A symlink, or symbolic link, is a special type of file that provides a
reference to another file or directory. These are usually used for convenience
by the OS and server administrators to reorder the file system. For example, on
a cPanel server symlinks are used in the user mail accounts structure for their
imap implementation. You would not normally expect to find a symlink within a
web hosting account web root to files outside of that account (e.g. to system
files) and its presence is therefore regarded here as suspicious. Symlinks to
files within an account are ignored.

f = suspicious file

cxs will report file suspicious files, e.g. image files that contain script
code or C/C++ files. The former should not normally exists and you don't
usually see C/C++ files in standard web hosting accounts.

S = SUID file

Files with SUID, or set user ID, permissions allow users to run an executable
with the permissions of the executable's owner. Typically, this permission is
used on files to provide elevated privileges on a server to a user executing
such a file. You would not normally expect to find a file with SUID permissions
within a web hosting account and its presence is therefore regarded here as
suspicious.

G = GUID file

Files with GUID, or set group ID, permissions allow users to run an executable
with the permissions of the executable's owner. Typically, this permission is
used on files to provide elevated privileges on a server to a user executing
such a file. You would not normally expect to find a file with SUID permissions
within a web hosting account and its presence is therefore regarded here as
suspicious.

c = core dump file

A core dump file is a special system file generated by some executables.
Typically, they are generated when an executable hits a fatal error during
execution. At best, such files indicate a problem with the executable involved
and consumes considerable disk space. At worst, core dump files have been used
to gain elevated user privileges and exploit a server.

C = core dump file deleted

This option will automatically delete core dump files as described above.

h = suspected exploit file

cxs uses a lookup table of file names and file types which are commonly used by
exploits. For example, you would not normally expect to find a file named httpd
within a web hosting account and indeed a common exploit uses that name in an
attempt to appear innocuous.

e = Linux binary or executable file

A linux binary or executable file is one that will run on a linux OS (ELF -
Executable and Linking Format). Typically, such files within user accounts are
exploits that run as daemon processes mimicking system processes to remain
hidden. You would not normally expect to find a linux binary file within a web
hosting account and its presence is therefore regarded here as suspicious.

x = Windows binary or executable file

While a windows binary file cannot be executed on a linux OS, you would not
normally expect to find one within a web hosting account and its presence could
indicate a Trojan file and so is regarded here as suspicious.

d = suspicious directory name

cxs will report directory names that contain non-standard ASCII characters.
Such directory can often be used in such a way as to appear hidden to the
end-user. An example would be a directory called /.../ or / ../ which might
appear innocuous but often such directories contain exploits.

n = hidden directory owned by nobody user

A directory with a leading dot (e.g. /.hidden/) will often not be apparent in
many FTP client applications. One that is owned by the nobody user account has
likely been created by a web script running under the nobody user account
(typically a PHP script where suPHP is not enabled). Such directories are
suspicious in their nature of attempting to be hidden and so are reported.

w = world writable directory

In a shared web hosting environment a directory that is world writable can
typically be read and written to by any user on the server. Such directories
should be avoided, especially in web roots, as it can allow exploits to spread
between user accounts.

T = script file

This is a special option to identify scripts. It attempts to identify PHP,
Perl, and other shebang ($!) script files such as shell scripts. You may not
want to allow scripts to be uploaded through upload forms, or to be present in
certain directories that you scan (e.g. /tmp or /dev/shm) so this option is
available to detect them.

E = Email script match

This indicates that the script sends out email. This can be useful if you are
trying to identify emails within an account that send out email.

 

CXS is a commercial product that is sold and licensed on a per server basis. Unlike competing products, it is strictly a one-time per server license purchase with updates for the life of the product, all at a reasonable price! Initial default installation on a single server per license is included in the price. With Toshost Managed VPS and Dedicated Server comes with free CXS Licnese. All our Shared hosting server use CXS & CSF.

• Share:
• • 
  • 
  • 
  •