Linux with Operating System Concepts

Module
Meaning
Extensions
addrtype
Match based on source address 
type
or destination address 
type
--src-type 
type
--dst-type 
type
Types include BLACKHOLE, 
BROADCAST, MULTICAST, NAT, and 
UNICAST
conntrack
Match based on the connection’s 
status
--ctstate 
state
States include
INVALID, ESTABLISHED, NEW, 
RELATED, SNAT, and DNAT
icmp
Match based on ICMP type
--icmp-type [!] 
type
Type can be any ICMP type or its 
corresponding number
iprange
Match if message’s source or 
destination falls within the given 
range
[!]--src-range 
range
[!]--dst-range 
range
Range denoted as 
address1
-
address2
length
Match if message’s length is equal 
to, or within the range, provided
--length [!] 
length
[:
length
]
Examples:
--length 500:1000
--length ! 0
limit
Limit the number of received 
messages
--limit-burst 
number
time
Match if specified time is met
--timestart 
value
--timestop 
value
--days 
days
--datestop 
days
value
is a time given in hh:mm format and 
days
is Monday, Tuesday, Wednesday, and 
so on

---

Network Configuration
◾
515
Aside from -A rules, you can also specify -P, -F, and -L rules. The -P rules are default 
rules. These will be applied if the current chain being followed exhausts its list of rules. For 
instance
–P INPUT REJECT
states that if no INPUT rule matches, then reject the message. The -F rules are used to flush 
all existing rules so that we start with a new set of -A rules. You might use -F if you are 
rewriting rules from the command line, or as the first rule in iptables. The -L rules are used 
to list all the rules in the firewall. You would typically only use -L from the command line 
and you would also more commonly use -F from the command line.
As noted above, aside from editing the iptables file itself, you can issue changes to the 
firewall rules from the command line through the 
iptables
command. This would 
look like any rule in iptables except that you enter it at the command line, preceded by 
the word 
iptables
. For instance, to add the rule INPUT -i eth0 -p udp -j ACCEPT, you 
would enter
iptables –A INPUT –i eth0 –p udp –j ACCEPT
With iptables, you could then flush the entire set of rules in the firewall with 
iptables -F
.
12.6.3 Examples of Firewall Rules
Here, we will examine a basic set of rules that we might find in an iptables file and explore 
what the rules mean. Each rule is explained in comments following the rule.
–P INPUT REJECT 
# default for incoming packets
–P OUTPUT ACCEPT 
# allow all outgoing messages
–P FORWARD DROP 
# do not perform forwarding
Forwarding is commonly used for routers, not workstations.
–A INPUT –i lo –j ACCEPT 
# accept anything over “lo”
–A INPUT –p tcp -dport 22 –j ACCEPT
# 
accept 
incoming 
ssh
–A INPUT –m state -state ESTABLISHED,RELATED –j ACCEPT
# 
accept 
messages 
that 
are
# 
continuations 
of 
previously
# 
established 
connections
–A INPUT –p icmp –j ACCEPT 
# accept ICMP messages
–A INPUT –i eth0 –s 10.11.12.0/24 –j ACCEPT
# 
accept 
messages 
from
# 
subnet 
10.11.12.0
–A INPUT –p tcp –s facebook.com -sports 80, 443 –j DROP
# 
drop 
webpage 
responses 
from
# 
facebook.com

---

