Massive thanks to @Joseinnewworld for adding another 22 #NFTs to his collection! 🙌 Our collection is now almost sold out — what a journey! From here on, I’ll be shifting my focus more on developing the system rather than producing new #NFT. Exciting times ahead 🚀 #eCash $XEC pic.twitter.com/O7dQlr0OtG
— NFToa (@nftoa_) October 8, 2025
Shoreline Firewall, better known as "Shorewall", is a high-level tool for configuring Netfilter. We can describe the firewall/gateway requirements using a set of configuration files. Shorewall reads those configuration files with the help of iptables. Shorewall configures Netfilter to suit our needs. Shorewall can be used on a dedicated system, a multifunction gateway/router/server or on a standalone linux.
Shorewall does not use Netfilter's ipchain compatible mode and can take advantage of Netfilter's connection state tracking capabilities.
Shorewall is not a daemon. Shorewall's job is complete when Netfilter is configured. After that, no shorewall code is executed, although the /sbin/shorewall program can be used at any time to monitor the Netfilter firewall. Shorewall is not the easiest iptables configuration tool to use, but it is the most flexible and powerful.
Before we discuss shorewalls, there are several terms we should know, including:
- Netfilter - Packet filter facility used in Linux kernel 2.4 and later.
- IPchains - Packet filter facility used in Linux kernel 2.2. Also a program used to configure and manage the facility. Netfilter can be used in compatible mode
- IPchainsiptables - a program used to configure and control Netfilter. The term 'iptables' is often used in combination of iptables+Netfilter.
1. Netfilter and Iptables
Netfilter is one of the devices in the Linux kernel that provides a core module for registering callback functions with a network stack. Registering callback functions is a recall of each data packet transferred without a network stack.
Iptables is a general table structure for rulesets. In each IP table there must be a number grouping (iptables matches) and one connection (iptables target). Netfilter, ip_tables, connection tracking (ip_conntrack, nf_conntrack) and the NAT subsystem are the main parts of the framework.
The functions of netfilter and iptables are:
- Building an internet firewall on stateless and stateful packet filtering.
- Can use NAT and masquerading to share internet access if we do not have a public IP address.
- Can use NAT for proxy implementation.
- Assisted tc and iproute2 systems in creating sophisticated QoS and router rules.
- Manipulating subsequent packets (mangling) such as changing the TOS/DSCP/ECN bits on the main IP.
Netfilter consists of three tables, namely: Filter, Nat and Mangle, where each table has the following order: PREROUTING, INPUT, FORWARD, OUTPUT and POSTROUTING.
Filter is a filtering package used to reject, output and receive data packets.
NAT is Network Address Translation which consists of DNAT, SNAT and Masquerading.
Mangle is a general packet modification such as setting TOS values or packet codes for routing rules and traffic shaping.
Below is a diagram of how data packets are sent with the builder circuit without Netfilter.
Figure 6.12. Diagram of Data Packets Sent with Builder Circuit Without Netfilter
Note: Not all of the contents of the table are used, depending on the contents of the usage. “Local Process” means the process that is run on the shorewall system itself.
In the box above, the name of the building block (INPUT) is given which is related to the table name (Mangle and Filter). Where the existing block and the command from the block are transferred. The example above shows that the first packet goes entirely to the INPUT block in the Mangle table and then to the INPUT block in the Filter table. When the block is closed, Shorewall does not use the (INPUT) block in the (Mangle) table.
Note: The strings in the Nat table are only transferred for new connection requests (related to persistent connections) while the strings in other tables are transferred on a packet-by-packet basis. The rule suggests that all traffic destinations for the firewall originate from the firewall on eth0 called "eth0_in". As in the example below.
Example of shorewall status on a server with interface (eth0):
[root@lists html]# shorewall status
Shorewall-1.4.7 Status at lists.shorewall.net - Mon Oct 13 12:51:13 PDT 2003
Counters reset Sat Oct 11 08:12:57 PDT 20031.1 The first table that appears is the Filter table.
Chain INPUT (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
679K 182M ACCEPT all -- lo * 0.0.0.0/0
0.0.0.0/0
785K 93M accounting all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0
0.0.0.0/0 state INVALIDAccording to the rules it shows that all traffic destination for the firewall comes from the firewall on eth0 called "eth0_in". The sequence will be shown further.
785K 93M eth0_in all -- eth0 * 0.0.0.0/0
0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 LOG flags 0 level 6 prefix `Shorewall:INPUT:REJECT:'
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
Chain FORWARD (policy DROP 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
0 0 accounting all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID
0 0 eth0_fwd all -- eth0 * 0.0.0.0/0
0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 LOG flags 0 level 6 prefix
`Shorewall:FORWARD:REJECT:'
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0
Chain OUTPUT (policy DROP 1 packets, 60 bytes)
pkts bytes target prot opt in out source destination
679K 182M ACCEPT all -- * lo 0.0.0.0/0
0.0.0.0/0
922K 618M accounting all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 DROP !icmp -- * * 0.0.0.0/0
0.0.0.0/0 state INVALID
922K 618M fw2net all -- * eth0 0.0.0.0/0
0.0.0.0/0
0 0 common all -- * * 0.0.0.0/0
0.0.0.0/0
0 0 LOG all -- * * 0.0.0.0/0
0.0.0.0/0 LOG flags 0 level 6 prefix
`Shorewall:OUTPUT:REJECT:'
0 0 reject all -- * * 0.0.0.0/0 0.0.0.0/0Below is the sequence from eth0_in:
Chain eth0_in (1 references)
pkts bytes target prot opt in out source destination
785K 93M dynamic all -- * * 0.0.0.0/0
0.0.0.0/0
785K 93M net2fw all -- * * 0.0.0.0/0
0.0.0.0/01.2 Then NAT Table
Nat table
Chain PREROUTING (policy ACCEPT 182K packets, 12M bytes)
pkts bytes target prot opt in out source destination
20005 1314K net_dnat all -- eth0 * 0.0.0.0/0
0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 678K packets, 44M bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 678K packets, 44M bytes)
pkts bytes target prot opt in out source destination
Chain net_dnat (1 references)
pkts bytes target prot opt in out source destination
638 32968 REDIRECT tcp -- * * 0.0.0.0/0
!206.124.146.177 tcp dpt:80 redir ports 31281.3 The Last Mangle Table
Mangle Table
Chain PREROUTING (policy ACCEPT 14M packets, 2403M bytes)
pkts bytes target prot opt in out source destination
1464K 275M pretos all -- * * 0.0.0.0/0
0.0.0.0/0
Chain INPUT (policy ACCEPT 14M packets, 2403M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 15M packets, 7188M bytes)
pkts bytes target prot opt in out source destination
1601K 800M outtos all -- * * 0.0.0.0/0
0.0.0.0/0
Chain POSTROUTING (policy ACCEPT 15M packets, 7188M bytes)
pkts bytes target prot opt in out source destination
Chain outtos (1 references)
pkts bytes target prot opt in out source destination
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:22 TOS set 0x10
315K 311M TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:22 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:21 TOS set 0x10
683 59143 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:21 TOS set 0x10
3667 5357K TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:20 TOS set 0x08
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:20 TOS set 0x08
Chain pretos (1 references)
pkts bytes target prot opt in out source destination
271K 15M TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:22 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:22 TOS set 0x10
730 41538 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp dpt:21 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:21 TOS set 0x10
0 0 TOS tcp -- * * 0.0.0.0/0
0.0.0.0/0 tcp spt:20 TOS set 0x08
2065 111K TOS tcp -- * * 0.0.0.0/0
0.0.0.0/02. Shorewall Concept
The configuration file for Shorewall is placed in the /etc/shorewall directory. Shorewall is like a network that works with a set of zones. Zones are placed in the /etc/shorewall/zones file. This file is to define the origin zone of traffic on the network.
Contents of the file /etc/shorewall/zone
#ZONE DISPLAY COMMENTS
net Net Internet
loc Local Local networks
dmz Dmz Demilitarized zone
#LAST LINE -- ADD YOUR ENTRIES BEFORE THIS ONE -- DO NOT REMOVEThe server where the shorewall is installed is known as a zone called fw.
The rules about what traffic is accepted and what traffic is rejected are related to zones.
We provide the default policy for connections from one zone to another in the /etc/shorewall/policy file. Some of the options in the policy are:
- ACCEPT -- Accept the connection
- DROP -- Ignore connection request
- REJECT -- Returns an error on the connection request.
We describe the rules in general in the /etc/shorewall/rules file.
We only need a connection request. We don't have to describe the rules for how traffic is part of the connection establishment, and in some cases we don't need to worry about how the associated connections are handled (ICMP error packets and TCP connection requests as used in FTP).
For all traffic passing through the firewall is set in /etc/shorewall/rules, if it is not defined in that file then it will be checked in /etc/shorewall/policy if it is not defined it will be checked in /etc/shorewall/action/usr/share/shorewall/actions.std.
Example of a rule in the /etc/shorewall/policy file that has three interfaces:
If we want the firewall system to be able to access the internet fully, we change the command as below:
The above policy will:
- Allows all connection requests from our local network to the internet.
- Ignore all connection requests from the internet to the local network or firewall; if a connection is dropped, the log level is filled with info
- Accept all connections from the firewall to the internet (if there are no comments in the policy).
- Reject all connections; if the connection is rejected at the log level, the info /etc/shorewall/interface is filled in.
This file is to determine the interface that will be connected to a zone.
The file above means that eth0 is connected to the internet network, eth1 is connected to the local network, and eth2 is connected to the demilitarized zone.
To illustrate how the policy provides an exception, for example if we have the policy but we cannot connect to the firewall from the internet using Secure Shell (SSH), even though SSH connects to TCP port 22.
So even if we have a policy to ignore all connections to the internet, we still need to connect to the SSH server on our firewall.
What is a Firewall?
The initial mission of the Internet was as a non-profit communication network. Initially, the Internet was designed without regard to the business world. Then this became a problem now and in the future. With the increasing number of Internet users, both information seekers and information providers, several problems have arisen, including security issues and the increasing need for addressing on the Internet. It is the task of the network operator concerned to minimize these risks. The selection of strategies and the skills of the network administrator will greatly differentiate whether a network is easily penetrated or not. For security issues, a Firewall is one of the tools that can be used to implement a security policy. Meanwhile, security policies are made based on a balance between the facilities provided and their security implications. The tighter the security policy, the more complex the configuration of information services or the fewer facilities available on the network. Conversely, with the increasing number of facilities available or the simple configuration applied, the easier it is for 'nosy' people from outside to enter the system (a direct result of weak security policies). Meanwhile, the problem of limited addressing for the Internet can be overcome by using NAT. The simple logic for saving IP addresses is to share a valid IP address number to several other IP clients. Or in other words, several computers can access the Internet even though we only have one valid IP address. One of these mechanisms is provided by Network Address Translation (NAT).
1. Understanding Firewalls
The Internet is a very open computer network in the world, the consequence that must be borne is that there is no guarantee of security for networks connected to the Internet. Firewall [1] is a method or mechanism that is applied to hardware, software or the system itself with the aim of protecting, either by filtering, limiting or even rejecting one or all relationships/activities of a segment on a private network with an external network that is not within its scope.
Figure 6.1 Firewall configuration
Firewalls are generally intended to serve:
- Machines/Computers. Any machine/computer that is directly connected to an external network or the internet and wants everything on the computer to be protected.
- Network. A computer network consisting of more than one computer and various types of network topologies used, whether owned by a company, organization, etc.
2. Characteristics of a Firewall
- All relationships/activities from inside to outside, must pass through the firewall. This can be done by physically blocking/limiting all access to the Local network, except through the firewall.
- Only registered/known activities can pass/make connections, this can be done by setting policies in the local security configuration. There are many types of firewalls to choose from as well as various types of policies offered.
- The firewall itself must be immune or relatively strong against attacks/weaknesses. This means using a system that can be trusted and with a relatively safe system.
3. Techniques Used by Firewalls
3.1 Service control (control over services)
Based on the types of services used on the Internet and can be accessed either in or out of the firewall. Usually the firewall will check the IP Address number and also the port number used in both TCP and UDP protocols, and can even be equipped with software for a proxy that will receive and translate every request for a service before allowing it. It could even be software on the server itself, such as services for the web or for mail.
Figure 6.2. Service Control
3.2 Direction Conrol (control over direction)
Based on the direction of various requests for services that will be recognized and allowed to pass through the firewall.
Figure 6.3. Direction Control
3.3 User control (control over users)
Based on the user to be able to run a service, meaning there are users who can and some who cannot run a service, because the user is not allowed to pass through the firewall. Usually used to limit users from the local network to access outside, but can also be applied to limit users from outside.
Figure 6.4. User Control
3.4 Behavior Control (control over treatment)
Based on how much the service has been used. For example, a firewall can filter email to combat/prevent spam.
Figure 6.5. Behavior Control
4. Types of Firewalls
4.1 Packet Filtering Router
Applied by setting all IP packets that are headed, passed or will be headed by the packet. In this type, the packet will be set whether to be accepted and forwarded or rejected.
Excess:
Easy to implement, transparent to users, relatively faster.
Weakness:
It is quite complicated to set up packets to be filtered properly, Weak in terms of authentication.
Figure 6.6. Packet Filtering Router
4.2 Application-Level Gateway
Serves to strengthen/channel application flow. This type will manage all relationships that use the application layer, be it FTP, HTTP, GOPHER etc.
How it works: if a user uses an application such as FTP to access remotely, the gateway will ask the user to enter the address of the remote host to be accessed. When the user sends the user ID and other appropriate information, the gateway will connect to the application on the remote host, and channel data between the two points. If the data does not match, the firewall will not forward the data or reject it. Furthermore, in this type of Firewall can be configured to only support a few applications and reject other applications from passing through the firewall.
Excess:
Relatively safer than the packet filtering type, routers are easier to check (audit) and log all incoming data flows at the application level.
Lack:
Excessive additional processing on each relationship. which will result in two connections between the user and the gateway, where the gateway will check and forward all flows from both directions.
Figure 6.7. Application-Level Gateway
4.3. Circuit-level Gateway
This third type can be a stand-alone system, or it can also be a special function formed from the application-level gateway type. This type does not allow end-to-end (direct) TCP connections.
How it works: The gateway will manage both TCP connections, 1 between itself (me) and TCP on the local user (inner host) and 1 more between itself (me) and TCP on the outside user (outside host). When two connections are implemented, the gateway will channel TCP segments from one connection to the other without checking its contents. Its security function lies in determining which connections are allowed. The use of this type is usually because the administrator trusts internal users.
Figure 6.8 Circuit-Level Gateway