Unit 4: TCP, UDP and ports · Lesson 6 of 6 · 18 min
Case file: a database open to the internet
Read a scan of your own public address, find which ports completed a handshake and which of them need no password.
case file
DeepSeek exposed ClickHouse database
DeepSeek · 2025
In January 2025 Wiz Research found publicly reachable ClickHouse databases belonging to DeepSeek on non-standard ports that required no authentication and allowed arbitrary SQL queries. A log table held over a million entries from January 6, 2025, including plaintext chat history, API keys and backend details. DeepSeek secured the databases promptly after Wiz disclosed the issue.
What went wrong
Internal databases were exposed to the internet without authentication while the company scaled rapidly.
What would have stopped it
- Never expose database ports publicly; place them behind private networking and require authentication.
- Continuously scan your external attack surface for open services on non-standard ports.
- Avoid logging user prompts and secrets in plaintext; redact sensitive fields.
What defenders could have seen
- External attack surface management alerts for open database ports.
- Database access logs showing queries from unknown internet IPs.
sourceswiz.iobleepingcomputer.com
mission
- You are
- The analyst reviewing the company's external attack surface.
- Situation
- An internet survey bot scanned corp.example's analytics server. The capture is
exposed-db.pcapand the attack surface tool's results are in~/inventory/external-scan.csv. This lab is modelled on the DeepSeek case. - Goal
- List the open ports, confirm which ones answered without a login and decide what to close.
- Hand in
- The open ports and the two that must not be public.
Open, closed, and open with no login
- Survey bot to analytics01: SYN to 5432
- analytics01 to Survey bot: RST: closed
- Survey bot to analytics01: SYN to 8123
- analytics01 to Survey bot: SYN-ACK: open
- Survey bot to analytics01: GET /ping
- analytics01 to Survey bot: 200 Ok. (no login asked)
List the ports the bot tried
SYN without ACK is the opening knock. Sort and remove duplicates first.
tshark -r exposed-db.pcap -Y 'tcp.flags.syn==1 && tcp.flags.ack==0' -T fields -e tcp.dstport | sort -un | tr '\n' ' '
22 80 443 3306 5432 8123 9000 9200
List the ports that answered
SYN-ACK from the server means something is listening.
tshark -r exposed-db.pcap -Y 'tcp.flags.syn==1 && tcp.flags.ack==1' -T fields -e ip.src -e tcp.srcport | sort -u
203.0.113.30 443
203.0.113.30 8123
203.0.113.30 9000
you should see 443, 8123 and 9000 are open.
See whether it asked for a login
After the handshake, the bot sent one HTTP request.
tshark -r exposed-db.pcap -Y http -T fields -e ip.src -e http.request.uri -e http.response.code
198.51.100.66 /ping
203.0.113.30 200
you should see The database's HTTP port answered 200 without any credentials.
Match it with the attack surface report
Your own scanner should have flagged the same thing. Read its unauthenticated findings.
grep ',no,' external-scan.csv
203.0.113.30,8123,http,ClickHouse HTTP interface,no,data team
203.0.113.30,9000,clickhouse,ClickHouse native protocol,no,data team
you should see Both ClickHouse ports are public and need no login.
defender tip Databases belong on private networks. Even with a password, a database port on the internet is one bug away from a breach.
What a defender takes away
- 1SYN-ACK means open; an answer without a login means exposed.
- 2Scan your own public addresses continuously, including unusual ports.
- 3Put databases behind private networking and require authentication anyway.
Questions
0 of 2 solved
Answer each one from what you find on your lab machine.