Prep for GSEC (LINUX)

This is just for me. Pretty pointless read.

— — — — — — — — — — — — — — Logs — — — — — — — — — — — — — — —

/dev/log -> syslog listens for events created by this socket. It is basically an entry point for applications to talk to, this eventually gets to syslog. Programs will typically talk through this medium via logger command.

logger -> allows for programs to send logs to system log.

logger "Test"

Check syslog and we see our message

syslog/rsyslog -> logger makes the entries into syslog. This writes to other log files. This does high I/O. So potential. Journald captures the logs. These logs are stored in a ring buffer. Though kernel doesnt write to this. it writes to klogd.

— — — — — — — — — — — — — — — kernel— — — — — — — — — — — — — — —

/proc/kmsg -> root only, its like calling syslog

/dev/kmsg -> Applications use to get kernel events. So echo

kernel messages -> dmesg(kernel ring buffer), kern.log, kmsg

kernel ring buffer(dmesg/kmsg)-> kernel operation.. NIC -> CPU. Stores log messages.

/var/log/kern -> troubleshoot kernel events

— — — — — — — — — — — — — — — auth— — — — — — — — — — —

/var/log/secure -> authentication messages

/var/log/faillog and btmp-> brute force attacks

— — — — — — — — — — — — — Failed Jobs— — — — — — — — — — — — — — — — — —

core dumps -> a process crash/death

ulimit -c and coredumpctl

strace -> view a PID syscall

/var/log/cron -> failed jobs

look at cron jobs via syslog

look at system activity via sar.

sar

— — — — — — — — — — — — — Systemd — — — — — — — — — — — — — — — — — —

Best first way of investigating failed services is through systemd units which are

socket files, devices, mounts, etc

unit files are usually in lib/systemd/system

conf file would be in /etc/systemd/system. Which would have the higher prioty

systemctl list-units — failed or systemctl list-unit-files

systemctl show 

Above command will show properties

if things fail. Reload unit files

systemctl daemon-reload

Other methods include looking at loaded lib/systemd file

Services typically failed when other dependencies dont start correctly. (ldd)

clearing failed units by systemctl reset-failed

systemctl list-sockets -all

systemd sockets are used to communicate processes

ss -p

shows services to a specific user

systemd --user

— — — — — — — — — — — — — More Systemd — — — — — — — — — — — — — — — — —

systemd targets are basically relationship management for units

so if a service is not starting correctly, prehaps its unit is not in the target file

so check

systemctl list-dependencies ssh

— — — — — — — — — — — Library or /lib— — — — — — — — — — — — — — — -

shared libraries for the system to function as well as applications

example can be the libsystemd.so.0 -> service manager

ldd- view library dependcides

Below shows all shared libraries

ldconfig -p

— — — — — — — — — — — — /dev — — — — — — — — — — — — — — — -

management of device nodes

/dev/console -> input and output devices

tty -> virtual terminals

/dev/null -> absolute BEST place to save important and critical files. redirect all logs to here

commands relating to /dev

dmesg would be useful for troubleshooting any device initalization

ls -l a device name in dev to verify proper permissions if there were previous access issues

dmsetup ls — tree -> check for any overlapping device mappings

df -h

lsblk(duh),

— — — — — — — — — — — -Environment variables — — — — — — — — — — — — —

printenv

Used by applications which may contain locations of executable files