Nếu quý Khách hàng đang chạy một VPS có bảng quản trị như DirectAdmin hay cPanel, rất có thể tường lửa trên đó là CSF. Bài này nói một chuyện đã xảy ra mà nhiều người chưa biết, và cách xử lý.
1. Chuyện đã xảy ra
ConfigServer, công ty làm CSF, đóng cửa hẳn ngày 31/08/2025 sau hơn hai mươi năm, báo trước đúng một tháng.
Điều đáng chú ý không phải việc một công ty đóng cửa, mà là hệ quả: máy chủ cập nhật của họ đã tắt. Nghĩa là CSF bản gốc trên máy của quý Khách hàng, từ ngày đó tới nay, không nhận thêm bản vá bảo mật nào từ nguồn gốc.
Và đây là phần dễ bỏ qua nhất: CSF vẫn chạy bình thường. Nó vẫn chặn, vẫn ghi nhật ký, vẫn hiện trong bảng quản trị. Không có thông báo nào nói nó đã thành phần mềm không còn ai vá. Một tường lửa đứng im như vậy trông giống hệt một tường lửa đang khoẻ.
2. Vì sao họ chọn đóng cửa thay vì bán hoặc viết lại
Lý do kỹ thuật đáng biết, vì nó quyết định việc nên đi đường nào tiếp.
CSF dựng trên iptables. Hướng đi của các hệ điều hành dòng Red Hat là nftables: AlmaLinux 9, Rocky 9 và RHEL 9 đã dùng nftables ở bên dưới, và RHEL 10 chỉ còn nftables, không còn iptables.
Viết lại CSF cho nftables không phải sửa vài dòng, mà là làm lại phần lõi. Đó là khối việc khiến chọn đóng cửa dễ hơn chọn tiếp tục.
Nghĩa là ngay cả khi có người đỡ CSF, bài toán nftables vẫn còn nguyên ở đó.
3. Hiện có những đường nào
| Đường | Ai làm | Phù hợp với ai |
|---|---|---|
| Bản fork của cPanel | cPanel, nguồn mở, có máy chủ cập nhật riêng | Máy chạy cPanel. Đầu năm 2026 cPanel đã trỏ các máy cPanel về máy chủ cập nhật của mình |
| Bản fork của cộng đồng | Nhóm tình nguyện, đang làm dở phần nftables | Người muốn giữ nguyên cách làm cũ và chấp nhận phụ thuộc một nhóm tình nguyện |
| firewalld | Nhà phát hành hệ điều hành | Máy dựng mới, hoặc máy muốn thoát khỏi vòng phụ thuộc này |
| Các tường lửa mới cho bảng quản trị | Vài đội khác, đều còn rất mới | Nên theo dõi, chưa nên đặt máy đang phục vụ khách lên đó |
Riêng với DirectAdmin: tới đầu tháng 10/2026, DirectAdmin vẫn chưa chính thức đỡ nhánh nào. Sáu tháng sau khi CSF đóng, cộng đồng của họ vẫn đang bàn là nên đỡ một bản fork hay chuyển sang hướng firewalld và nftables.
4. Việc nên làm đầu tiên: xem CSF trên máy mình còn nhận cập nhật không
Chạy ba lệnh này. Cả ba chỉ đọc, không sửa gì.
# Phien ban CSF dang chay
sudo csf -v
# Ngay sua doi cuoi cua chinh phan mem
ls -l --time-style=long-iso /usr/sbin/csf /etc/csf/csf.conf
# Tu cap nhat co dang bat khong
sudo grep -i 'auto_updates' /etc/csf/csf.conf
Cách đọc: nếu ngày sửa đổi cuối của /usr/sbin/csf là trước tháng 9/2025, và tự cập nhật đang bật mà vẫn không có gì mới, thì máy của quý Khách hàng đang chạy một bản không còn được vá.
Thêm một lệnh cho biết CSF có thật sự đang lọc hay không, vì có máy cài CSF mà nó không chạy:
sudo systemctl is-active csf lfd
sudo csf -l | head -20
5. Đừng gỡ CSF ngay
Đây là chỗ cần nói thẳng, vì phản ứng tự nhiên khi nghe tin này là gỡ cho nhanh.
Một tường lửa cũ còn đang chặn vẫn tốt hơn không có tường lửa nào. CSF bản 2025 không nhận vá mới, nhưng các luật nó đang áp vẫn chặn đúng những gì nó được dạy chặn. Gỡ nó đi mà chưa dựng lớp thay thế là mở cửa ngay hôm nay để tránh một nguy cơ của ngày mai.
Và tuyệt đối không bật hai tường lửa cùng lúc. CSF với firewalld cùng chạy là kiểu lỗi rất khó tìm: luật của bên này chèn vào chuỗi xử lý của bên kia, rồi lệnh kiểm của bên này nói một đằng mà gói tin đi một nẻo. Quý Khách hàng sẽ mất nhiều giờ để hiểu vì sao một cổng “đã chặn” vẫn vào được, hoặc vì sao một cổng “đã mở” vẫn không vào được.
Thứ tự đúng:
- Dựng luật của tường lửa mới, chưa bật.
- Mở một kết nối mới để kiểm, không tin phiên đang mở.
- Bật tường lửa mới.
- Kiểm lại bằng một kết nối mới nữa.
- Rồi mới tắt CSF.
Bước 2 và bước 4 là hai bước hay bị bỏ. Phiên SSH đang mở sống nhờ luật cho các kết nối đã thiết lập, nên nó vẫn chạy kể cả khi luật mới đã chặn hết người mới vào. Nó không chứng minh được gì.
6. Nếu chọn firewalld: ba thứ CSF có mà firewalld không có
Đây là phần hay bị đánh giá thấp. CSF không chỉ là tường lửa. Chuyển sang firewalld mà không bù những phần dưới đây thì kết quả là một máy được bảo vệ kém hơn trước, dù trông gọn gàng hơn.
| CSF có | firewalld không có | Bù bằng gì |
|---|---|---|
| Chặn IP dò mật khẩu trên nhiều dịch vụ: bảng quản trị, FTP, thư, không chỉ SSH | Không có gì | fail2ban, nhưng phải thêm jail cho từng dịch vụ đó, không chỉ jail sshd mặc định |
| Hạn chế gửi thư ra ngoài từ script bị chiếm | Không có | Phần chống thư rác của chính bảng quản trị. Trên DirectAdmin là hai lớp sẵn có trong cấu hình Exim |
| Chặn dồn dập cổng | Không có | Giới hạn tần suất của nftables, và chỉ nên áp cho cổng quản trị |
| Giao diện bấm chuột | Không có | Không bù được. Phải gõ firewall-cmd |
Hàng cuối là điểm yếu thật. Ghi ra để quý Khách hàng cân nhắc thật, không phải nghe một bên.
Về phần chặn gửi thư ra ngoài
Phần này đáng nói riêng, vì nó là lớp duy nhất trong bảng trên không thay thế được bằng một công cụ tương đương.
Mục đích của nó: khi một tệp mã nguồn trên website bị chiếm và bắt đầu gửi thư rác, lớp này ngăn thư đi ra. Không có nó thì hậu quả thường thấy là địa chỉ IP của máy bị đưa vào danh sách chặn của các nhà cung cấp thư, và sau đó thư thật của quý Khách hàng cũng không tới được người nhận. Khôi phục uy tín một địa chỉ IP mất nhiều tuần.
⚠️ Đừng chặn cổng 25 đi ra bằng một luật tường lửa đơn giản. firewalld không lọc được theo tiến trình hay theo người dùng bằng luật thông thường. Chặn thô cả cổng 25 là chặn luôn chính máy chủ thư, tức là không gửi được thư nào, kể cả thư thật.
Cách đúng là chặn ở tầng máy chủ thư, nơi biết thư do ai gửi. Trên DirectAdmin, hai lớp sẵn có trong cấu hình Exim làm đúng việc này: một lớp chặn script gửi hàng loạt ngay tại máy chủ thư, một lớp giới hạn số thư mỗi người dùng mỗi giờ.
Một cái bẫy khi đặt jail cho fail2ban
Nếu một jail trỏ vào tệp nhật ký không tồn tại trên máy, fail2ban báo lỗi và không khởi động cả các jail khác trong cùng tệp cấu hình. Kết quả là quý Khách hàng tưởng đã có năm lớp bảo vệ mà thực ra không có lớp nào.
Nên làm theo thứ tự này:
# 1. Xem nhat ky nao CO THAT tren may
ls -l /var/log/directadmin/login.log /var/log/exim/mainlog \
/var/log/proftpd/auth.log /var/log/maillog 2>&1
# 2. Chi bat jail cho nhat ky co that, roi kiem cau hinh TRUOC khi nap lai
sudo fail2ban-client -t
# 3. Nap lai, roi doc xem jail nao that su chay
sudo systemctl reload fail2ban
sudo fail2ban-client status
Và một bước nữa mà rất ít người làm: kiểm xem bộ lọc có đọc được nhật ký hay không.
sudo fail2ban-regex /var/log/directadmin/login.log \
/etc/fail2ban/filter.d/<ten-bo-loc>.conf
Ra 0 matched trong khi nhật ký có dòng đăng nhập thất bại thật nghĩa là bộ lọc không khớp định dạng nhật ký của bản bảng quản trị trên máy này. Jail đó vẫn hiện là đang chạy, và vẫn không chặn được gì. Im lặng và vô dụng.
7. Bảng quyết định nhanh
| Tình huống của quý Khách hàng | Nên làm |
|---|---|
| Dựng máy mới | Dùng firewalld ngay từ đầu, kèm phần bù ở mục 6. Đừng cài CSF lên máy mới |
| Máy cPanel đang chạy CSF | Dùng bản fork của cPanel. Đây là nhánh có nguồn lực tốt nhất hiện nay |
| Máy DirectAdmin đang chạy CSF, có người thạo CSF | Giữ CSF, chuyển sang một bản fork còn được cập nhật, và theo dõi khi nào DirectAdmin chốt hướng |
| Máy DirectAdmin đang chạy CSF, không ai thạo | Lên lịch chuyển sang firewalld. Không gấp, nhưng đừng để quên |
| Máy đang chạy CSF mà không ai biết nó đang chặn gì | Việc đầu tiên không phải đổi tường lửa, mà là đọc xem nó đang chặn gì, bằng csf -l |
Hàng cuối là tình huống thường gặp nhất, và cũng là lý do nhiều lần chuyển tường lửa làm dịch vụ dừng: không ai biết luật cũ đang mở những cổng nào cho những ai, nên luật mới dựng lên là thiếu.
8. Việc nên làm ngay hôm nay, dù chưa chọn đường nào
Ba việc, đều không rủi ro:
| Việc | Vì sao |
|---|---|
| Chạy ba lệnh ở mục 4 và lưu kết quả lại kèm ngày | Đây là bản ghi hiện trạng. Mọi quyết định sau đó cần nó |
Xuất luật CSF đang chạy ra tệp: sudo csf -l > /root/luat-csf-$(date +%F).txt |
Đây là thứ dùng để dựng luật mới cho đúng, và là thứ cứu quý Khách hàng nếu đổi hỏng |
| Kiểm xem có đường vào thứ hai không: console của nhà cung cấp còn dùng được chứ | Mọi tai nạn tường lửa đều kết thúc ở câu hỏi này |
Việc thứ ba đáng làm nhất. Thử đăng nhập console trước khi cần tới nó, chứ không phải lúc đã mất đường vào.
9. Khi cần hỗ trợ
Quý Khách hàng đang dùng VPS tại Cloudzone và muốn rà lại tường lửa trên máy, hoặc muốn chuyển từ CSF sang firewalld mà không muốn tự làm, hãy nhắn qua khung chat ở góc phải màn hình. Gửi kèm kết quả ba lệnh ở mục 4 thì đội ngũ kỹ thuật đọc được ngay tình trạng.
Trong lúc đổi tường lửa, điều đáng nhớ nhất là giữ một đường vào thứ hai đã kiểm chắc chắn. Mọi thứ khác đều sửa lại được.