网络安全入门两天实战：抓包、端口、密码与日志加固

如果你点进这篇笔记，是因为觉得网络安全入门就该从某个“炫酷的终端窗口”开始，那我恐怕要泼一点冷水。我记录的是自己真正开始学网络安全的头两天——没有攻陷任何目标，没有敲出让人看不懂的神秘代码，反而把“数据传输”“密码存储”“日志与加固”这些听起来并不性感的底层内容，挨个拆开看了一遍。可恰恰是这些内容，让我对“安全”二字的理解发生了根本变化：所谓网络安全，其实就是在不断回答三个问题——数据在传输时能不能被别人读懂，身份在验证时能不能被冒用，系统在运行时有没有多余的入口。

这篇文章写给两类人：一类是完全零基础、想入行但不知道从哪下手的读者；另一类是开发或运维背景，想快速建立安全视角的朋友。我会按真实的“第一天”和“第二天”的时间线来写，所有命令和实验都可以在自己的虚拟机里复现。读完之后你至少能回答：一次普通网页请求在网络上经历了什么？密码为什么不能明文存数据库？想快速排查一台Linux服务器有没有被盯上，应该看哪里？

1. 动手学习前的三个抉择：环境、路径与心态

1.1 为什么第一天我先放弃了“玩工具”的念头

我本来也以为，学网络安全第一步应该是装上一堆“看起来很厉害”的扫描器，去探测各种目标。但一位做安全运维的前辈问了我一个问题：你知道一个TCP连接长什么样吗？知道DNS查询是怎么发出去的吗？你连正常流量都没看过，扫描出来一堆端口对你来说和乱码有什么区别？

这个问题让我一下子清醒了。网络安全不是“会几个工具”就行，而是建立在通信、认证、访问控制这些基础机制之上的。连数据包都没抓过，就没资格谈“防御”；连日志都没读过，就没资格谈“排查”。所以我调整了思路：第一天不碰任何花哨的东西，先把自己每天上网发生的过程看清楚；第二天再研究账号系统和日志系统。

1.2 两天路线：不追热点，只追链路

我最终给自己定的两天路线很简单，也很“不酷”：

• 第一天上午：理解网络通信的基本链路，观察DNS解析、TCP握手和加密流量。
• 第一天下午：认识“端口”与“服务”的关系，盘点自己系统的暴露面。
• 第二天上午：搞懂密码的存储与验证逻辑，亲手把密码登录换成密钥登录。
• 第二天下午：学会看Linux日志，做一遍基础的加固动作。

这套路线没有追逐任何热点漏洞，也没有任何攻击性操作，但它构建了一个防御者最需要的地基：你知道数据怎么流动，才知道在哪里加密；你知道系统开了哪些口子，才知道该关哪里；你知道密码是怎么校验的，才知道什么样的登录策略才靠谱。

1.3 实验环境：一台虚拟机加一张快照

为了避免在自己日常使用的电脑上产生风险，也为了能随意“折腾”，我搭了一个隔离的实验环境：

• 宿主机：Windows系统。
• 虚拟机软件：VirtualBox。
• 靶机系统：Ubuntu Server，作为我反复操作的实验对象。
• 第二台最小化Linux虚拟机：用来模拟另一台设备（后面做共享访问测试时会用到）。

网络模式我选了NAT，而不是桥接。原因很简单：NAT模式下虚拟机可以主动访问外网，但外部网络不容易直接访问虚拟机，隔离性好，适合观察类实验。如果选了桥接模式，虚拟机就像一台普通设备挂在局域网里，外部设备有可能直接探测到它，对初学者来说没必要增加这种风险。

另外我把“快照”用得非常勤。改配置、跑命令之前先拍一张快照，后面哪怕把系统搞到无法启动，也可以一键还原。后面我会讲到有一次防火墙配置失误，就是靠快照救回来的。这里建议所有刚入门的人养成快照习惯，它是你试错成本最低的保险。

2. 第一天上午：抓包观察一台设备的“自我介绍”

2.1 从浏览器到服务器，链路里到底发生了什么

