diff options
Diffstat (limited to 'documentation/content/el/books/handbook/audit/_index.adoc')
| -rw-r--r-- | documentation/content/el/books/handbook/audit/_index.adoc | 333 |
1 files changed, 333 insertions, 0 deletions
diff --git a/documentation/content/el/books/handbook/audit/_index.adoc b/documentation/content/el/books/handbook/audit/_index.adoc new file mode 100644 index 0000000000..a2f04ec5df --- /dev/null +++ b/documentation/content/el/books/handbook/audit/_index.adoc @@ -0,0 +1,333 @@ +--- +title: Κεφάλαιο 18. Έλεγχος Συμβάντων Ασφαλείας +part: Μέρος III. Διαχείριση Συστήματος +prev: books/handbook/mac +next: books/handbook/disks +--- + +[[audit]] += Έλεγχος Συμβάντων Ασφαλείας +:doctype: book +:toc: macro +:toclevels: 1 +:icons: font +:sectnums: +:sectnumlevels: 6 +:source-highlighter: rouge +:experimental: +:skip-front-matter: +:toc-title: Πίνακας Περιεχομένων +:table-caption: Πίνακας +:figure-caption: Σχήμα +:example-caption: Παράδειγμα +:xrefstyle: basic +:relfileprefix: ../ +:outfilesuffix: +:sectnumoffset: 18 + +ifeval::["{backend}" == "html5"] +:imagesdir: ../../../images/books/handbook/audit/ +endif::[] + +ifeval::["{backend}" == "pdf"] +:imagesdir: ../../../../static/images/books/handbook/audit/ +endif::[] + +ifeval::["{backend}" == "epub3"] +:imagesdir: ../../../../static/images/books/handbook/audit/ +endif::[] + +include::shared/authors.adoc[] +include::shared/releases.adoc[] +include::shared/el/mailing-lists.adoc[] +include::shared/el/teams.adoc[] +include::shared/el/urls.adoc[] + +toc::[] + +[[audit-synopsis]] +== Σύνοψη + +Οι εκδόσεις του FreeBSD από την 6.2-RELEASE και μετά περιλαμβάνουν υποστήριξη για λεπτομερή έλεγχο συμβάντων ασφαλείας. Ο έλεγχος συμβάντων επιτρέπει αξιόπιστη, λεπτομερή και παραμετροποιήσιμη καταγραφή πλήθους συμβάντων σχετικών με την ασφάλεια, συμπεριλαμβανομένων των logins, των αλλαγών ρυθμίσεων, καθώς και της πρόσβασης σε αρχεία και στο δίκτυο. Οι καταγραφές αυτές είναι πολύτιμες για απευθείας παρακολούθηση του συστήματος, ανίχνευση εισβολέων, καθώς και για ανάλυση μετά από κάποια επίθεση. Το FreeBSD υλοποιεί τη μορφή αρχείων και το BSM API όπως έχουν δημοσιευτεί από την Sun(TM), και επιτρέπει διαλειτουργικότητα με τις υλοποιήσεις ελέγχου τόσο του Solaris(TM) της Sun(TM) όσο του Mac OS(R) της Apple(R). + +Το κεφάλαιο αυτό εστιάζει στην εγκατάσταση και ρύθμιση του Ελέγχου Συμβάντων. Εξηγεί τις πολιτικές ελέγχου, και παρέχει ένα παράδειγμα ρυθμίσεων ελέγχου. + +Αφού διαβάσετε αυτό το κεφάλαιο, θα ξέρετε: + +* Τι είναι ο έλεγχος συμβάντων και πως λειτουργεί. +* Πως να ρυθμίσετε τον έλεγχο συμβάντων στο FreeBSD για χρήστες και προγράμματα (processes). +* Πως να αναλύσετε τα ίχνη του ελέγχου χρησιμοποιώντας τα εργαλεία μείωσης όγκου δεδομένων και ανάλυσης. + +Πριν διαβάσετε αυτό το κεφάλαιο, θα πρέπει: + +* Να κατανοείτε τις βασικές έννοιες του UNIX(R) και του FreeBSD (crossref:basics[basics,Βασικές Έννοιες στο UNIX(R)]). +* Να είστε εξοικειωμένος με τις βασικές έννοιες της ρύθμισης και μεταγλώττισης του πυρήνα. (crossref:kernelconfig[kernelconfig,Ρυθμίζοντας τον Πυρήνα του FreeBSD]). +* Να έχετε κάποια εξοικείωση με την ασφάλεια και πως αυτή σχετίζεται με το FreeBSD (crossref:security[security,Ασφάλεια]). + +[WARNING] +==== + +Οι λειτουργίες ελέγχου στο FreeBSD 6.2 είναι σε πειραματικό στάδιο και η εγκατάσταση τους σε μηχανήματα παραγωγής θα πρέπει να γίνεται μόνο αφού ληφθούν σοβαρά υπόψιν οι κίνδυνοι από την εγκατάσταση πειραματικού λογισμικού. Οι γνωστοί αυτή τη στιγμή τρέχοντες περιορισμοί περιλαμβάνουν την αδυναμία ελέγχου όλων των συμβάντων που σχετίζονται με την ασφάλεια. Επίσης κάποιοι μηχανισμοί εισόδου (logins), όπως οι γραφικοί (X11-βασισμένοι) display managers, καθώς και ορισμένες υπηρεσίες τρίτων κατασκευαστών δεν είναι σωστά ρυθμισμένες για τον έλεγχο εισόδου χρηστών. +==== + +[WARNING] +==== + +Ο έλεγχος συμβάντων ασφαλείας μπορεί να δημιουργήσει πολύ λεπτομερείς καταγραφές της δραστηριότητας του συστήματος: σε ένα σύστημα με υψηλό φόρτο, τα αρχεία καταγραφής μπορεί να γίνουν πολύ μεγάλα, αν έχουν ρυθμιστεί για λεπτομερή καταγραφή, και να ξεπεράσουν τα αρκετά gigabytes την εβδομάδα σε κάποιες περιπτώσεις. Οι διαχειριστές θα πρέπει να λαμβάνουν υπόψιν τους τις πιθανές απαιτήσεις σε χώρο δίσκου σε περίπτωση ρυθμίσεων λεπτομερούς καταγραφής. Για παράδειγμα, ίσως είναι θεμιτό να αφιερωθεί ένα σύστημα αρχείων στο [.filename]#/var/audit# ώστε τα υπόλοιπα συστήματα αρχείων να μην επηρεαστούν αν ο χώρος αυτός εξαντληθεί. +==== + +[[audit-inline-glossary]] +== Key Terms in this Chapter + +Before reading this chapter, a few key audit-related terms must be explained: + +* _event_: An auditable event is any event that can be logged using the audit subsystem. Examples of security-relevant events include the creation of a file, the building of a network connection, or a user logging in. Events are either "attributable", meaning that they can be traced to an authenticated user, or "non-attributable" if they cannot be. Examples of non-attributable events are any events that occur before authentication in the login process, such as bad password attempts. +* _class_: Event classes are named sets of related events, and are used in selection expressions. Commonly used classes of events include "file creation" (fc), "exec" (ex) and "login_logout" (lo). +* _record_: A record is an audit log entry describing a security event. Records contain a record event type, information on the subject (user) performing the action, date and time information, information on any objects or arguments, and a success or failure condition. +* _trail_: An audit trail, or log file, consists of a series of audit records describing security events. Typically, trails are in roughly chronological order with respect to the time events completed. Only authorized processes are allowed to commit records to the audit trail. +* _selection expression_: A selection expression is a string containing a list of prefixes and audit event class names used to match events. +* _preselection_: The process by which the system identifies which events are of interest to the administrator in order to avoid generating audit records describing events that are not of interest. The preselection configuration uses a series of selection expressions to identify which classes of events to audit for which users, as well as global settings that apply to both authenticated and unauthenticated processes. +* _reduction_: The process by which records from existing audit trails are selected for preservation, printing, or analysis. Likewise, the process by which undesired audit records are removed from the audit trail. Using reduction, administrators can implement policies for the preservation of audit data. For example, detailed audit trails might be kept for one month, but after that, trails might be reduced in order to preserve only login information for archival purposes. + +[[audit-install]] +== Installing Audit Support + +User space support for Event Auditing is installed as part of the base FreeBSD operating system as of 6.2-RELEASE. However, Event Auditing support must be explicitly compiled into the kernel by adding the following lines to the kernel configuration file: + +[.programlisting] +.... +options AUDIT +.... + +Rebuild and reinstall the kernel via the normal process explained in crossref:kernelconfig[kernelconfig,Ρυθμίζοντας τον Πυρήνα του FreeBSD]. + +Once the kernel is built, installed, and the system has been rebooted, enable the audit daemon by adding the following line to man:rc.conf[5]: + +[.programlisting] +.... +auditd_enable="YES" +.... + +Audit support must then be started by a reboot, or by manually starting the audit daemon: + +[.programlisting] +.... +/etc/rc.d/auditd start +.... + +[[audit-config]] +== Audit Configuration + +All configuration files for security audit are found in [.filename]#/etc/security#. The following files must be present before the audit daemon is started: + +* [.filename]#audit_class# - Contains the definitions of the audit classes. +* [.filename]#audit_control# - Controls aspects of the audit subsystem, such as default audit classes, minimum disk space to leave on the audit log volume, maximum audit trail size, etc. +* [.filename]#audit_event# - Textual names and descriptions of system audit events, as well as a list of which classes each event in in. +* [.filename]#audit_user# - User-specific audit requirements, which are combined with the global defaults at login. +* [.filename]#audit_warn# - A customizable shell script used by auditd to generate warning messages in exceptional situations, such as when space for audit records is running low or when the audit trail file has been rotated. + +[WARNING] +==== + +Audit configuration files should be edited and maintained carefully, as errors in configuration may result in improper logging of events. +==== + +=== Event Selection Expressions + +Selection expressions are used in a number of places in the audit configuration to determine which events should be audited. Expressions contain a list of event classes to match, each with a prefix indicating whether matching records should be accepted or ignored, and optionally to indicate if the entry is intended to match successful or failed operations. Selection expressions are evaluated from left to right, and two expressions are combined by appending one onto the other. + +The following list contains the default audit event classes present in [.filename]#audit_class#: + +* `all` - `all` - Match all event classes. +* `ad` - `administrative` - Administrative actions performed on the system as a whole. +* `ap` - `application` - Application defined action. +* `cl` - `file_close` - Audit calls to the `close` system call. +* `ex` - `exec` - Audit program execution. Auditing of command line arguments and environmental variables is controlled via man:audit_control[5] using the `argv` and `envv` parameters to the `policy` setting. +* `fa` - `file_attr_acc` - Audit the access of object attributes such as man:stat[1], man:pathconf[2] and similar events. +* `fc` - `file_creation` - Audit events where a file is created as a result. +* `fd` - `file_deletion` - Audit events where file deletion occurs. +* `fm` - `file_attr_mod` - Audit events where file attribute modification occurs, such as man:chown[8], man:chflags[1], man:flock[2], etc. +* `fr` - `file_read` - Audit events in which data is read, files are opened for reading, etc. +* `fw` - `file_write` - Audit events in which data is written, files are written or modified, etc. +* `io` - `ioctl` - Audit use of the man:ioctl[2] system call. +* `ip` - `ipc` - Audit various forms of Inter-Process Communication, including POSIX pipes and System V IPC operations. +* `lo` - `login_logout` - Audit man:login[1] and man:logout[1] events occurring on the system. +* `na` - `non_attrib` - Audit non-attributable events. +* `no` - `no_class` - Match no audit events. +* `nt` - `network` - Audit events related to network actions, such as man:connect[2] and man:accept[2]. +* `ot` - `other` - Audit miscellaneous events. +* `pc` - `process` - Audit process operations, such as man:exec[3] and man:exit[3]. + +These audit event classes may be customized by modifying the [.filename]#audit_class# and [.filename]#audit_event# configuration files. + +Each audit class in the list is combined with a prefix indicating whether successful/failed operations are matched, and whether the entry is adding or removing matching for the class and type. + +* (none) Audit both successful and failed instances of the event. +* `+` Audit successful events in this class. +* `-` Audit failed events in this class. +* `^` Audit neither successful nor failed events in this class. +* `^+` Don't audit successful events in this class. +* `^-` Don't audit failed events in this class. + +The following example selection string selects both successful and failed login/logout events, but only successful execution events: + +[.programlisting] +.... +lo,+ex +.... + +=== Configuration Files + +In most cases, administrators will need to modify only two files when configuring the audit system: [.filename]#audit_control# and [.filename]#audit_user#. The first controls system-wide audit properties and policies; the second may be used to fine-tune auditing by user. + +[[audit-auditcontrol]] +==== The [.filename]#audit_control# File + +The [.filename]#audit_control# file specifies a number of defaults for the audit subsystem. Viewing the contents of this file, we see the following: + +[.programlisting] +.... +dir:/var/audit +flags:lo +minfree:20 +naflags:lo +policy:cnt +filesz:0 +.... + +The `dir` option is used to set one or more directories where audit logs will be stored. If more than one directory entry appears, they will be used in order as they fill. It is common to configure audit so that audit logs are stored on a dedicated file system, in order to prevent interference between the audit subsystem and other subsystems if the file system fills. + +The `flags` field sets the system-wide default preselection mask for attributable events. In the example above, successful and failed login and logout events are audited for all users. + +The `minfree` option defines the minimum percentage of free space for the file system where the audit trail is stored. When this threshold is exceeded, a warning will be generated. The above example sets the minimum free space to twenty percent. + +The `naflags` option specifies audit classes to be audited for non-attributed events, such as the login process and system daemons. + +The `policy` option specifies a comma-separated list of policy flags controlling various aspects of audit behavior. The default `cnt` flag indicates that the system should continue running despite an auditing failure (this flag is highly recommended). Another commonly used flag is `argv`, which causes command line arguments to the man:execve[2] system call to audited as part of command execution. + +The `filesz` option specifies the maximum size in bytes to allow an audit trail file to grow to before automatically terminating and rotating the trail file. The default, 0, disables automatic log rotation. If the requested file size is non-zero and below the minimum 512k, it will be ignored and a log message will be generated. + +[[audit-audituser]] +==== The [.filename]#audit_user# File + +The [.filename]#audit_user# file permits the administrator to specify further audit requirements for specific users. Each line configures auditing for a user via two fields: the first is the `alwaysaudit` field, which specifies a set of events that should always be audited for the user, and the second is the `neveraudit` field, which specifies a set of events that should never be audited for the user. + +The following example [.filename]#audit_user# file audits login/logout events and successful command execution for the root user, and audits file creation and successful command execution for the www user. If used with the example [.filename]#audit_control# file above, the `lo` entry for `root` is redundant, and login/logout events will also be audited for the `www` user. + +[.programlisting] +.... +root:lo,+ex:no +www:fc,+ex:no +.... + +[[audit-administration]] +== Administering the Audit Subsystem + +=== Viewing Audit Trails + +Audit trails are stored in the BSM binary format, so tools must be used to modify or convert to text. The `praudit` command convert trail files to a simple text format; the `auditreduce` command may be used to reduce the audit trail file for analysis, archiving, or printing purposes. `auditreduce` supports a variety of selection parameters, including event type, event class, user, date or time of the event, and the file path or object acted on. + +For example, the `praudit` utility will dump the entire contents of a specified audit log in plain text: + +[source,bash] +.... +# praudit /var/audit/AUDITFILE +.... + +Where _AUDITFILE_ is the audit log to dump. + +Audit trails consist of a series of audit records made up of tokens, which `praudit` prints sequentially one per line. Each token is of a specific type, such as `header` holding an audit record header, or `path` holding a file path from a name lookup. The following is an example of an `execve` event: + +[.programlisting] +.... +header,133,10,execve(2),0,Mon Sep 25 15:58:03 2006, + 384 msec +exec arg,finger,doug +path,/usr/bin/finger +attribute,555,root,wheel,90,24918,104944 +subject,robert,root,wheel,root,wheel,38439,38032,42086,128.232.9.100 +return,success,0 +trailer,133 +.... + +This audit represents a successful `execve` call, in which the command `finger doug` has been run. The arguments token contains both the processed command line presented by the shell to the kernel. The path token holds the path to the executable as looked up by the kernel. The attribute token describes the binary, and in particular, includes the file mode which can be used to determine if the application was setuid. The subject token describes the subject process, and stores in sequence the audit user ID, effective user ID and group ID, real user ID and group ID, process ID, session ID, port ID, and login address. Notice that the audit user ID and real user ID differ: the user `robert` has switched to the `root` account before running this command, but it is audited using the original authenticated user. Finally, the return token indicates the successful execution, and the trailer concludes the record. + +=== Reducing Audit Trails + +Since audit logs may be very large, an administrator will likely want to select a subset of records for using, such as records associated with a specific user: + +[source,bash] +.... +# auditreduce -u trhodes /var/audit/AUDITFILE | praudit +.... + +This will select all audit records produced for the user `trhodes` stored in the [.filename]#AUDITFILE# file. + +=== Delegating Audit Review Rights + +Members of the `audit` group are given permission to read audit trails in [.filename]#/var/audit#; by default, this group is empty, so only the `root` user may read audit trails. Users may be added to the `audit` group in order to delegate audit review rights to the user. As the ability to track audit log contents provides significant insight into the behavior of users and processes, it is recommended that the delegation of audit review rights be performed with caution. + +=== Live Monitoring Using Audit Pipes + +Audit pipes are cloning pseudo-devices in the device file system which allow applications to tap the live audit record stream. This is primarily of interest to authors of intrusion detection and system monitoring applications. However, for the administrator the audit pipe device is a convenient way to allow live monitoring without running into problems with audit trail file ownership or log rotation interrupting the event stream. To track the live audit event stream, use the following command line + +[source,bash] +.... +# praudit /dev/auditpipe +.... + +By default, audit pipe device nodes are accessible only to the `root` user. To make them accessible to the members of the `audit` group, add a `devfs` rule to [.filename]#devfs.rules#: + +[.programlisting] +.... +add path 'auditpipe*' mode 0440 group audit +.... + +See man:devfs.rules[5] for more information on configuring the devfs file system. + +[WARNING] +==== + +It is easy to produce audit event feedback cycles, in which the viewing of each audit event results in the generation of more audit events. For example, if all network I/O is audited, and praudit is run from an SSH session, then a continuous stream of audit events will be generated at a high rate, as each event being printed will generate another event. It is advisable to run praudit on an audit pipe device from sessions without fine-grained I/O auditing in order to avoid this happening. +==== + +=== Rotating Audit Trail Files + +Audit trails are written to only by the kernel, and managed only by the audit daemon, auditd. Administrators should not attempt to use man:newsyslog.conf[5] or other tools to directly rotate audit logs. Instead, the `audit` management tool may be used to shut down auditing, reconfigure the audit system, and perform log rotation. The following command causes the audit daemon to create a new audit log and signal the kernel to switch to using the new log. The old log will be terminated and renamed, at which point it may then be manipulated by the administrator. + +[source,bash] +.... +# audit -n +.... + +[WARNING] +==== + +If the auditd daemon is not currently running, this command will fail and an error message will be produced. +==== + +Adding the following line to [.filename]#/etc/crontab# will force the rotation every twelve hours from man:cron[8]: + +[.programlisting] +.... +0 */12 * * * root /usr/sbin/audit -n +.... + +The change will take effect once you have saved the new [.filename]#/etc/crontab#. + +Automatic rotation of the audit trail file based on file size is possible via the `filesz` option in man:audit_control[5], and is described in the configuration files section of this chapter. + +=== Compressing Audit Trails + +As audit trail files can become very large, it is often desirable to compress or otherwise archive trails once they have been closed by the audit daemon. The [.filename]#audit_warn# script can be used to perform customized operations for a variety of audit-related events, including the clean termination of audit trails when they are rotated. For example, the following may be added to the [.filename]#audit_warn# script to compress audit trails on close: + +[.programlisting] +.... +# +# Compress audit trail files on close. +# +if [ "$1" = closefile ]; then + gzip -9 $2 +fi +.... + +Other archiving activities might include copying trail files to a centralized server, deleting old trail files, or reducing the audit trail to remove unneeded records. The script will be run only when audit trail files are cleanly terminated, so will not be run on trails left unterminated following an improper shutdown. |