radin/my-docs
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Compare commits

base: radin:dev
Branches Tags
radin:main radin:dev
...
compare: radin:d14e844a3811dc6888c1baee90d78faf3949936f
Branches Tags
radin:main radin:dev

4 Commits
dev ... d14e844a38

Author SHA1 Message Date
radinpirouz
d14e844a38 Added tcpdump doc 2026-04-09 01:59:48 +03:30
radinpirouz
2182412ade Added hping3 to documents 2026-04-05 23:27:19 +03:30
radinpirouz
bd21f7c0df Rewrited Git Doc 2026-03-16 15:46:58 +03:30
radin
06eef16b93 Merge pull request 'Update From Dev To Main' (#1) from dev into main 
Reviewed-on: #1
 2026-03-13 10:35:05 +00:00
4 changed files with 1108 additions and 311 deletions
Expand all files Collapse all files

567
Code-Management/Git/main.md
View File

@@ -1,523 +1,468 @@
# Git Commands Guide (DevOps-Oriented) # Git Commands Guide for DevOps Engineers
**Professional Reference Document**
*Comprehensive Git workflow for development, CI/CD pipelines, and team collaboration*
---
## Table of Contents
1. [Installation and Setup](#1-installation-and-setup)
2. [SSH Key Configuration](#2-ssh-key-configuration)
3. [Repository Initialization](#3-repository-initialization)
4. [Basic Workflow](#4-basic-workflow)
5. [Status and History](#5-status-and-history)
6. [File Operations](#6-file-operations)
7. [Branch Management](#7-branch-management)
8. [Merging and Rebasing](#8-merging-and-rebasing)
9. [Remote Operations](#9-remote-operations)
10. [Commit Management](#10-commit-management)
11. [Removing Commits](#11-removing-commits)
12. [Stash Operations](#12-stash-operations)
13. [Tags and Releases](#13-tags-and-releases)
14. [.gitignore Management](#14-gitignore-management)
15. [Configuration and Aliases](#15-configuration-and-aliases)
16. [Troubleshooting and Recovery](#16-troubleshooting-and-recovery)
17. [Repository Cloning](#17-repository-cloning)
---
## 1. Installation and Setup ## 1. Installation and Setup
### Install Git ### **Install Git**
Download from official source: [git-scm.com](https://git-scm.com/)
Download and install Git from:
[https://git-scm.com/](https://git-scm.com/)
Linux (Debian/Ubuntu):
**Linux Distributions:**
```bash ```bash
# Debian/Ubuntu
sudo apt update && sudo apt install git -y sudo apt update && sudo apt install git -y
# RHEL/CentOS/Fedora
sudo yum install git -y # or dnf install git -y
``` ```
RHEL/CentOS: **macOS:**
```bash
sudo yum install git -y
```
macOS (Homebrew):
```bash ```bash
brew install git brew install git
``` ```
### Verify Installation ### **Verify Installation**
```bash ```bash
git --version git --version
``` ```
*Displays installed Git version*
### Configure User Identity ### **Configure User Identity**
Git requires author information for every commit:
Git uses this information for commits:
```bash ```bash
git config --global user.name "Your Name" git config --global user.name "Your Full Name"
git config --global user.email "your.email@example.com" git config --global user.email "your.email@company.com"
``` ```
Check configuration: **Configuration Scopes:**
| Scope | Command Flag | Applies To | Persistence |
|-------|--------------|------------|-------------|
| System | `--system` | All users on machine | System-wide |
| Global | `--global` | Current user | User account |
| Local | `--local` | Specific repository | Repository only |
**Verify Configuration:**
```bash ```bash
git config --list git config --list
``` ```
Configuration scopes:
* `--system`: All users
* `--global`: Current user
* `--local`: Repository only
--- ---
## 2. SSH Key Configuration ## 2. SSH Key Configuration
### Generate SSH Key ### **Generate SSH Key Pair**
```bash ```bash
ssh-keygen -t ed25519 -C "your.email@example.com" ssh-keygen -t ed25519 -C "your.email@company.com"
``` ```
- **`-t ed25519`**: Modern, secure key algorithm
- **`-C`**: Comment for key identification
Start SSH agent and add key: ### **SSH Agent Management**
```bash ```bash
# Start SSH agent
eval "$(ssh-agent -s)" eval "$(ssh-agent -s)"
# Add private key to agent
ssh-add ~/.ssh/id_ed25519 ssh-add ~/.ssh/id_ed25519
``` ```
### Use Custom SSH Key (Per Repository) ### **Per-Repository SSH Key**
```bash ```bash
git config --local core.sshCommand "ssh -i <PATH_TO_SSH_KEY>" # Set custom key for specific repo
``` git config --local core.sshCommand "ssh -i /path/to/custom_key"
Clone with custom SSH key: # Clone with specific key (one-time)
git -c core.sshCommand="ssh -i /path/to/key" clone git@host:repo.git
```bash
git -c core.sshCommand="ssh -i <key-path>" clone git@host:repo.git
``` ```
--- ---
## 3. Initialize Repository ## 3. Repository Initialization
Create a new Git repository:
### **Create New Repository**
```bash ```bash
# Initialize with main branch
git init -b main git init -b main
```
Existing repository: # Initialize with default branch
```bash
git init git init
``` ```
**Key Concepts:**
- **Working Directory**: Files not yet tracked by Git
- **Staging Area (Index)**: Files prepared for commit
- **Repository**: Committed history and metadata
--- ---
## 4. Basic Workflow ## 4. Basic Workflow
### Stage and Commit Changes ### **Stage Changes**
Stage all changes:
```bash ```bash
# Stage all changes (new, modified, deleted)
git add -A git add -A
# Stage specific files
git add <file1> <file2>
# Stage all modified files (not new files)
git add .
``` ```
Commit changes: ### **Commit Changes**
```bash ```bash
git commit -m "Initial commit" git commit -m "Descriptive commit message"
``` ```
### Connect Local Repository to Remote ### **Connect to Remote**
```bash ```bash
git remote add origin <REPO_URL> git remote add origin <repository-url>
git remote -v # Verify remote configuration
``` ```
Verify: ### **Push to Remote**
```bash
git remote -v
```
### Push to Remote
First push:
```bash ```bash
# First push (sets upstream tracking)
git push -u origin main git push -u origin main
```
Subsequent pushes: # Subsequent pushes
```bash
git push git push
``` ```
--- ---
## 5. Repository Status and History ## 5. Status and History
### Check Repository Status
### **Repository Status**
```bash ```bash
git status git status
``` ```
*Shows working directory and staging area state*
### View Commit History ### **Commit History**
```bash
git log
```
Common options:
```bash ```bash
# One-line summary
git log --oneline git log --oneline
# Visual graph of all branches
git log --graph --oneline --all git log --graph --oneline --all
git log -p
git log -3 # Last N commits with patch
git log -p -3
# Show specific commit details
git show <commit-hash>
``` ```
### View File Changes ### **Change Visualization**
Unstaged changes:
```bash ```bash
# Unstaged changes (working directory)
git diff git diff
```
Staged changes: # Staged changes (index vs HEAD)
```bash
git diff --staged git diff --staged
```
Compare branches: # Branch comparison
git diff main..develop
```bash
git diff main..dev
``` ```
--- ---
## 6. File Operations ## 6. File Operations
### Stage Specific Files | Operation | Command | Effect |
|-----------|---------|---------|
```bash | Stage file | `git add <file>` | Moves file to staging area |
git add <file> | Unstage | `git reset <file>` | Removes from staging, keeps changes |
``` | Discard changes | `git restore <file>` | Reverts to last committed version |
| Rename | `git mv old new` | Stages rename operation |
### Unstage Files | Remove (tracked) | `git rm <file>` | Stages file deletion |
| Untrack | `git rm --cached <file>` | Removes from Git, keeps locally |
```bash
git reset <file>
```
### Discard Local Changes
```bash
git checkout -- <file>
```
Restore using modern command:
```bash
git restore <file>
```
### Rename File
```bash
git mv old-name new-name
```
### Remove File
```bash
git rm <file>
```
Remove but keep locally:
```bash
git rm --cached <file>
```
--- ---
## 7. Branch Management ## 7. Branch Management
### Create and Switch Branch ### **Branch Operations**
```bash ```bash
git checkout -b <branch-name> # Create and switch
``` git switch -c feature/new-api
Modern alternative: # List branches
git branch -v # Local branches with last commit
git branch -a # All branches (local + remote)
```bash # Delete branch
git switch -c <branch-name> git branch -d feature # Safe delete (merged)
``` git branch -D feature # Force delete
### List Branches # Rename branch
```bash
git branch
git branch -a
git branch -v
```
### Delete Branch
```bash
git branch -d <branch-name>
```
Force delete:
```bash
git branch -D <branch-name>
```
### Rename Branch
```bash
git branch -m old-name new-name git branch -m old-name new-name
``` ```
**Branch States:**
- **Local Branch**: Exists only in your repository
- **Remote Branch**: Exists on remote server (`origin/main`)
- **Tracking Branch**: Local branch linked to remote (`main -> origin/main`)
--- ---
## 8. Merging and Rebasing ## 8. Merging and Rebasing
### Merge Branch ### **Merge (Preserves History)**
```bash ```bash
git merge <branch-name> git checkout main
git merge feature/xyz
``` ```
Merge types: **Merge Types:**
| Type | Condition | Result |
* Fast-forward |------|-----------|---------|
* Three-way merge (creates merge commit) | Fast-forward | Target ahead, no divergence | Linear history |
| Three-way | Both branches have new commits | Merge commit created |
### Rebase (Linear History)
### **Rebase (Linear History)**
```bash ```bash
git checkout feature/xyz
git rebase main git rebase main
``` ```
Abort rebase: **Rebase Controls:**
```bash ```bash
git rebase --abort git rebase --abort # Cancel rebase
``` git rebase --continue # Resolve conflicts and continue
Continue rebase:
```bash
git rebase --continue
``` ```
--- ---
## 9. Remote Operations ## 9. Remote Operations
### List Remotes ### **Remote Management**
```bash ```bash
git remote git remote -v # List remotes
git remote -v git remote show origin # Detailed remote info
git fetch --all # Fetch all remotes
``` ```
### Show Remote Details ### **Pull Strategies**
```bash ```bash
git remote show origin git pull # Fetch + merge
``` git pull --rebase # Fetch + rebase (cleaner history)
### Fetch Changes
```bash
git fetch
git fetch --all
```
### Pull Changes
Fetch + merge:
```bash
git pull
```
Rebase instead of merge:
```bash
git pull --rebase
``` ```
--- ---
## 10. Commit Management ## 10. Commit Management
### Amend Last Commit ### **Modify Last Commit**
```bash ```bash
git commit --amend git commit --amend # Edit message/files
``` ```
### Show Commit Details ### **Safe Undo (Shared Branches)**
```bash ```bash
git show <commit-id> git revert <commit-hash> # Creates reversing commit
``` ```
### Revert Commit (Safe for Shared Branches) ### **Reset Types**
```bash ```bash
git revert <commit-id> git reset --soft HEAD~1 # Keeps staging area
git reset HEAD~1 # Unstages, keeps files
git reset --hard HEAD~1 # Discards everything
``` ```
### Reset Commit (Use with Caution) ---
Soft reset: ## 11. Removing Commits
### **Remove Local (Unpushed) Commit**
```bash ```bash
# Soft reset (interactive rebase recommended)
git reset --soft HEAD~1 git reset --soft HEAD~1
# Interactive rebase for multiple commits
git rebase -i HEAD~3
# Change 'pick' to 'drop' or delete line
``` ```
Mixed reset: ### **Remove Pushed Commit from Remote**
```bash **⚠️ DANGER: Rewrites shared history**
git reset HEAD~1
```
Hard reset:
```bash ```bash
# 1. Reset locally
git reset --hard HEAD~1 git reset --hard HEAD~1
# 2. Force push (collaborators must coordinate)
git push --force-with-lease origin main
# 3. Alternative: Safer revert
git revert HEAD # Creates undoing commit
git push
```
**Team Coordination Required:**
```
1. Notify team before force push
2. Team runs: git fetch && git reset --hard origin/main
3. Use revert for shared production branches
```
### **Remove Specific Pushed Commit**
```bash
# Interactive rebase
git rebase -i <commit-before-target>~1
# Or create revert
git revert <specific-commit-hash>
``` ```
--- ---
## 11. Stash (Temporary Changes) ## 12. Stash Operations
Save work without committing:
```bash
git stash
```
List stashes:
**Temporary Storage:**
```bash ```bash
git stash push -m "WIP: API changes"
git stash list git stash list
``` git stash apply stash@{0} # Keep stash
git stash pop # Apply and remove
Apply stash:
```bash
git stash apply
```
Pop stash:
```bash
git stash pop
``` ```
--- ---
## 12. Tags (Releases) ## 13. Tags and Releases
Create tag:
### **Tag Management**
```bash ```bash
git tag v1.0.0 # Lightweight tag
``` git tag v1.2.3
Annotated tag: # Annotated tag (recommended)
git tag -a v1.2.3 -m "Release v1.2.3"
```bash # Push tags
git tag -a v1.0.0 -m "Release v1.0.0"
```
Push tags:
```bash
git push origin --tags git push origin --tags
``` ```
--- ---
## 13. .gitignore ## 14. .gitignore Management
Create `.gitignore`:
**Create/Update:**
```bash ```bash
touch .gitignore touch .gitignore
``` ```
Example: **Common Patterns:**
``` ```
.env # Dependencies
node_modules/ node_modules/
vendor/
# Logs
*.log *.log
logs/
# Environment
.env
*.env.local
# OS
.DS_Store
Thumbs.db
``` ```
Apply after commit: **Apply Existing .gitignore:**
```bash ```bash
git rm -r --cached . git rm -r --cached .
git add . git add . && git commit -m "Apply .gitignore"
git commit -m "Apply gitignore"
``` ```
--- ---
## 14. Useful Configuration and Aliases ## 15. Configuration and Aliases
Change default editor:
### **Editor and Pager**
```bash ```bash
git config --global core.editor "vim" git config --global core.editor "code --wait"
``` ```
Create aliases: ### **Productivity Aliases**
```bash ```bash
git config --global alias.st status git config --global alias.st "status"
git config --global alias.co checkout git config --global alias.co "checkout"
git config --global alias.cm commit git config --global alias.br "branch -v"
git config --global alias.br branch git config --global alias.cm "!f() { git add -A && git commit -m \"$@\"; }; f"
``` ```
--- ---
## 15. Troubleshooting and Recovery ## 16. Troubleshooting and Recovery
Undo last commit but keep changes:
```bash
git reset --soft HEAD~1
```
Recover deleted branch:
### **Common Recovery**
```bash ```bash
# View all history (including resets)
git reflog git reflog
git checkout -b <branch-name> <commit-id>
```
Fix detached HEAD: # Recover deleted branch
git checkout -b recovery-branch <commit-hash>
```bash # Fix detached HEAD
git checkout main git checkout main
``` ```
--- ---
## 16. Clone Repository ## 17. Repository Cloning
Clone via SSH:
```bash ```bash
git clone git@github.com:user/repo.git # Standard clone
git clone <url>
# Specific branch
git clone -b develop <url>
# Shallow clone (history limited)
git clone --depth 1 <url>
``` ```
Clone specific branch: ---
```bash ## Key Git Concepts Explained
git clone -b <branch> <repo-url>
```
| Concept | Definition | Importance |
|---------|------------|-----------|
| **HEAD** | Current commit/branch pointer | Always points to active commit |
| **Index/Staging** | Intermediate area between working dir and repo | Prepares exact commit content |
| **Fast-forward** | Linear merge without merge commit | Clean history |
| **Detached HEAD** | HEAD points directly to commit | Use for inspection, create branch to save work |
| **Reflog** | Local history of HEAD movements | Recovery lifeline |
| **Force Push** | Overwrites remote history | Use only with team coordination |
**Document Version: 2.0**
*Optimized for DevOps workflows, CI/CD integration, and team collaboration*

248
Security & Networking/hping3/01-Information.md Normal file
View File

@@ -0,0 +1,248 @@
# 01. Information – What is `hping3`?
## Overview
`hping3` is a powerful network tool used primarily for:
- Crafting and sending custom TCP/IP packets
- Testing firewalls and intrusion detection systems (IDS/IPS)
- Network scanning, mapping, and discovery
- Performance and connectivity testing (latency, MTU, path issues)
From a DevOps/SRE perspective, `hping3` is like a “Swiss Army knife” for low‑level network troubleshooting and security‑oriented testing. It allows you to send packets with very precise control over headers and flags, which goes far beyond what tools like `ping` or `traceroute` can do.
> Note: `hping3` should be used only on networks and systems you are authorized to test. It can easily be mistaken for malicious traffic.
---
## Key Capabilities
### 1. Custom Packet Crafting
`hping3` lets you build packets with specific parameters:
- **IP layer**:
- Source/destination IP
- TTL, fragmentation, IP ID
- **TCP layer**:
- Source/destination port
- Flags (SYN, ACK, FIN, RST, PSH, URG)
- Sequence/ack numbers
- **UDP & ICMP**:
- Custom payloads
- Port selection (UDP)
- ICMP type and code
This is useful for:
- Reproducing odd traffic patterns seen in logs
- Simulating client behavior at the packet level
- Testing how devices and middleboxes handle specific combinations of flags
---
### 2. Stateful Firewall & IDS Testing
Because `hping3` can manipulate flags and headers, it is commonly used to test:
- Firewall rules (ingress/egress)
- NAT behavior
- IDS/IPS detection and blocking
Examples of what you can validate:
- Whether SYN packets to certain ports are correctly blocked or allowed
- How a firewall responds to fragmented packets
- Whether “stealth” scans are detected by security tooling
---
### 3. Port Scanning and Host Discovery
`hping3` can act as a flexible port scanner:
- TCP SYN scans on specific ports or ranges
- FIN/XMAS/NULL scans to observe firewall behavior
- Host discovery based on custom probes (TCP/UDP/ICMP)
While tools like `nmap` are more convenient for general scanning, `hping3` is useful when you need precise control over how probes are sent or you want to emulate specific traffic patterns.
---
### 4. Network Performance & Path Testing
`hping3` can be used to measure:
- Round-trip time (RTT) for various protocols and ports
- Packet loss and jitter under different conditions
- MTU/path issues with fragmentation control
Typical use cases:
- Measuring latency to a specific TCP port (e.g., 443) instead of relying on ICMP `ping`
- Determining whether ICMP is blocked and testing alternative paths with TCP/UDP
- Debugging connectivity problems through stateful devices that treat ICMP differently from TCP
---
### 5. Traceroute-like Functionality
`hping3` can perform traceroute‑style path discovery, but using TCP or UDP instead of ICMP:
- Helps when ICMP is filtered or rate-limited
- Shows how TCP packets to specific ports traverse the network
This is useful when:
- ICMP-based `traceroute` doesn’t give meaningful results
- You need path information for application ports (e.g., 80, 443, 5432)
---
## Why DevOps/SRE Engineers Care
In modern environments (cloud, containers, microservices), networking problems often involve:
- Security groups, NACLs, firewalls
- Load balancers and proxies
- Overlay networks (e.g., Kubernetes CNI)
- Complex routing or NAT
`hping3` helps you:
- Validate security rules (e.g., between Kubernetes nodes, across VPCs/VNETs)
- Troubleshoot weird connectivity issues that don’t show up with `ping`
- Investigate asymmetrical routing or stateful filtering
- Reproduce network conditions reported by applications or logs
It is especially valuable when standard utilities (`ping`, `curl`, `telnet`, `nc`) aren’t enough to reveal how packets are handled in transit.
---
## TCP Flags & Special Packets (FIN, URG, RST, XMAS) and Flooding
`hping3` gives you direct control over TCP flags. Understanding these is crucial for using it correctly and interpreting responses.
### FIN (Finish) flag / FIN packet
- **What it is**:
The FIN flag indicates that the sender has finished sending data and wants to gracefully close the TCP connection.
- **Normal use**:
Used at the end of a TCP session as part of the connection teardown (FIN/ACK, ACK).
- **In scanning/testing**:
- A **FIN scan** sends packets with only the FIN flag set to a port.
- On a **closed port**, the target should respond with `RST`.
- On an **open port**, many TCP/IP stacks ignore the packet (no response).
This behavior is used to infer whether ports are open/filtered without sending SYN packets that might be logged more aggressively.
### URG (Urgent) flag / URG packet
- **What it is**:
URG marks that some of the data in the TCP segment is “urgent” and should be prioritized by the receiving host.
- **Normal use**:
Rarely used in modern applications. Historically used for things like interrupt signals.
- **In scanning/testing**:
Setting the URG flag along with other flags can:
- Stress or test how TCP stacks handle unusual or rarely seen combinations
- Help detect middleboxes that mishandle or log such packets
Tools like `hping3` can create URG packets to see how targets or firewalls react.
### RST (Reset) flag / RST packet
- **What it is**:
The RST flag instructs the receiver to immediately terminate the TCP connection.
- **Normal use**:
- Sent when a packet arrives for a port where no service is listening.
- Used to abort a connection abruptly (e.g., when a process crashes or refuses a connection).
- **In scanning/testing**:
- When you send a SYN to a **closed** port, a typical response is a `RST` packet.
- Tools use the presence or absence of RST to determine whether a port is open or closed.
- You can also send RST packets to tear down existing connections (for testing, in controlled environments).
### XMAS packet
- **What it is**:
A “XMAS” (Christmas tree) packet is a TCP packet with multiple flags set at once, commonly: **FIN, PSH, URG**.
- **Why the name**:
It’s called a “Christmas tree” packet because many flags are “lit up” at the same time, like lights on a tree.
- **In scanning/testing**:
- Used for **XMAS scans**.
- Similar to FIN scans:
- On **closed** ports, the host often responds with `RST`.
- On **open** ports, many stacks send no reply.
- Some older or non-standard TCP/IP stacks respond differently, leaking information about OS type or configuration.
- **Firewall/IDS behavior**:
XMAS packets are unusual and often treated as suspicious, so many devices log or drop them, which can be useful for testing detection.
---
## What is a Flood?
In the context of `hping3` and network testing, a **flood** means sending a very high rate of packets to a target, typically as fast as possible.
- **Purpose in legitimate testing**:
- Stress-test network devices (firewalls, load balancers, routers).
- Identify bottlenecks or performance limits in network paths.
- Observe how systems behave under heavy packet load (Do they drop packets? Do they rate-limit?).
- **Types of floods (conceptually)**:
- **SYN flood**: flood of TCP SYN packets to a port.
- **ICMP flood**: flood of ICMP echo requests.
- **UDP flood**: flood of UDP packets.
- **Use in `hping3`**:
- `hping3` can send packets in “flood mode” (no delays between packets).
- This is powerful and potentially disruptive: packet floods can consume bandwidth and CPU, degrade service, or trigger protective mechanisms.
- **Operational considerations**:
- Only perform flood tests on infrastructure you control and where such testing is explicitly allowed.
- Coordinate with network and security teams.
- Monitor carefully (CPU, memory, bandwidth, and logs) during tests to avoid unintended outages.
---
## Typical Usage Contexts
- **On-prem / data center**:
Test firewalls, routers, and IDS, validate segmentation between environments (e.g., prod vs. non‑prod).
- **Cloud environments (AWS/Azure/GCP/etc.)**:
- Verify security group/NACL behavior at the packet level.
- Test connectivity between VPCs/VNETs, on‑prem VPNs, and cloud workloads.
- **Kubernetes & containerized apps**:
- Validate node-to-node or pod-to-pod connectivity.
- Test ingress/egress rules in CNIs and service meshes.
- Debug why a service is reachable via one path but not another.
---
## Limitations & Considerations
- Requires appropriate privileges (often root) to craft raw packets.
- Can generate traffic patterns similar to port scans or attacks, so:
- Always get proper authorization.
- Coordinate with security teams to avoid false alarms.
- Not designed as a full replacement for higher-level tools (e.g., `nmap`, `iperf`, `traceroute`), but as a complementary low-level tool.
- Behavior may differ slightly across OSes and network stacks.
---
## Installation (High-Level)
Availability varies by distribution, but generally:
- **Debian/Ubuntu**: via `apt` (package usually named `hping3`)
- **RHEL/CentOS/Fedora**: via `yum`/`dnf` or EPEL
- **macOS**: via Homebrew (if available) or compile from source
- **Others**: typically built from source from the official repository
(Installation instructions can be detailed in a separate document.)
---
## Summary
`hping3` is a low-level TCP/IP packet crafting and analysis tool used by DevOps/SRE and security engineers to:
- Test and validate firewall and network security policies
- Perform targeted port scans (including FIN/XMAS-style scans) and host discovery
- Troubleshoot complex connectivity and performance issues
- Generate controlled floods for stress tests (in authorized environments)

252
Security & Networking/hping3/02-Commands.md Normal file
View File

@@ -0,0 +1,252 @@
# 02. Commands – Practical `hping3` Usage
This document explains common `hping3` commands and what they do at a packet/protocol level.
Replace `<target>` with an IP or hostname, and `<port>` with a TCP/UDP port number.
> Use these commands only on systems and networks you are authorized to test.
---
## 1. ICMP “Normal Ping”
```bash
hping3 -1 <target>
```
- `-1`: Use **ICMP mode** (type 8 echo request), similar to the standard `ping` command.
- Behavior:
- Sends ICMP echo request packets to `<target>`.
- Measures round-trip time (RTT) and indicates packet loss.
- Use case:
- Basic connectivity check when you want to use `hping3` instead of `ping`.
- Helpful if you want later to switch to more advanced testing without changing tools.
---
## 2. Send TCP ACK Packets
```bash
hping3 -A <target>
```
- `-A`: Set the **ACK** flag in TCP packets.
- Behavior:
- Sends TCP packets with the ACK flag set to the default port (0 unless `-p` is specified).
- Use case:
- Test firewall rules related to **established** connections (many firewalls allow ACK packets but block SYN).
- Map which hosts respond to unsolicited ACK packets and how (RST/no response).
To target a specific port (for example, 80):
```bash
hping3 -A <target> -p 80
```
---
## 3. Send TCP SYN Packets
```bash
hping3 -S <target>
```
- `-S`: Set the **SYN** flag in TCP packets.
- Behavior:
- Sends SYN packets to the default port (0 unless `-p` is specified).
- Use case:
- Test how the target responds to connection attempts.
- When combined with `-p`, this becomes a basic SYN scan for that port.
With a specific port:
```bash
hping3 -S <target> -p <port>
```
---
## 4. Send TCP FIN Packets
```bash
hping3 -F <target>
```
- `-F`: Set the **FIN** flag in TCP packets.
- Behavior:
- Sends packets that look like “finish” requests for a connection.
- Use case:
- Perform **FIN scans** (when combined with `-p`) to check firewall behavior:
- Closed ports typically respond with `RST`.
- Open ports often send no response.
- Useful for testing how devices treat non-SYN traffic.
Example with a port:
```bash
hping3 -F <target> -p 80
```
---
## 5. Send TCP RST (Reset) Packets
```bash
hping3 -R <target>
```
- `-R`: Set the **RST** flag in TCP packets.
- Behavior:
- Sends packets that instruct the receiver to immediately terminate a connection.
- Use case:
- Observe how the target or firewall handles unexpected RST packets.
- In controlled tests, can be used to tear down test connections.
With a specific port:
```bash
hping3 -R <target> -p 80
```
---
## 6. Send TCP URG (Urgent) Packets
```bash
hping3 -U <target>
```
- `-U`: Set the **URG** flag in TCP packets.
- Behavior:
- Marks data as “urgent” (though most modern applications rarely use it).
- Use case:
- Test how TCP stacks and firewalls handle **uncommon flags**.
- Validate logging/alerting for rare or suspicious traffic patterns.
Example with a port:
```bash
hping3 -U <target> -p 80
```
---
## 7. Send XMAS Packets
```bash
hping3 -X <target>
```
- `-X`: Send **XMAS** packets (commonly FIN + PSH + URG flags set).
- Behavior:
- Creates “Christmas tree” packets with multiple flags lit.
- Use case:
- **XMAS scans**:
- Closed ports usually respond with `RST`.
- Open ports often do not respond.
- Test firewall/IDS handling of obviously suspicious packets.
Example with a port:
```bash
hping3 -X <target> -p 80
```
---
## 8. Send SYN Packet to a Destination Port
```bash
hping3 -S <target> -p <port>
```
- `-S`: SYN flag.
- `-p <port>`: Destination port.
- Behavior:
- Sends a TCP SYN packet to the specified `<port>` on `<target>`.
- Use case:
- Simple port check:
- Open port: typically responds with SYN/ACK.
- Closed port: typically responds with RST.
- Validate firewall rules for a specific service port.
---
## 9. Send SYN Packets with Random Source Address
```bash
hping3 -S <target> --rand-source
```
- `-S`: SYN flag.
- `--rand-source`: Randomize the **source IP address** for each packet.
- Behavior:
- Target sees SYN packets as if they are coming from many different IPs.
- Use case (legitimate, controlled testing):
- Test how firewalls, load balancers, or DDoS protection handle **spoofed** or distributed-looking traffic.
- Validate rate-limiting or connection limiting across “different” clients.
Note: Because of IP spoofing, responses will not come back to you; this is for observing target-side behavior/logs.
---
## 10. SYN Flood with Random Source
```bash
hping3 -S <target> --rand-source --flood
```
- `-S`: SYN flag.
- `--rand-source`: Randomize source IP per packet.
- `--flood`: Send packets as fast as possible, no output per packet.
- Behavior:
- High-rate SYN traffic with spoofed source IPs.
- Use case:
- **Stress testing** and **capacity testing** of firewalls/load balancers/IPS in a lab or authorized environment.
- Warning:
- This can severely impact services and look like a SYN flood attack.
- Use only with explicit permission and monitoring in place.
---
## 11. ICMP Flood with Spoofed Source Address
```bash
hping3 -1 <target> -a <src-address> --flood
```
> Note: Your original example used `-i`, but for ICMP mode it should be `-1`.
- `-1`: ICMP mode (echo requests).
- `-a <src-address>`: Spoof **source IP** as `<src-address>`.
- `--flood`: Send packets as fast as possible.
- Behavior:
- Sends a high-rate ICMP echo request flood to `<target>` with a fake source IP.
- Use case:
- Test how devices handle **ICMP flood** conditions and spoofed traffic (in a controlled environment).
- Warning:
- Can consume bandwidth and trigger DDoS protections or rate limits.
- Only for authorized stress testing.
If you really meant `-i` (interval), that changes send rate instead of protocol:
```bash
hping3 -1 <target> -a <src-address> --flood
# or with custom interval (e.g., 10 ms):
hping3 -1 <target> -a <src-address> -i u10000
```
---
## 12. Check If Port 22 (SSH) Is Open
```bash
hping3 -S <target> -p 22 -c 1
```
- `-S`: SYN flag (start of TCP handshake).
- `-p 22`: Destination port 22 (typically SSH).
- `-c 1`: Send only **one** packet.
- Behavior:
- Sends a single SYN to port 22 on `<target>`.
- How to interpret:
- If you see a **SYN/ACK** response, port 22 is likely open and reachable.
- If you see a **RST**, port 22 is closed or actively refused.
- If there is **no response**, the port may be filtered by a firewall or silently dropped.
---
## Summary
- `-1`: ICMP mode (ping-like).
- `-S`, `-A`, `-F`, `-R`, `-U`, `-X`: Control which TCP flags are set (SYN, ACK, FIN, RST, URG, XMAS).
- `-p <port>`: Target a specific port.
- `--rand-source`: Spoof/randomize source IPs.
- `-a <src-address>`: Spoof a specific source IP.
- `--flood`: Send packets as fast as possible (for stress testing).
- `-c <count>`: Limit number of packets sent.

352
Security & Networking/tcpdump/main.md Normal file
View File

@@ -0,0 +1,352 @@
# tcpdump
## Overview
`tcpdump` is a powerful command-line packet analyzer used to capture and inspect network traffic in real time. It is widely used by DevOps engineers, network administrators, and security professionals for troubleshooting, monitoring, and debugging network-related issues.
It works by intercepting packets flowing through a network interface and displaying them based on defined filters.
---
## How tcpdump Works
### Packet Capture Mechanism
`tcpdump` relies on the **libpcap** library to capture packets. The process involves:
1. **Network Interface Access**
- tcpdump attaches to a network interface (e.g., `eth0`, `ens33`, `wlan0`).
2. **Promiscuous Mode**
- By default, tcpdump can enable promiscuous mode, allowing it to capture all packets on the network segment, not just those addressed to the host.
3. **Kernel-Level Filtering**
- Uses Berkeley Packet Filter (BPF) to filter packets efficiently in the kernel space before sending them to user space.
4. **Packet Decoding**
- Captured packets are decoded and printed in a human-readable format.
---
## Installation
### Linux (Debian/Ubuntu)
```bash
sudo apt update
sudo apt install tcpdump
````
### Linux (RHEL/CentOS)
```bash
sudo yum install tcpdump
```
### macOS
```bash
brew install tcpdump
```
---
## Basic Syntax
```bash
tcpdump [options] [filter expression]
```
---
## Common Options
| Option | Description |
| ------------------- | ------------------------------------- |
| `-i <interface>` | Specify network interface |
| `-c <count>` | Capture a specific number of packets |
| `-n` | Disable hostname resolution |
| `-nn` | Disable hostname and port resolution |
| `-v`, `-vv`, `-vvv` | Increase verbosity |
| `-X` | Show packet contents in hex and ASCII |
| `-A` | Display packet contents in ASCII |
| `-w <file>` | Write output to file |
| `-r <file>` | Read packets from file |
| `-s <snaplen>` | Set capture size |
| `-D` | List available interfaces |
---
## Common Use Cases
### 1. Capture Packets on an Interface
```bash
tcpdump -i eth0
```
### 2. Capture a Limited Number of Packets
```bash
tcpdump -i eth0 -c 10
```
### 3. Disable Name Resolution (Faster Output)
```bash
tcpdump -nn -i eth0
```
### 4. Capture and Save to File
```bash
tcpdump -i eth0 -w capture.pcap
```
### 5. Read from a Capture File
```bash
tcpdump -r capture.pcap
```
---
## Filtering with BPF (Berkeley Packet Filter)
Filters are the most powerful feature of tcpdump.
### Basic Structure
```bash
tcpdump [options] 'filter expression'
```
### Filter Types
#### Host Filter
```bash
tcpdump host 192.168.1.1
```
#### Source/Destination Filter
```bash
tcpdump src 192.168.1.1
tcpdump dst 192.168.1.1
```
#### Port Filter
```bash
tcpdump port 80
tcpdump src port 443
tcpdump dst port 22
```
#### Protocol Filter
```bash
tcpdump tcp
tcpdump udp
tcpdump icmp
```
#### Network Filter
```bash
tcpdump net 192.168.1.0/24
```
---
## Combining Filters
### Logical Operators
| Operator | Meaning |
| -------- | -------------------------- |
| `and` | Both conditions must match |
| `or` | Either condition matches |
| `not` | Negates the condition |
### Examples
```bash
tcpdump tcp and port 80
tcpdump host 192.168.1.1 and port 22
tcpdump not port 22
tcpdump tcp and (port 80 or port 443)
```
---
## Packet Output Interpretation
Example output:
```
14:32:10.123456 IP 192.168.1.10.54321 > 93.184.216.34.80: Flags [S], seq 123456, win 65535
```
### Breakdown
| Field | Description |
| ----------- | ------------------------------- |
| Timestamp | Packet capture time |
| Protocol | IP, ARP, etc. |
| Source | Source IP and port |
| Destination | Destination IP and port |
| Flags | TCP flags (SYN, ACK, FIN, etc.) |
| seq | Sequence number |
| win | Window size |
---
## TCP Flags
| Flag | Meaning |
| ---- | ---------------------- |
| SYN | Connection initiation |
| ACK | Acknowledgment |
| FIN | Connection termination |
| RST | Reset connection |
| PSH | Push data immediately |
| URG | Urgent data |
---
## Advanced Usage
### 1. Capture HTTP Traffic
```bash
tcpdump -i eth0 -A port 80
```
### 2. Capture HTTPS Traffic (Metadata Only)
```bash
tcpdump -i eth0 port 443
```
### 3. Capture DNS Queries
```bash
tcpdump -i eth0 port 53
```
### 4. Capture Traffic Between Two Hosts
```bash
tcpdump host 192.168.1.1 and 192.168.1.2
```
### 5. Capture Large Packets Fully
```bash
tcpdump -i eth0 -s 0
```
---
## Writing and Analyzing PCAP Files
### Capture to File
```bash
tcpdump -i eth0 -w traffic.pcap
```
### Analyze with tcpdump
```bash
tcpdump -r traffic.pcap
```
### Integration with Wireshark
* Export `.pcap` files and analyze using GUI tools like Wireshark.
---
## Performance Considerations
* Use `-n` or `-nn` to reduce DNS lookups.
* Apply filters to minimize captured data.
* Avoid capturing full packets unless necessary (`-s 0`).
* Use `-c` to limit capture size.
---
## Security and Permissions
* Requires root or sudo privileges:
```bash
sudo tcpdump -i eth0
```
* Be cautious when capturing sensitive data (credentials, tokens).
---
## Troubleshooting Scenarios
### 1. Debugging Connectivity Issues
```bash
tcpdump -i eth0 host <target-ip>
```
### 2. Checking Open Ports
```bash
tcpdump -i eth0 tcp port 22
```
### 3. Investigating Packet Loss
* Look for retransmissions and duplicate ACKs.
### 4. Diagnosing DNS Problems
```bash
tcpdump -i eth0 port 53
```
---
## Best Practices
* Always filter traffic to reduce noise.
* Capture only what is necessary.
* Store captures securely.
* Use rotation when capturing long sessions:
```bash
tcpdump -i eth0 -w file_%Y%m%d%H%M%S.pcap
```
---
## Limitations
* Cannot decrypt encrypted traffic (e.g., HTTPS).
* High traffic environments may drop packets.
* Output can become overwhelming without filters.
---
## Alternatives and Complementary Tools
* `tshark` (CLI version of Wireshark)
* `wireshark` (GUI packet analyzer)
* `ngrep` (network grep tool)
* `iftop` / `nload` (bandwidth monitoring)
---
## Summary
`tcpdump` is an essential tool in a DevOps engineer’s toolkit for low-level network inspection. Mastery of filtering, efficient capture strategies, and output interpretation enables effective debugging and monitoring of complex distributed systems.