我打开浏览器输入一个网址，敲下回车，这个过程看似一瞬间，实际网络里发生了好几件事。我用Wireshark抓包，把步骤拆开看才真正理解：

第一步是DNS解析。浏览器不知道这个域名对应的服务器地址，需要问DNS服务器：“这个域名对应的IP是多少？”Wireshark里能看到一条DNS查询记录，紧接着是DNS响应，里面带着解析出来的IP。

第二步是TCP三次握手。浏览器拿到IP地址后，要和服务器建立一个可靠连接。三次握手分别是客户端发SYN、服务器回SYN-ACK、客户端再回ACK。整个过程如果用生活类比，就是：你敲门（SYN），门里的人问“谁啊”并打开一条门缝（SYN-ACK），你再推门确认“是我”（ACK），门才完全打开。

第三步是TLS握手。如果是HTTPS站点，TCP建立之后还会进行加密协商：客户端发ClientHello，服务端返回证书和密钥协商参数，两边确认用同一套会话密钥。这一步完成之后，应用数据才开始传输，而且是加密的。

说实话，这些概念我原来都“背过”，但直到在Wireshark里亲眼看到SYN、SYN-ACK、ACK三个包按顺序出现，才真正理解“握手”不是一个比喻，而是一条一条真实的数据包，每一跳都有时间戳、有源地址、有目标地址。

2.2 Wireshark第一次实操：过滤、观察、记录

Wireshark的界面初看有点吓人，一大片滚动数据，但其实只抓住几个点就够了：

1. 安装后打开，选择正在使用的网卡（一般是“以太网”或“Wi-Fi”），点击开始捕获。
2. 在过滤栏输入 dns || tcp.port == 443，这样只显示DNS查询和HTTPS相关的流量，避免被无关数据淹没。
3. 打开浏览器访问一个普通网站，比如 example.com。
4. 回到Wireshark停止捕获，观察列表里的信息。

我第一次抓到的是自己电脑发出的DNS请求，那一瞬间有点像“照镜子”：原来我每次上网之前，电脑都会先向DNS服务器问一次路。接着我看到了到服务器的TCP握手包，source端口是随机的五位数，destination端口是443。连续抓几次之后，你会形成一种直觉：凡是看到目标端口为443、内容不可读的包，基本可以断定是加密流量。

这里还要提醒一点：不要直接在公网环境下乱抓包，尤其不要在公司网络、公共Wi-Fi下长期开启混杂模式。实验就在自己虚拟机或者本机做，抓两三个网站的例子就够了，没必要也不应该采集他人的流量。

2.3 明信片与密信：明文与加密数据的直观对比

为了真正理解“加密到底干了什么”，我做了个对比实验：先访问一个纯HTTP的测试站点，然后访问HTTPS站点，分别抓包看内容。

访问HTTP站点时，Wireshark里可以直接看到明文内容。比如我用表单提交一个测试字符串，数据包里直接能看到相同的字符串躺在里面，完全没做任何处理。那一刻我想到一个词：明信片。明信片在邮寄途中，每个经手的中转站都能翻开看到内容。HTTP就是网络世界的明信片。

访问HTTPS站点时，同样的请求在Wireshark里变成了密文，只能看到TLS记录层的信息，具体内容全部被加密。第三方就算截获了这个包，看到的也是一堆不可读的字节。

这个实验给我一个很直观的防御启发：别以为互联网传输默认是安全的，凡是涉及账号、密码、支付信息的地方，必须先确认是不是HTTP协议。哪怕只是在你自己的实验环境里，看到明文密码包也会让你脊背发凉。

3. 第一天下午：从端口开始，盘点自己暴露了多少面

3.1 端口不是漏洞，而是“暴露面”

下午我换了个方向，不再盯流量，开始看端口。很多初学者听到“端口扫描”就觉得是攻击行为，但换个角度想：你想知道自己的服务器开了哪些门，难道不是防守的第一步吗？

端口可以理解为门牌号。一台服务器上运行着多种服务，SSH默认在22口，HTTP默认在80口，HTTPS默认在443口，MySQL默认在3306口。每个门牌号背后都对应一个正在监听的程序，也就是“服务”。攻击者想进入系统，第一步通常是试探哪些门是开的、门后是什么服务。

