Common Mistakes · Guide 04 · Linux
Linux Mistakes
Linux mistakes often come from powerful commands used too broadly: recursive permission changes, unsafe sudo edits, deleting persistence, killing processes, or disabling SSH without checking the mission.
Strong Linux work is precise. Inspect users, permissions, processes, services, logs, persistence, and network state before changing them.
Quick Use
Linux rule
Powerful commands demand narrow scope and clear evidence
Before changing permissions, users, services, packages, processes, SSH, or persistence, confirm the exact object, expected state, dependency, and verification plan.
10 Linux mistakes
What goes wrong and the safer replacement
Using recursive chmod or chown without scoping the target
What goes wrong
A team may use recursive permission or ownership changes to fix one suspicious file or directory quickly.
Why it hurts
Applications, services, user access, and system behavior can break across an entire directory tree.
Stronger replacement
Inspect the exact path, expected owner, group, mode, inheritance behavior, and affected application before making the smallest necessary change.
Editing sudoers directly without validation
What goes wrong
Privilege rules may be changed quickly in /etc/sudoers or /etc/sudoers.d without syntax validation.
Why it hurts
A syntax error can break sudo access and make recovery difficult.
Stronger replacement
Use visudo or an equivalent validation step, change only the justified rule, and verify approved privilege afterward.
Disabling SSH automatically
What goes wrong
SSH may be turned off because remote access is seen as risky.
Why it hurts
If SSH is required by the mission, approved administration can be lost.
Stronger replacement
Confirm whether SSH is required, then restrict users, authentication methods, listener scope, and firewall exposure instead of disabling blindly.
Killing unknown processes before collecting evidence
What goes wrong
A process may be terminated simply because its name or behavior looks suspicious.
Why it hurts
Command-line context, parent-child relationships, open files, network connections, and other transient evidence can disappear.
Stronger replacement
Record PID, PPID, executable path, command line, user, open files, sockets, and service relationship before containment.
Deleting cron jobs or timers before documenting them
What goes wrong
Suspicious persistence may be removed as soon as it is discovered.
Why it hurts
The team can lose evidence showing what ran, when it ran, and which user or executable was involved.
Stronger replacement
Capture the cron entry or timer unit, ownership, command, timestamps, and related logs before remediation.
Assuming every account with a shell is a normal user
What goes wrong
Teams may classify Linux identities only by whether they have an interactive shell.
Why it hurts
Service, system, or automation accounts can be misidentified and disabled incorrectly.
Stronger replacement
Review UID, groups, shell, home directory, recent activity, sudo rights, and service dependencies before changing the account.
Removing packages because they look unnecessary
What goes wrong
A package may be removed to reduce attack surface without checking which service or mission function depends on it.
Why it hurts
Required applications, libraries, services, or administration tools can stop working.
Stronger replacement
Identify the package purpose, reverse dependencies, associated services, and mission role before removal.
Ignoring systemd unit files and overrides
What goes wrong
Teams may check only whether a service is running and skip the unit definition, drop-ins, or environment configuration.
Why it hurts
Suspicious startup commands, altered paths, or persistence can remain hidden.
Stronger replacement
Inspect the unit file, drop-in overrides, ExecStart, environment, account, dependencies, and journal activity.
Treating world-writable files as identical risk
What goes wrong
Every world-writable path may be changed without considering why it exists or whether sticky-bit behavior is expected.
Why it hurts
Normal Linux behavior can be broken while the real dangerous permission remains unresolved elsewhere.
Stronger replacement
Evaluate the path, file type, owner, purpose, sticky bit, service dependency, and whether the permission is actually unsafe in context.
Changing the firewall without mapping required services
What goes wrong
UFW or nftables rules may be tightened broadly without checking required listeners and remote administration.
Why it hurts
SSH, web services, DNS, or other required traffic can be blocked.
Stronger replacement
Map required services, interfaces, ports, and clients first, then narrow only unnecessary exposure.
Identity
Classify users before changing them
Permissions
Avoid broad recursive fixes
Persistence
Preserve before deleting
Evidence quick reference
Capture Linux context before containment
Process context
ps -ef
pstree -ap
readlink -f /proc/<PID>/exe
tr '\0' ' ' < /proc/<PID>/cmdline
Service context
systemctl status <service>
systemctl cat <service>
journalctl -u <service> --no-pager -n 100
Network context
ss -lntup
ip addr
ip route
Identity context
getent passwd
getent group sudo
sudo -l -U <username>
Weak habit vs better habit
Replace destructive shortcuts with evidence-first Linux work
Weak habit
Run chmod -R to fix the permissions quickly.
Better habit
Identify the exact incorrect path and repair only the permission or ownership that is actually wrong.
Weak habit
Kill the suspicious process.
Better habit
Capture PID, executable, command line, parent, user, network activity, and service relationship before containment.
Weak habit
Delete the cron job.
Better habit
Record the entry, owner, command, timing, related executable, and logs before removal.
Weak habit
Turn off SSH for security.
Better habit
Confirm mission requirements, then restrict access and authentication while preserving approved administration.
Weak habit
Remove the package because we do not need it.
Better habit
Check package purpose, dependencies, services, and mission use before uninstalling it.
Weak habit
The service is running, so the configuration is fine.
Better habit
Inspect the unit file, overrides, executable path, account, dependencies, and journal evidence.
Verification
Ask these after high-impact Linux changes
Can approved users still sign in?
Do approved administrators still have the sudo rights they need?
Are required services still running?
Does SSH state still match the mission?
Did any permission change break an application or service?
Did suspicious cron, timer, or service persistence return?
Do listeners match required services?
Are important authentication and journal logs preserved?
Linux final checklist
Preserve evidence, scope changes, and verify services
The mission was checked before disabling SSH or services.
Approved users were reviewed by UID, groups, shell, and role.
Sudo membership and effective sudo rights were checked.
Service accounts were identified before disablement.
Recursive permission changes were avoided unless fully justified.
Suspicious processes were documented before termination.
Cron jobs and systemd timers were preserved before remediation.
Systemd unit files and overrides were inspected where relevant.
World-writable and SUID / SGID findings were reviewed in context.
Firewall changes preserved required services and administration.
Important authentication and journal evidence was preserved.
Required functionality was retested after high-impact changes.