3.1 - clients, hosts, and ports
remote connections have several parts that play important roles in making the whole process work. networked applications and machines existed in a "client/server" relationship.
the client is one side of this relationship. the client initiates a connection with a remote machine. the connection begins when the client sends a request for data to the "server". in many discussions about the client/server relationship, "client" is often used to represent the end-user's computer.
the server is the other end of this relationship. the server holds data that clients would want to access, and "serves" it out upon request. in modern networks, servers represent central points where vast amounts of data are sent and received.
a machine's ports are specific endpoints for individual connections to come and go from. this helps to keep multiple connections from getting jumbled together. it isn't enough for a client and/or server to connect to another machine, they must connect to a specific port on that machine. some ports are reserved for specific services, and a lot of networked applications have specific ports to which they will connect by default.
a good way to visualize the client/server system is in the form of a public library. in this analogy, the patrons of the library represent clients, who come to the library in search of a specific book (request data). the library represents the server, as it is a building that hosts the data/information that the patrons wish to access. it loans out its materials upon request (serves data). finally, the individual shelves represent ports. each shelf is reserved for a specific topic of books, much like many ports are reserved for certain services. the library staff can be thought of as daemons, services running on a machine to handle certain tasks with or without user interaction.
3.2 - port scanning, services, and nmap
port scanning is the practice of probing the ports on a machine to gather information about the machine itself and the applications running on it. this practice is commonly used by both attackers and administrators, for very similar reasons. both have an incentive to identify and reconnoiter vulnerable spots in a machine's configuration.
by itself, port scanning is not nefarious. simply examining a server's ports and services is not revealing any confidential data, nor is it gaining unauthorized access to a system.
port scanning will tell the user (for each port scanned) if a port is:
- open/accepted: the port is active and there is a service listening on the port.
- closed: the port is either not listening or is denying requests.
- filtered/blocked/dropped: the port did not send a reply to the scanner.
a service is a networked application running on a machine in the application layer. they perform specific tasks according to their role. services "listen" on ports on their host machine, and respond to incoming connections.
examples of commonly used services are email (port 587), http/https (80/443), and printing (9100).
nmap is a popular, and powerful, application used for port scanning and reconnaissance. not only can a user scan for open and closed ports, but also learn what services are listening on the open ports, determine the operating system of the target, and test for common vulnerabilities. it has many options and modes to use, but the syntax of a basic service scan is like this:
nmap -sV host -p port/portrange
// the -sV tag denotes a "service/version" scan //
make sure to take time to read the nmap documentation in depth. it is very useful and informative.
nmap may not be preinstalled on some linux distributions, but is compatible with almost all of them. versions for windows and mac also exist, as well as GUI-based implementations.
3.3 - remote connection protocols and tools
several protocols exist for making a connection to, and communicating with, a remote machine. over the years, great improvements have been made regarding speed, reliability, usability, and security.
telnet was an early standard for remote connections, short for "teletype network". it was developed mainly to facilitate two-way communications between hosts on the same LAN (local area network), or on the wider internet.
as remote computer communications have expanded, the usefulness and popularity of telnet has decreased significantly. telnet communications are transmitted in plaintext, so it is trivial for a malicious actor to intercept and read the data being sent. because of this, telnet has largely been superseded by ssh.
on linux, telnet communications can be made using the telnet command. the usage is: telnet address port
ssh, short for "secure shell", is the modern successor of telnet. like telnet, it is meant to provide two-way communication between terminal-based hosts. however, ssh traffic is encrypted end-to-end, making it suitable for use even on unsecured, public networks.
the usage of the ssh command is as follows:
ssh options user@hostname -p port
// use the -i option to specify a keyfile to use instead of a password, like so: //
// ssh -i keyfile user@hostname -p port //
scp, short for "secure copy protocol", is a protocol for transferring files over a secure connection. it is based on the ssh protocol. its usage is as follows:
scp -P port user@hostname:path/to/file /local/target/location
netcat is a popular tool for sending and receiving data over a network connection. it is used to form a quick connection with a specified port of a remote machine. in additional to simple terminal-based communications, it can also be used for file transfer, port scanning, and port listening. the netcat utility can be invoked like this:
to send traffic to a port:
nc options hostip port
to listen for incoming traffic on a port:
nc -l otheroptions -p port
// you can make this into a shell by adding -e /bin/bash at the end //
// pipe a cat or echo into this command to have that message sent to any incoming connection //
to send a file:
nc options hostip port < file
to receive a file:
nc -l -p port > file // this saves the received file as file //
openssl is used in much the same way as netcat, but is entirely encrypted. for this reason, it is generally regarded as the more secure option. its usage is as follows:
openssl s_client -connect hostname:port