所以“开放端口”本身不是漏洞，但它意味着暴露面。端口开得越多、服务越复杂，潜在风险就越大。一个合格的防御者，应该随时知道自己这台机器上开着哪些门，以及这些门是不是必要的。

3.2 对着自己的虚拟机做一次资产盘点

在虚拟机上我用了两个命令来查看监听端口：

bash复制ss -tlnp

这条命令会列出所有正在监听的TCP端口，以及对应的进程名。输出里能清楚看到sshd监听在22，上面提到的HTTP测试服务监听在80。

如果要更完整的视角，可以用nmap对自己虚拟机的IP做一次扫描。注意一定是在自己的实验环境里操作：

bash复制sudo apt install nmap
nmap -sV -p- 虚拟机IP地址

-sV表示探测服务版本，-p-表示扫描全部65535个端口。我在自己的虚拟机上扫了一遍，结果和ss -tlnp看到的完全一致。这个一致性很重要：说明这台机器里没有我不知道的隐藏服务。如果结果里冒出一个我没配置过的端口，那才是真正需要紧张的事。

我整理了一份常见端口对照表，方便以后排查时快速定位：

3.3 一次“不被认证的共享”引发的信任边界思考

下午我做了一个小实验，让我对“内网信任”有了深刻直观的理解。我在第一台虚拟机里配置了一个不需要认证就能访问的SMB共享目录，然后从第二台虚拟机直接访问它，结果一下就打开了，没有要求任何用户名密码。

接着我用Wireshark在中间观察流量，看到了SMB协议的交互过程——一条共享浏览请求直接得到了成功的响应，全程没有身份验证环节。也就是说，在同一个网络里，只要某台机器开放了可匿名访问的共享，另一台设备就能直接读取里面的文件。

这个实验并没有攻击任何人，但它充分展示了一个经常被忽略的问题：网络内部设备之间存在默认信任。这样设计本来是方便资源共享的，可一旦有某台设备被入侵，攻击者就会利用这种信任从一台机器跳到另一台机器，造成所谓的横向风险扩散。

防御启示也很直接：第一，文件共享必须显式配置认证，绝不能图方便开匿名；第二，同一网络内不同信任级别的设备要尽量做网络隔离；第三，共享目录里不要放敏感文件，哪怕是自己家里的小型服务器也一样。

4. 第二天上午：密码存储——从明文到加盐哈希的攻防演进

4.1 服务器不该“知道”你的密码

第二天上午，我把注意力转向账号密码体系。先抛出一个反直觉的结论：一个设计良好的系统，数据库里不应该存储用户的明文密码，甚至不应该存储“可逆”的密码形式。服务器做的不是“保存密码”，而是“保存一段可以用来验证密码的材料”。

理解这一点最好的方式，是设想一个非常糟糕的设计：某网站的数据库把用户密码明文存储。一旦数据库出现泄露（哪怕只是备份文件被误传），攻击者拿到的就是一长串真实的用户名和密码，可以直接用来登录。更麻烦的是，很多人在多个平台用同一个密码，一次明文泄露就可能引发连锁性的账号风险。

所以现代系统的思路是：即使数据库泄露，攻击者拿到的也不应该是可直接使用的密码本身，而是一串难以还原的验证信息。这就是哈希登场的背景。

4.2 哈希、加盐、慢哈希：把密码变成验证材料

哈希函数可以把任意长度的输入，变成固定长度的输出。以SHA-256为例，不管输入是几位密码，输出永远是64个十六进制字符。而且只要输入改动一个字符，输出就会面目全非，这个过程不可逆。

在虚拟机里我做了个演示：

bash复制echo -n "123456" | sha256sum

然后再执行一次：

bash复制echo -n "123456" | sha256sum

两次输出的哈希值完全一样。这说明：同一个密码，哈希结果固定。那么问题来了——如果只是简单哈希，攻击者拿到数据库后，可以用一个装了亿万条常见密码的字典，逐个算哈希并和库里的值比对，很快就能反推出一批弱口令。这就是“彩虹表”和“字典攻击”的基本逻辑。

