Ravindra BagaleCourses & study guides मराठी Track your progress

2. Ports and Protocols: SSH, HTTP, HTTPS, FTP/SFTP and DNS

2.5 FTP and SFTP

By Last updated:

FTP juna protocol aahe – aajun kahi hosting companies vaprtat. Pan tyacha motha problem: username aani password clear text madhe jatat.

Point FTP FTPS SFTP
Port 21 (control) + 20 or random (data) 21/990 + data ports 22 (runs over SSH)
Encryption None TLS SSH
Firewall friendliness Poor (extra data ports) Poor Good (one port)
Recommended? No Only if required Yes 
sftp -i mykey.pem ec2-user@<PUBLIC_IP>     # then: put file.txt, get file.txt, ls, bye
scp -i mykey.pem report.pdf ubuntu@<PUBLIC_IP>:~/

Why this matters for security

With Wireshark (Part 10) you will literally see an FTP password appear in the packet capture. Anonymous FTP login and old vulnerable FTP servers (Metasploitable 2 runs one) are classic lab targets. In real systems, replace FTP with SFTP/SCP over SSH.

Ravindra Bagale's Tip

Many students install vsftpd and open port 21 just to upload files to EC2. There's no need! SSH is already running – in WinSCP, FileZilla or MobaXterm choose the "SFTP" protocol, port 22, and give your key. One less open port means one less risk.

Practice task

Connect to any Linux machine with sftp, upload a file, list it, download it back, and exit with bye.

Extended teaching notes

Why this lesson matters

Hardening is deleting unnecessary risk: fewer packages, fewer open ports, fewer privileged accounts, faster patches, better logs.

Hardening related services

[('SSH', 'Key auth, no root login, Fail2ban or equivalent, SG limited to your IP/VPN.', '', ''), ('SMB / NFS / LDAP / SNMP', 'Do not expose to the internet; patch; strong auth; disable unused versions (e.g. SMBv1).', '', ''), ('SMTP', 'Authenticated relay only; SPF/DKIM/DMARC for your domains.', '', ''), ('DNS', 'Restrict zone transfers; monitor for unexpected records (crt.sh for certs).', '', ''), ('Firewalls', 'Host firewall + cloud SG/NSG; default deny; document every allow.', '', '')]

Real examples

Global: CIS Benchmarks exist for Linux, Windows and clouds. Indian company (sample): a Pune team requires SSH keys only and weekly patch windows for internet-facing hosts.

Mini case study

Suppose we are on a purple-team exercise for an Indian mid-size company (sample data). Red notes a technique from this lesson against a lab clone. Blue must show the control that stops it, the log that would have fired, and the ticket that hardens production. That is the standard this course trains you for.

Defender's worksheet (do this today)

  1. Write the lesson title, date and the exact lab target you are allowed to use.
  2. List three owned systems (VMs, apps, or cloud accounts) where this lesson applies.
  3. Run one safe check from the lesson on a lab system only. Paste the command and output.
  4. Write a two-sentence fix you would give a teammate.
  5. Name one related public advisory (CERT-In, CISA, NVD, or a vendor bulletin) with its date.

Indian workplace (sample data)

Suppose we are a junior analyst at Infosys, TCS, Wipro or a fintech SOC in Bengaluru/Pune. Turn this lesson into one checklist item with an owner, a due date and a place to store evidence (ticket + screenshot).

Global practice

Compare your notes with OWASP, CIS Benchmarks, NIST CSF/IR guidance or a cloud Well-Architected security question. Write five lines on what overlaps.

Everyday analogy

Explain the risk and the fix to a family member without jargon. If they can repeat the warning, you understand it well enough to teach juniors.

Key terms

  • Control: a safeguard (patch, config, process, detection).
  • Finding: a weakness backed by evidence.
  • Remediation: the fix plus how you verified it.
  • Scope: systems you have written permission to touch.
  • Least privilege: only the access the task needs.
  • Defence in depth: several layers so one failure does not end the story.

Common mistakes

  • Skipping written permission "just for a quick scan".
  • Practising on hostel, office or public targets without authorisation.
  • Collecting tool output without writing the fix.
  • Copying attack steps onto production to "verify". Defenders verify with versions, configs and patches.
  • Publishing screenshots that contain secrets, cookies or internal hostnames.

