Service: A service is program which runs in the background. It answers to the requests etc. For instance, the “web service” might be provided by an httpd daemon like Apache or Nginx.
Daemon: a daemon is a type of program that runs in the background, and a service is the functionality that is provided to the system or network, which can be composed of one or more daemons.example: httpd daemon.
How to check which services are running
In modern linux, we use systemd as the service manager(it also works as login manager and many more). systemd is the root process with id 1 for userspace when linux boots up.
We can check all the services which are running using systemd service manager:
manojkumar@n36-186-058:~$ systemctl status
manojkumar@n36-186-058:~$ systemctl status sshd
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; --> this means service start during the boot time vendor preset: enabled)
Drop-In: /usr/lib/systemd/system/ssh.service.d
└─ssh_env.conf
Active: active (running) since Mon 2024-04-01 16:13:29 UTC; 3 days ago
Docs: man:sshd(8)
man:sshd_config(5)
Main PID: 27957 (sshd)
Tasks: 1 (limit: 4915)
Memory: 10.1M
CGroup: /system.slice/ssh.service
└─27957 /usr/sbin/sshd -DNetstat:
Check if service is actually listening:
manojkumar@n36-186-058:~$ netstat -tuna
Active Internet connections (servers and established)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 0.0.0.0:29503 0.0.0.0:* LISTEN
tcp 0 0 127.0.0.1:1988 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:1100 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:1101 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN
We can get the processid too for listening. The current connections are showed by ESTABLISHED.
manojkumar@n36-186-058:~$ sudo netstat -tunap | grep sshd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 27957/sshd
tcp 0 36 10.36.186.58:22 10.200.163.111:56619 ESTABLISHED 3338666/sshd: manoj
tcp6 0 0 :::22 :::* LISTEN 27957/sshdNMAP:
Are my services visible from the localhost?:
We can use nmap to scan all the ports from the perspective of the localhost and see which ports are open:
manojkumar@n36-186-058:~$ nmap localhost
Starting Nmap 7.70 ( https://nmap.org ) at 2024-04-04 19:19 UTC
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000083s latency).
Other addresses for localhost (not scanned): ::1 127.0.1.1
Not shown: 995 closed ports
PORT STATE SERVICE
22/tcp open ssh
25/tcp open smtp
111/tcp open rpcbind
1100/tcp open mctp
2200/tcp open ici
Nmap done: 1 IP address (1 host up) scanned in 0.04 seconds
manojkumar@n36-186-058:~$Below services are listening on the external interface of the server:
manojkumar@n36-186-058:~$ ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens5: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether fa:16:3e:3a:c5:43 brd ff:ff:ff:ff:ff:ff
inet 10.36.186.58/22 brd 10.36.187.255 scope global ens5
valid_lft forever preferred_lft forever
inet6 fdbd:dc61:ff:0:1:36:186:58/128 scope global
valid_lft forever preferred_lft forever
inet6 fe80::f816:3eff:fe3a:c543/64 scope link
valid_lft forever preferred_lft forever
manojkumar@n36-186-058:~$ nmap 10.36.186.58
Starting Nmap 7.70 ( https://nmap.org ) at 2024-04-04 19:20 UTC
Nmap scan report for n36-186-058.byted.org (10.36.186.58)
Host is up (0.000067s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
1100/tcp open mctp
2200/tcp open iciWe can also scan a remote server and check all the ports it is listening to:
manojkumar@n199-194-087:~$ nmap 10.36.186.58
Starting Nmap 7.70 ( https://nmap.org ) at 2024-04-04 19:24 UTC
Nmap scan report for n36-186-058.byted.org (10.36.186.58)
Host is up (0.24s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
1100/tcp open mctp
2200/tcp open ici
IPTables
In the context of Linux networking, iptables is a widely-used tool that allows system administrators to configure the packet filtering rules provided by the Linux kernel firewall. The firewall uses a set of predefined tables, and each table contains a number of chains. A chain is essentially a list of rules that can match a set of packets. Each rule within a chain can specify what to do with a packet that matches its criteria, such as allowing it through, rejecting it, or passing it to another chain for further processing.
Tables:
iptables has several tables, and each table is associated with a different kind of packet processing. The most commonly used tables are:
- Filter Table: The default table used for packet filtering (allowing or blocking traffic).
- NAT Table: Used for network address translation (e.g., port forwarding, masquerading).
- Mangle Table: Used for specialized packet alterations (e.g., changing TTL values).
- Raw Table: Used for configuring exemptions from connection tracking.
Chains:
Each table contains a few predefined chains, which are sequences of rules that the packets are checked against sequentially. The most common chains are:
- INPUT Chain: Processes incoming packets destined to local sockets. This chain is used to control the behavior of incoming connections.
- FORWARD Chain: Handles packets that are being routed through the system and are not destined for the system itself. This chain is used when the system is acting as a router or firewall for other devices.
- OUTPUT Chain: Manages outgoing packets generated by local processes. This chain is used to control what traffic the system is allowed to send out.
- PREROUTING Chain: (NAT table) Used for altering incoming packets before routing.
- POSTROUTING Chain: (NAT table) Used for altering packets as they are about to go out.
Packet Filter Rules:
Each rule within a chain can match packets based on various criteria, such as source and destination IP addresses, source and destination ports, the protocol (TCP, UDP, ICMP, etc.), and more. If a packet matches the criteria specified in a rule, the rule’s associated action (also known as the “target”) is executed. Common targets include:
- ACCEPT: Allow the packet to pass through and continue on its journey.
- DROP: Block the packet from passing through and do not send any response.
- REJECT: Block the packet from passing through but send an error response to the sender.
- LOG: Log the packet details according to the kernel logging configuration and then continue processing more rules in the chain.
If a packet does not match any rule in a chain, the default policy of the chain (ACCEPT, DROP, or REJECT) is applied to the packet.
How It Works:
When a packet enters the network interface, it is processed by the iptables rules in the order they appear in the chain. As soon as a rule matches the packet, the rule’s specified action is taken, and depending on the action, the packet may either continue to the next rule or chain, or the processing may stop.
For example, an incoming packet will first go through the PREROUTING chain of the mangle and then nat tables (if applicable), then through the INPUT chain of the filter table. If it’s destined for another host and just being routed through the system, it would go through the FORWARD chain instead. Outgoing packets go through the OUTPUT and then the POSTROUTING chain.
Through this system of tables, chains, and rules, iptables provides a powerful and flexible framework for defining how packets are handled by the system.
In below example, we are dropping http packets:
manojkumar@n36-186-058:~$ sudo iptables -A INPUT -p tcp --dport 80 -j DROP