docs: Update README file

This commit is contained in:
Blake Ridgway 2025-06-15 11:40:47 -05:00
parent 5b3e869fc8
commit 0016161a8e

201
README.md
View file

@ -1,93 +1,176 @@
# shell_ideas ### 1. Automated Log File Archiver & Rotator
**Core Functionality:**
- [x] Create a script file `log-archiver.sh`.
- [x] Define variables for the target log file and the backup directory.
- [x] Use the `date` command to create a timestamp for the backup file.
- [x] Use `mkdir -p` to ensure the backup directory exists.
- [x] Use `gzip -c` to compress the log file and redirect the output to the new backup file.
- [x] Use `> $LOG_FILE` to safely clear the contents of the original log file.
- [x] Add `echo` statements to report what the script is doing.
**Enhancements & Features:**
- [ ] **Argument Parsing:** Modify the script to accept the log file path as a command-line argument instead of being hardcoded.
- [x] **Root Check:** Add a check at the beginning to ensure the script is run with `sudo` or as the root user.
- [ ] **Error Handling:** Use `set -e` to make the script exit immediately if a command fails. Add a check to ensure the provided log file actually exists.
- [ ] **Configuration File:** Move variables like `BACKUP_DIR` to an external `/etc/log-archiver.conf` file.
- [ ] **Automated Cleanup:** Add a feature to automatically delete backups older than a specified number of days (e.g., 90 days).
## Getting started ---
To make it easy for you to get started with GitLab, here's a list of recommended next steps. ### 2. Command-Line System Health Dashboard
Already a pro? Just edit this README.md and make it your own. Want to make it easy? [Use the template at the bottom](#editing-this-readme)! **Core Functionality:**
- [ ] Create a script file `sys-health.sh`.
- [ ] Use `echo` to create clear headers for each section (Memory, Disk, etc.).
- [ ] Use the `free -h` command to display memory usage.
- [ ] Use the `df -h /` command to display root disk usage.
- [ ] Use the `uptime` command to show how long the system has been running.
- [ ] Use the `who` or `users` command to list logged-in users.
## Add your files **Enhancements & Features:**
- [ ] **Color Coding:** Use ANSI escape codes or `tput` to color-code output. For example, print disk usage in red if it's over 90%.
- [ ] **More Metrics:** Add sections for CPU load (from `uptime`) and the number of running processes (`ps aux | wc -l`).
- [ ] **Live Refresh:** Wrap the main logic in a `while true` loop with a `sleep` and `clear` command to create a live-updating dashboard.
- [ ] **Command-Line Flags:** Add flags to show or hide specific sections (e.g., `./sys-health.sh --no-users`).
- [ ] [Create](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#create-a-file) or [upload](https://docs.gitlab.com/ee/user/project/repository/web_editor.html#upload-a-file) files ---
- [ ] [Add files using the command line](https://docs.gitlab.com/topics/git/add_files/#add-files-to-a-git-repository) or push an existing Git repository with the following command:
``` ### 3. Failed Login Attempt Analyzer
cd existing_repo
git remote add origin https://gitlab.com/blakeridgway/shell_ideas.git
git branch -M main
git push -uf origin main
```
## Integrate with your tools **Core Functionality:**
- [ ] Create a script file `auth-analyzer.sh`.
- [ ] Identify the correct authentication log file for the system (`/var/log/auth.log` or `/var/log/secure`).
- [ ] Use `grep` to filter for lines containing "Failed password".
- [ ] Use `awk` to extract the IP address from each matching line.
- [ ] Use a `sort | uniq -c | sort -nr` pipeline to count and rank the IPs.
- [ ] Use `head` to display the top 10 results.
- [ ] [Set up project integrations](https://gitlab.com/blakeridgway/shell_ideas/-/settings/integrations) **Enhancements & Features:**
- [ ] **Alerting:** If any single IP has more than a set number of failures (e.g., 20), send an email alert.
- [ ] **Automatic Blocking:** Add a `--block` flag that uses `iptables` or `ufw` to automatically block the top offending IP. (Use with extreme caution!).
- [ ] **IP Geolocation:** Use a command-line tool or a free API to look up the country of origin for the top IPs.
- [ ] **Date Filtering:** Add an option to only analyze logs from the current day.
## Collaborate with your team ---
- [ ] [Invite team members and collaborators](https://docs.gitlab.com/ee/user/project/members/) ### 4. Simple Network Port Scanner
- [ ] [Create a new merge request](https://docs.gitlab.com/ee/user/project/merge_requests/creating_merge_requests.html)
- [ ] [Automatically close issues from merge requests](https://docs.gitlab.com/ee/user/project/issues/managing_issues.html#closing-issues-automatically)
- [ ] [Enable merge request approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/)
- [ ] [Set auto-merge](https://docs.gitlab.com/user/project/merge_requests/auto_merge/)
## Test and Deploy **Core Functionality:**
- [ ] Create a script file `port-scanner.sh`.
- [ ] Accept a target IP address as the first command-line argument.
- [ ] Create an array or a space-separated string of common ports to check (e.g., 21, 22, 80, 443).
- [ ] Use a `for` loop to iterate through the list of ports.
- [ ] Inside the loop, use the `bash` built-in `/dev/tcp/host/port` to attempt a connection.
- [ ] Check the exit code (`$?`) of the connection attempt to determine if the port is open.
Use the built-in continuous integration in GitLab. **Enhancements & Features:**
- [ ] **Port Ranges:** Allow the user to specify a port range (e.g., `1-1024`) instead of just the hardcoded list.
- [ ] **Service Banners:** For open ports, print the common service name (e.g., "80/tcp - HTTP").
- [ ] **Timeout:** Wrap the connection attempt in the `timeout` command to prevent the script from hanging on filtered ports.
- [ ] **Verbose Mode:** Add a `-v` flag to show closed/filtered ports as well as open ones.
- [ ] [Get started with GitLab CI/CD](https://docs.gitlab.com/ee/ci/quick_start/) ---
- [ ] [Analyze your code for known vulnerabilities with Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/)
- [ ] [Deploy to Kubernetes, Amazon EC2, or Amazon ECS using Auto Deploy](https://docs.gitlab.com/ee/topics/autodevops/requirements.html)
- [ ] [Use pull-based deployments for improved Kubernetes management](https://docs.gitlab.com/ee/user/clusters/agent/)
- [ ] [Set up protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html)
*** ### 5. Interactive User Management Utility
# Editing this README **Core Functionality:**
- [ ] Create a script file `user-manager.sh`.
- [ ] Check for root privileges at the start.
- [ ] Use `echo` to display a menu with options (1. Add User, 2. Delete User, 3. List Users, 4. Exit).
- [ ] Use a `case` statement to handle the user's choice.
- [ ] Use `read` to prompt for usernames.
- [ ] Execute the appropriate commands (`useradd`, `userdel`, `cut -d: -f1 /etc/passwd`).
When you're ready to make this README your own, just edit this file and use the handy template below (or feel free to structure it however you want - this is just a starting point!). Thanks to [makeareadme.com](https://www.makeareadme.com/) for this template. **Enhancements & Features:**
- [ ] **Looping Menu:** Wrap the menu in a `while` loop so it continues to display after an action is completed, until the user chooses to exit.
- [ ] **More Options:** Add menu items for locking a user (`usermod -L`), unlocking a user (`usermod -U`), and forcing a password change.
- **Input Validation:** Before deleting a user, check if the user actually exists.
- **Password Generation:** When adding a user, automatically generate a random password and display it to the administrator.
## Suggestions for a good README ---
Every project is different, so consider which of these sections apply to yours. The sections used in the template are suggestions for most open source projects. Also keep in mind that while a README can be too long and detailed, too long is better than too short. If you think your README is too long, consider utilizing another form of documentation rather than cutting out information. ### 6. File Integrity Monitor
## Name **Core Functionality:**
Choose a self-explaining name for your project. - [ ] Create a script file `fim.sh`.
- [ ] Implement an `--init` mode to create a baseline.
- [ ] In init mode, use `find` and `sha256sum` to record the checksums of all files in a target directory (e.g., `/etc`) into a `baseline.txt` file.
- [ ] Implement a `check` mode (the default behavior).
- [ ] In check mode, generate a new list of checksums and compare it against `baseline.txt` using `diff`.
- [ ] Report whether changes were detected or not.
## Description **Enhancements & Features:**
Let people know what your project can do specifically. Provide context and add a link to any reference visitors might be unfamiliar with. A list of Features or a Background subsection can also be added here. If there are alternatives to your project, this is a good place to list differentiating factors. - [ ] **Exclusion List:** Create a `.fimignore` file where you can list files or directories to be ignored during the scan.
- [ ] **Better Reporting:** Parse the `diff` output to give clean reports like "MODIFIED: /etc/passwd" or "ADDED: /etc/newfile.conf".
- [ ] **Email Alerts:** If a change is detected, send an email notification to the system administrator.
- [ ] **Cron Automation:** Provide instructions in the README on how to set up a cron job to run the check automatically every hour or day.
## Badges ---
On some READMEs, you may see small images that convey metadata, such as whether or not all the tests are passing for the project. You can use Shields to add some to your README. Many services also have instructions for adding a badge.
## Visuals ### 7. Web Server Log Aggregator
Depending on what you are making, it can be a good idea to include screenshots or even a video (you'll frequently see GIFs rather than actual videos). Tools like ttygif can help, but check out Asciinema for a more sophisticated method.
## Installation **Core Functionality:**
Within a particular ecosystem, there may be a common way of installing things, such as using Yarn, NuGet, or Homebrew. However, consider the possibility that whoever is reading your README is a novice and would like more guidance. Listing specific steps helps remove ambiguity and gets people to using your project as quickly as possible. If it only runs in a specific context like a particular programming language version or operating system or has dependencies that have to be installed manually, also add a Requirements subsection. - [ ] Create a script file `weblog-analyzer.sh`.
- [ ] Accept the path to an access log as an argument.
- [ ] Use `awk`, `sort`, `uniq`, and `head` to find and display the top 10 most frequent IP addresses.
- [ ] Use `awk`, `sort`, `uniq`, and `head` to find and display the top 10 most requested URLs.
## Usage **Enhancements & Features:**
Use examples liberally, and show the expected output if you can. It's helpful to have inline the smallest example of usage that you can demonstrate, while providing links to more sophisticated examples if they are too long to reasonably include in the README. - [ ] **HTTP Status Codes:** Add a section to summarize HTTP response codes (e.g., 200s, 404s, 500s).
- [ ] **User-Agent Analysis:** Add a feature to search for and flag requests from common security scanners (like `sqlmap`, `nmap`, `nikto`).
- [ ] **Date Filtering:** Add flags to analyze entries only from a specific date or time range.
- [ ] **HTML Reports:** Add an option to generate a simple HTML file with the report for easier viewing.
## Support ---
Tell people where they can go to for help. It can be any combination of an issue tracker, a chat room, an email address, etc.
## Roadmap ### 8. Automated SSH Configuration Hardening
If you have ideas for releases in the future, it is a good idea to list them in the README.
## Contributing **Core Functionality:**
State if you are open to contributions and what your requirements are for accepting them. - [ ] Create a script file `ssh-harden.sh`.
- [ ] Check for root privileges.
- [ ] **Crucially, create a timestamped backup of `/etc/ssh/sshd_config` before making any changes.**
- [ ] Use `sed` to find and replace key parameters to enforce best practices (e.g., set `PermitRootLogin no`).
- [ ] After making changes, restart the SSH service to apply them.
For people who want to make changes to your project, it's helpful to have some documentation on how to get started. Perhaps there is a script that they should run or some environment variables that they need to set. Make these steps explicit. These instructions could also be useful to your future self. **Enhancements & Features:**
- [ ] **Audit Mode:** Add a `--check` flag that only reports on non-compliant settings without actually changing them.
- [ ] **Idempotency:** Before changing a setting, check its current value. If it's already compliant, do nothing. This makes the script safe to run multiple times.
- [ ] **More Rules:** Expand the script to check for other important settings like `PasswordAuthentication`, `X11Forwarding`, `AllowUsers`, etc.
- [ ] **Interactive Mode:** Add an `--interactive` flag that prompts the admin for confirmation before applying each change.
You can also document commands to lint the code or run tests. These steps help to ensure high code quality and reduce the likelihood that the changes inadvertently break something. Having instructions for running tests is especially helpful if it requires external setup, such as starting a Selenium server for testing in a browser. ---
## Authors and acknowledgment ### 9. Simple Network Honeypot Logger
Show your appreciation to those who have contributed to the project.
## License **Core Functionality:**
For open source projects, say how it is licensed. - [ ] Create a script file `honeypot.sh`.
- [ ] Define a port to listen on and a log file path.
- [ ] Use a `while true` loop to ensure the listener restarts after a connection closes.
- [ ] Use `netcat` (`nc -l -p <port>`) to listen for incoming connections.
- [ ] Pipe all output from the `nc` command to a log file, appending the data.
- [ ] Log the date and time of each connection attempt.
## Project status **Enhancements & Features:**
If you have run out of energy or time for your project, put a note at the top of the README saying that development has slowed down or stopped completely. Someone may choose to fork your project or volunteer to step in as a maintainer or owner, allowing your project to keep going. You can also make an explicit request for maintainers. - [ ] **Fake Banners:** Before the `nc` command, `echo` a convincing fake banner (e.g., "Cisco IOS Login:") to entice attackers and log their interactions.
- [ ] **Run as a Service:** Provide instructions or a helper function to run the script as a detached background process.
- [ ] **Source IP Logging:** Ensure the source IP of the connection is reliably logged for every attempt.
- [ ] **Real-time Alerting:** When a connection is detected, trigger an immediate notification (e.g., via email or a local `wall` message).
---
### 10. SSL/TLS Certificate Expiry Checker
**Core Functionality:**
- [ ] Create a script file `cert-check.sh`.
- [ ] Accept a domain name as a command-line argument.
- [ ] Use `openssl s_client` piped to `openssl x509` to get the certificate's expiration date.
- [ ] Parse the expiration date string.
- [ ] Use the `date` command to calculate the number of days remaining until the certificate expires.
- [ ] Print a human-readable summary of the result.
**Enhancements & Features:**
- [ ] **Batch Processing:** Allow the script to read a list of domains from a text file and check all of them.
- [ ] **Warning Threshold:** Set a threshold (e.g., 30 days) and print a prominent warning if a certificate is expiring soon. The script should exit with a non-zero status code in this case for easier automation.
- [ ] **CSV/JSON Output:** Add a flag to output the results in a machine-readable format like CSV or JSON.
- [ ] **More Certificate Details:** Add options to also display the certificate issuer, subject, and signature algorithm.