解决这个问题要靠“加盐”。盐是一段随机字符串，存储密码时把它和用户的密码拼在一起再算哈希。这样一来，即使两个用户的密码都是“123456”，因为盐不同，最终的哈希值也不一样，预先算好的字典就失效了。

再进一步，就是“慢哈希”。简单哈希计算太快了，攻击者一秒钟能试几千万次。慢哈希故意让计算变得很慢，比如bcrypt或argon2，验证一次密码需要几十到几百毫秒。对用户来说这点时间无所谓，但对攻击者来说，穷举成本瞬间被拉高了几个数量级。

4.3 在线猜解与离线破解的防御差异

接下来我理清了一个经常被混淆的概念：在线猜解和离线破解，对应的防御策略完全不同。

在线猜解是指攻击者不断尝试登录接口，比如拿着常用密码列表对某个账号试。它发生在“登录行为”这一层，特征是同一个账号在短时间内出现大量失败请求。防御手段也很明确：限制单IP尝试频率、加入图形验证码、连续失败后锁定账号、启用双因素认证。我后来在服务器上配的fail2ban就是专门干这个的。

离线破解发生在“数据库已经泄露”之后。攻击者不需要访问登录接口，而是直接在本地对拿到的哈希值做计算。此时限速、验证码都失效了，唯一能依靠的就是存储端的设计——加盐和慢哈希。换句话说，如果你的数据库用了明文或简单哈希，无论登录接口防护得多严密，泄露那一刻就已经输了。

还得提醒一句：很多人说“撞库”，本质上就是攻击者拿到了其他平台的用户名密码组合，拿到这边尝试登录。防御它的关键，除了要求用户设置不同密码，更可靠的是开启双因素认证——就算密码泄露，攻击者还缺第二个验证因素。

4.4 SSH密钥登录：亲自动手把密码替换掉

理解完密码原理，我决定马上动手改一个真实场景：把虚拟机的SSH密码登录改成密钥登录。这一步几乎每个服务器管理员都会做，而且技术上完全不复杂。

先在本地生成密钥对：

bash复制ssh-keygen -t ed25519

一路回车即可，会在本地生成一对公私钥。接着把公钥复制到服务器：

bash复制ssh-copy-id 用户名@虚拟机IP

它会要求输入一次当前密码，之后把公钥写入服务器的authorized_keys文件。此时先用密钥登录测试一次：

bash复制ssh 用户名@虚拟机IP

确认能登录成功，再修改服务器上的SSH配置：

bash复制sudo vim /etc/ssh/sshd_config

找到PasswordAuthentication这一行，把yes改成no，保存后重启服务：

bash复制sudo systemctl restart ssh

这一步做完后，密码登录就彻底关闭了。攻击者再如何猜密码，也不会收到任何“密码错误”的回应。但这里有个极其重要的教训：修改配置前，一定先保持一个已经登录的SSH会话不要断开，否则一旦配置错误或者公钥没传对，你会发现自己被完全锁在服务器外面。我那次没有翻车，但身边真实发生过因此只能通过云控制台重置密码的案例。

5. 第二天下午：日志审计与加固清单，以及一次翻车现场

5.1 日志里藏着大量线索：Linux日志的基本构成

第二天下午的内容最让我有“安全感”。因为在此之前，我一直觉得服务器像黑盒，出了事只能瞎猜。日志审计完全是另一套思路：通过系统记录的足迹，把一个一个异常动作给还原出来。

Linux系统里最核心的几个日志位置：

• /var/log/auth.log：认证日志，记录所有登录尝试、认证成功与失败。排查暴力破解主要看这里。
• /var/log/syslog：系统日志，记录系统运行过程中的事件。
• last命令：直接查看最近的登录记录，包括登录用户、登录来源IP、时间。
• journalctl：系统日志管理工具，可以按服务和时间过滤。

在虚拟机上，我用一行命令看了最近的认证失败记录：

bash复制sudo grep "Failed password" /var/log/auth.log | tail -n 20