Recap

  • Evidence, fix, owner, date.
  • Own lab only.
  • Fix > spectacle.

Real incident: ETS (California state tests) – one stolen SFTP login used for four months to copy student records (Oct 2026)

1. What happened

Educational Testing Service (ETS) is a nonprofit testing organisation. Under a contract with the State of California, it runs the state tests for public school students. ETS used an SFTP site to send and receive test files with the California Department of Education (CDE).

  • On 25 September 2026, ETS spotted unauthorized activity on that SFTP site. It disabled the account involved, took the site offline and started an investigation with outside security experts.
  • The investigation found that someone used one compromised login credential to get into the SFTP site again and again between 22 May and 18 September 2026, and copied files with student information. That is almost four months before anyone noticed.
  • The copied files cover, at least, all students enrolled in the previous three school years. The data can include student name, date of birth, home address, school, grade, student ID numbers, demographic details, disability and testing-accommodation details, and test results. No exact number of affected students has been published. (CDE's own figures show more than 5.7 million students in California public schools in the 2025–26 school year alone.)
  • CDE says the files did not contain Social Security numbers, passwords, bank or card details, or parent information.
  • Families started getting notices on 16 October 2026, and notices will go out until early November. ETS is giving two years of free identity protection, and it has built a completely new SFTP site with stronger security controls.
  • The official notices do not say how the login was stolen and do not name the attacker. ETS says it has found no sign so far that the data was published online.

2. How the hack happened (public reporting only – high-level)

  1. ETS kept an SFTP site reachable from the internet, so that CDE and ETS could exchange large test-data files.
  2. The attacker got hold of one working username and login secret for that site. How they got it is not public.
  3. The attacker simply logged in like a normal user. SFTP encrypted the connection perfectly – but encryption only protects the data on the wire. It cannot tell a real user from a thief who has the right login.
  4. Over almost four months, the attacker came back at various times and copied the files that were on the site each time.
  5. The logins and downloads were not caught for months. The activity was found on 25 September, one week after the last known access.

3. How to stop it / defend (this lesson: FTP and SFTP)

  • SFTP is the right protocol, but it is only the lock on the pipe. Choosing SFTP over FTP (this lesson) stops password sniffing. You still have to protect who can log in.
  • Use SSH keys, not passwords, for SFTP accounts. Give each partner its own account and own key, never one shared login. Where your SFTP tool supports it, add MFA for human users.
  • Allow port 22 only from known addresses. If only one partner office or server should connect, allow only its IP address in the security group or firewall (same idea as limiting SSH to your IP in 2.2).
  • Lock each user into its own folder. Each SFTP user should see only its own folder, and only the rights it needs (for example upload-only for a sender).
  • Don't use the transfer site as a storage room. Move files away after they are picked up and auto-delete old files. A stolen login is far less harmful when the site holds only today's files.
  • Log every login and every download, and send the logs to a SIEM (Chapter 31). Alert on a login from a new country or IP, logins at odd hours, or one account downloading much more than usual.

4. How to take care so it won't happen again (checklist)

  • [ ] List every FTP/SFTP server you run, who owns it, and every account on it.
  • [ ] Remove old and unused accounts, and rotate keys and passwords on a schedule.
  • [ ] Turn off password login for SFTP accounts where keys can be used; add MFA for people.
  • [ ] Allow port 22 only from partner IP addresses that really need it.
  • [ ] Set a short retention time on the transfer folders, and delete files once they are collected.
  • [ ] Review SFTP login and download logs every week, and alert on unusual volume.
  • [ ] If a vendor handles your data, ask in the contract for these same controls and for access logs.

Source: California Department of Education, "ETS Begins Notifying California Students and Families Following Data Security Incident", 16 October 2026; ETS Notice of Data Breach published by the California Department of Education (page reviewed 19 October 2026); SecurityWeek, "One Compromised Login Exposed Millions of California Students' Records", 19 October 2026; Malwarebytes, "Millions of California students' sensitive data stolen in breach", 19 October 2026.

Check if you're safe: Password Strength Checker