516
◾
Linux with Operating System Concepts
The idea behind the above rules is to accept any incoming message that fits the given 
criteria with the exception of the last entry, which drops the message. However, our very 
first rule establishes the default, which is to reject any incoming message that does not pass 
any of the accept rules. Why therefore do we need a separate rule to drop Facebook mes-
sages? The answer is based on the different action that takes place. By default, we REJECT 
messages, but the Facebook message is DROPped. You might recall earlier that a REJECT 
action will notify the sender that the message was received. With a DROP action, we do 
not respond to the sender.
Let us consider another situation. We are not explicitly accepting messages over port 
80, which is HTTP. How then is the user able to view web pages? The answer comes 
from the third rule that deals with an ESTABLISHED state. The above –A rules are all 
INPUT rules. We saw that all OUTPUT messages are automatically ACCEPTed via the 
–P default rule. Therefore, the user is free to send out messages without the firewall stop-
ping them.
For an HTTP interaction, it is the user who initiates the process (either by entering a 
URL in a web browser’s address box or clicking on a link in the web browser’s current web 
page). This action results in an outgoing HTTP message sent to a web server. In doing so, 
this establishes a connection with the server so that the state becomes ESTABLISHed. Any 
response from the web server is of an already ESTABLISHed (or possibly RELATEd) mes-
sage. So, the state of the incoming message from the web server has a state acceptable by 
our 
–m state
rule. In fact, until the connection is ended (at our end) or times out, the 
state remains ESTABLISHED.
On the other hand, we are not allowed to receive HTTP requests as the only protocols 
that we accept are tcp over port 22 and icmp. This is fine if we are not running a web server 
as any incoming HTTP requests would be nonsense. If we do decide to run our own web 
server, we would need to add rules to permit messages from port 80 and quite possibly 
other related ports like 8080 and 443. The following might be added to permit HTTP and 
HTTPS requests:
–A INPUT –p tcp –m multiport -dports 80,8080,443
–m state -state NEW,ESTABLISHED –j ACCEPT
This rule states that incoming TCP packets over any of the ports 80, 8080, or 443 that 
have either a NEW or ESTABLISHED state are accepted.
We might want to further refine this or other rules if we are worried that HTTP requests 
could cause us damage. One example is to add unwanted IP addresses to a list of REJECT 
or DROP actions. For instance, let us assume that we have received several denial of ser-
vice attacks from the subnet 1.80.0.0/13. We might then add the following rule that should 
be placed earlier than the ACCEPT rules to ensure that this rule triggers; otherwise, an 
ACCEPT rule might trigger and the INPUT chain would be followed no further so that the 
firewall would not reach this rule.
-A INPUT –s 1.80.0.0/13 –j DROP

---

Network Configuration
◾
517
Another way to prevent possible denial of service attacks is to restrict the number of 
incoming messages permissible from any one source. We could add the following rule 
so that there is a limit to the number of accepted messages per minute or per established 
connection.
–A INPUT –p tcp –m multiport -dports 80,443 –m limit
-limit 25/minute -limit-burst 100 –j ACCEPT
The remaining ACCEPT rules in our earlier example will permit access into our com-
puter over the lo interface, port 22 (using ssh), messages using the icmp protocol (both 
ping and traceroute use this), and anything from the 10.11.12.0 subnet that arrives over the 
Ethernet card.
By permitting icmp messages, we open ourselves up to possible reconnaissance attacks. 
Through ping, a potential attacker could identify IP addresses in a network. While we do 
not necessarily want to stop all incoming icmp traffic, we might want to discourage ping 
and traceroute queries. To accomplish this, we might add the following two rules. The first 
rule states that incoming ping/traceroute requests will be dropped while the second rule 
states that outgoing ping/traceroute responses will be dropped.
–A INPUT –p icmp -icmp-type echo-request –j DROP
–A OUTPUT –p icmp -icmp-type echo-reply –j DROP
Finally, we might set up explicit logging rules. We could define our own chain, rather 
than the preestablished INPUT, OUTPUT, and FORWARD chains. For instance, –N 
LOGGING will define a new set of rules under the chain LOGGING. We then add (-A) 
rules to this chain, for instance:
-A LOGGING --log-level 7 -j LOG
-A LOG -j DROP
These rules state that anything to be dropped should also be logged at log level 7 (the num-
ber 7 is used by syslog).
As stated earlier, we could modify our firewall by issuing these commands from the 
command line. If we do this, then the new rules are available now, but unfortunately, not 
the next time we reboot the computer. To save the changes entered at the command line, 
you can issue the instruction 
/sbin/iptables-save
. Alternatively, you can directly 
edit the iptables file (
/etc/sysconfig/iptables
) in vi and save the results. Once 
done, restart the iptables service.
12.7 WRITING YOUR OWN NETWORK SCRIPTS
As with any aspect of Linux, there are gaps in the operating system that you can fill by writ-
ing your own scripts. This section is meant to convey some possible scripts. It would be up 
to you to determine what you might need and implement them. We will examine several 
ideas for scripts. Each of these scripts will be written using the Bash scripting language.

---

518
◾
Linux with Operating System Concepts
12.7.1 A Script to Test Network Resource Response
Our first script will test to see if a given network resource is responding. We will test the 
resource with ping. The command 
ping