看到输出的一瞬间，我才意识到这台刚刚搭好的虚拟机竟然也已经开始收到一些来自公网扫描地址的登录尝试。Wireshark里的流量可能还只是“数据”，日志里的记录则是“有人在试探你的门锁”的直接证据。

5.2 用三个维度快速排查可疑登录

第二天下午我学了一套快速判断一台服务器是否被盯上的方法，核心是从三个维度看登录日志：

第一个维度是时间。正常运维人员不会在凌晨三点反复登录，日志里如果出现大量凌晨时段的连接尝试，就要警惕。

第二个维度是来源IP。一个从未见过的IP地址，地理来源与业务无关，却频繁出现，很可能是扫描或自动化攻击。可以通过last命令看登录来源：

bash复制last -n 20

第三个维度是频率。短时间内出现大量“Failed password”，基本可以断定是被爆破类攻击盯上了。

我把三次实验过程中看到的日志整理成了一张思维表格，方便自己记忆：

需要特别说明的是：日志里有尝试登录的记录不代表服务器已经被攻破了，更不一定代表有真实风险。只要密钥登录或者强密码策略配置合理，这些尝试基本都在门外碰壁。日志审计的意义，就是让你能在这些尝试造成实质危害之前发现异常。

5.3 基础加固动作清单：补丁、防火墙、最小权限

看完了日志，我顺手做了一遍系统加固，可以说每个动作都不复杂，但非常管用：

• 更新系统补丁。定期执行系统更新，是因为绝大多数攻击利用的都是已知漏洞。sudo apt update && sudo apt upgrade 简单，但它是整个加固清单里成本最低、价值最高的动作。
• 启用防火墙。Ubuntu自带ufw，先放行SSH再启用：

bash复制sudo ufw allow OpenSSH
sudo ufw enable
sudo ufw status verbose

这里顺序非常关键：先放行SSH，再启用防火墙。如果顺序反了，防火墙默认拒绝所有入口流量，远程连接瞬间就会断开。

• 关闭不需要的服务。实验里我用不到的服务，就通过systemctl disable 服务名关掉，减少暴露面。
• 禁止root直接远程登录。在ssh配置里设置PermitRootLogin prohibit-password，让管理员通过普通用户加sudo的方式操作。
• 安装并配置fail2ban，监控认证日志，短时间内失败次数过多的来源IP会被自动临时封禁。

这些动作做完之后，我再次用nmap扫描虚拟机，打开的端口从好几个减少到了只剩22和80。仅仅减少暴露面这一步，就让攻击者的可用入口少了一大半。

5.4 翻车现场：一条防火墙命令差点把SSH锁死

最后分享一个真实的翻车现场，也是我强烈建议你建快照的原因。那天我一边看着教程一边操作防火墙，教程里是先执行ufw enable，再执行ufw allow OpenSSH。我照着敲，结果ufw enable一执行，UFW立刻按默认规则拒绝了所有入口连接，SSH当场断掉。

还好我是在VirtualBox的本地控制台操作的，没有完全失去访问方式。我先通过控制台登录，执行sudo ufw allow OpenSSH，把SSH放行后才恢复。假如我是在一台只有远程连接的云服务器上做这个操作，又没有控制台权限，恐怕就只能重置系统或去重启进入恢复模式了。

这件事给我两点教训：第一，任何涉及防火墙、SSH配置、网络隔离的操作，必须先把“允许规则加好”再“启用防火墙”，顺序永远不要反过来；第二，在高风险操作前拍快照，真的能救命。我后来养成了习惯：动防火墙、改SSH、换内核这类操作之前，一律先拍快照。

两天学下来，我最大的收获不是会背多少攻击工具的名字，而是建立了一种“透视感”——看到一次网页访问，能想到DNS查询、TCP握手、TLS协商；看到一台服务器，会下意识数它的开放端口；看到一条登录失败的日志，会去查时间、来源IP和频率。这些视角就是我最初想要的“安全思维”的起点。如果你也要入门，建议别急着给自己定“找到漏洞”的KPI，先把这三件事亲手做一遍：抓一次自己的网络流量，看一次自己的开放端口，读一次自己的登录日志。做完之后你会发现，安全感恰恰来自于你知道自己暴露了什么。