Firewall Setup & Rules

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 
These are few Firewall Rules.

# 1. Delete all existing rules
iptables -F

# 2. Set default chain policies
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT DROP
iptables -t nat -A POSTROUTING -j MASQUERADE (Command to share Internet to all network)

# 3. Block a specific ip-address
#BLOCK_THIS_IP=”x.x.x.x”
#iptables -A INPUT -s “$BLOCK_THIS_IP” -j DROP

# 4. Allow ALL incoming SSH
#iptables -A INPUT -i eth0 -p tcp –dport 22 -m state –state NEW,ESTABLISHED -j ACCEPT
#iptables -A OUTPUT -o eth0 -p tcp –sport 22 -m state –state ESTABLISHED -j ACCEPT

# 5. Allow incoming SSH only from a sepcific network
#iptables -A INPUT -i eth0 -p tcp -s 192.168.200.0/24 –dport 22 -m state –state NEW,ESTABLISHED -j ACCEPT
#iptables -A OUTPUT -o eth0 -p tcp –sport 22 -m state –state ESTABLISHED -j ACCEPT

# 6. Allow incoming HTTP
#iptables -A INPUT -i eth0 -p tcp –dport 80 -m state –state NEW,ESTABLISHED -j ACCEPT
#iptables -A OUTPUT -o eth0 -p tcp –sport 80 -m state –state ESTABLISHED -j ACCEPT

# Allow incoming HTTPS
#iptables -A INPUT -i eth0 -p tcp –dport 443 -m state –state NEW,ESTABLISHED -j ACCEPT
#iptables -A OUTPUT -o eth0 -p tcp –sport 443 -m state –state ESTABLISHED -j ACCEPT

# 7. MultiPorts (Allow incoming SSH, HTTP, and HTTPS)
iptables -A INPUT -i eth0 -p tcp -m multiport –dports 22,80,443 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp -m multiport –sports 22,80,443 -m state –state ESTABLISHED -j ACCEPT

# 8. Allow outgoing SSH
iptables -A OUTPUT -o eth0 -p tcp –dport 22 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp –sport 22 -m state –state ESTABLISHED -j ACCEPT

# 9. Allow outgoing SSH only to a specific network
#iptables -A OUTPUT -o eth0 -p tcp -d 192.168.101.0/24 –dport 22 -m state –state NEW,ESTABLISHED -j ACCEPT
#iptables -A INPUT -i eth0 -p tcp –sport 22 -m state –state ESTABLISHED -j ACCEPT

# 10. Allow outgoing HTTPS
iptables -A OUTPUT -o eth0 -p tcp –dport 443 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A INPUT -i eth0 -p tcp –sport 443 -m state –state ESTABLISHED -j ACCEPT

# 11. Load balance incoming HTTPS traffic
#iptables -A PREROUTING -i eth0 -p tcp –dport 443 -m state –state NEW -m nth –counter 0 –every 3 –packet 0 -j DNAT –to-destination 192.168.1.101:443
#iptables -A PREROUTING -i eth0 -p tcp –dport 443 -m state –state NEW -m nth –counter 0 –every 3 –packet 1 -j DNAT –to-destination 192.168.1.102:443
#iptables -A PREROUTING -i eth0 -p tcp –dport 443 -m state –state NEW -m nth –counter 0 –every 3 –packet 2 -j DNAT –to-destination 192.168.1.103:443

# 12. Ping from inside to outside
iptables -A OUTPUT -p icmp –icmp-type echo-request -j ACCEPT
iptables -A INPUT -p icmp –icmp-type echo-reply -j ACCEPT

# 13. Ping from outside to inside
iptables -A INPUT -p icmp –icmp-type echo-request -j ACCEPT
iptables -A OUTPUT -p icmp –icmp-type echo-reply -j ACCEPT

# 14. Allow loopback access
iptables -A INPUT -i lo -j ACCEPT
iptables -A OUTPUT -o lo -j ACCEPT

# 15. Allow packets from internal network to reach external network.
# if eth1 is connected to external network (internet)
# if eth0 is connected to internal network (192.168.1.x)
iptables -A FORWARD -i eth0 -o eth1 -j ACCEPT

# 16. Allow outbound DNS
#iptables -A OUTPUT -p udp -o eth0 –dport 53 -j ACCEPT
#iptables -A INPUT -p udp -i eth0 –sport 53 -j ACCEPT

# 17. Allow NIS Connections
# rpcinfo -p | grep ypbind ; This port is 853 and 850
#iptables -A INPUT -p tcp –dport 111 -j ACCEPT
#iptables -A INPUT -p udp –dport 111 -j ACCEPT
#iptables -A INPUT -p tcp –dport 853 -j ACCEPT
#iptables -A INPUT -p udp –dport 853 -j ACCEPT
#iptables -A INPUT -p tcp –dport 850 -j ACCEPT
#iptables -A INPUT -p udp –dport 850 -j ACCEPT

# 18. Allow rsync from a specific network
iptables -A INPUT -i eth0 -p tcp -s 192.168.101.0/24 –dport 873 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 873 -m state –state ESTABLISHED -j ACCEPT

# 19. Allow MySQL connection only from a specific network
iptables -A INPUT -i eth0 -p tcp -s 192.168.200.0/24 –dport 3306 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 3306 -m state –state ESTABLISHED -j ACCEPT

# 20. Allow Sendmail or Postfix
iptables -A INPUT -i eth0 -p tcp –dport 25 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 25 -m state –state ESTABLISHED -j ACCEPT

# 21. Allow IMAP and IMAPS
iptables -A INPUT -i eth0 -p tcp –dport 143 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 143 -m state –state ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth0 -p tcp –dport 993 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 993 -m state –state ESTABLISHED -j ACCEPT

# 22. Allow POP3 and POP3S
iptables -A INPUT -i eth0 -p tcp –dport 110 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 110 -m state –state ESTABLISHED -j ACCEPT

iptables -A INPUT -i eth0 -p tcp –dport 995 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 995 -m state –state ESTABLISHED -j ACCEPT

# 23. Prevent DoS attack
iptables -A INPUT -p tcp –dport 80 -m limit –limit 25/minute –limit-burst 100 -j ACCEPT

# 24. Port forwarding 422 to 22
iptables -t nat -A PREROUTING -p tcp -d 192.168.102.37 –dport 422 -j DNAT –to 192.168.102.37:22
iptables -A INPUT -i eth0 -p tcp –dport 422 -m state –state NEW,ESTABLISHED -j ACCEPT
iptables -A OUTPUT -o eth0 -p tcp –sport 422 -m state –state ESTABLISHED -j ACCEPT

# 25. Log dropped packets
iptables -N LOGGING
iptables -A INPUT -j LOGGING
iptables -A LOGGING -m limit –limit 2/min -j LOG –log-prefix “IPTables Packet Dropped: ” –log-level 7
iptables -A LOGGING -j DROP

 

……………………………………………………………………………….

 
IPTABLES Firewall Example (you are here)
IPCHAINS Firewall Example

 

# I save this file as /etc/sysconfig/iptables-precursor
# and then source it and run iptables-save to create
# /etc/sysconfig/iptables, which is an input file
# consumed by the script /etc/rc.d/init.d/iptables,
# which in turn makes use of the script /sbin/iptables-restore.
#
# Before mucking with setting up iptables, you should
# disconnect the machine from the internet. Examine
# and understand the current set of iptables rules
# before you reconnect to the internet.
#
# To configure the set of iptables rules:
#
# /etc/rc.d/init.d/iptables stop
# source /etc/sysconfig/iptables-precursor
#
# To save the current set of iptables rules for use at next reboot:
#
# iptables-save > /etc/sysconfig/iptables
#
# To dynamically restart iptables after modifying /etc/sysconfig/iptables:
#
# /etc/rc.d/init.d/iptables restart
#
# Note that /etc/rc.d/init.d/iptables is a script. You can read it to
# gain understanding of how iptables uses iptables-restore to restore
# iptables firewall rules at reboot.
#
# To examine the current set of rules in effect:
#
# /etc/rc.d/init.d/iptables status
#
# However, I prefer to show the current set of rules via:
#
# iptables -nvL -t filter
# iptables -nvL -t nat
#
# or
#
# iptables -vL -t filter
# iptables -vL -t nat
#
#
# To configure iptables to be used at next system reboot:
#
# chkconfig –add iptables
#
# To see if iptables is currently configured to start at boot, do:
#
# chkconfig –list iptables
#
# (You might have to do chkconfig –del ipchains to remove ipchains)
#
# The rest of this file is derived from my old ipchains script.
#

# A word about routing
# ——————–
#
# Note that this web page does not discuss routing decisions. Routing
# (see the ‘ifconfig’ and ‘route’ commands) decides which interface an
# incoming packet will be delivered to, i.e. if a given packet will be
# ‘input’ to this machine or be ‘forwarded’ to some interface for
# delivery to another machine, say on an internal network. You should
# have your routing configured before you attempt to configure your
# firewall.
#
# Caveat. DNAT and SNAT provide a way for the IPTABLES firewall to modify the
# Destination or Source IP addresses of a packet and, in this way, interact
# with routing decisions. See section below: ‘More about NAT and routing’.
#

# The network
# ———–
#
# This firewall is running on a gateway machine having multiple ethernet
# interfaces, a public one, eth0, which is a DSL connection to an ISP,
# and one or more internal ones, including eth1, which is assigned to
# 192.168.0.1, an IP number on my internal private network. My public
# network has static IP numbers depicted below as x.y.z…. Actual
# IP numbers would, of course, be a sequence of four octets. For this
# script, I assume that the firewall is running on the same machine
# having the interfaces configued with my public IPs. For this reason,
# most of the rules below are INPUT rules. Were I to route some of my public
# static IP numbers to interfaces on one or more machines inside the
# firewall on the internal network, I would modify certain rules to be
# FORWARD rules instead of INPUT rules. I show some examples below of
# FORWARD rules. Finally, the script is just for a single server IP,
# hence all of the “/32” network masks below. A more realistic situation
# would involve using IP ranges and their corresponding network masks.
#
# The gateway at my ISP is x.y.z.1. I run a few web servers on
# x.y.z.w, a DNS server on x.y.z.n, and qmail on x.y.z.m.
#
# Using this file in a more complex network would require some
# modifications. Particular attention would need to be given to using
# the right the IP numbers and interfaces, among other things. 🙂
#

# Preliminaries
# ————-
#
# To permit machines internal to the network to be able to
# send IP packets to the outside world, enable IP Forwarding:
#
# echo 1 > /proc/sys/net/ipv4/ip_forward
#
# Prevent SYN floods from consuming memory resources:
#
# echo 1 > /proc/sys/net/ipv4/tcp_syncookies
#
# I place the above echo commands into /etc/rc.d/rc.local
# so that they will be executed at boot time.
#
# The basic idea of this firewall
# ——————————-
#
# Provide rules that are applied in the following order:
#
# ACCEPT all UDP packets for certain UDP services
#
# Currently the only UDP connections I accept are to my secure DNS
# server, tinydns. For an explanation of why tinydns is secure, see:
# http://www.faqts.com/knowledge_base/view.phtml/aid/8739/fid/699.
#
# DENY all other UDP packets.
#
# ACCEPT SYN packets just for certain TCP services
#
# SYN packets are specified via the -syn flag in the input
# rules defined below. Note that certain services can be
# further filtered by xinetd.
#
# DENY all other TCP SYN packets.
#
# ACCEPT all other TCP packets that are part of existing connections
#
# DENY all other TCP packets.
#
# In other words, we allow any TCP packet through that is part of an
# established TCP connection, but we are very selective in just which
# connections we permit to be made to start off with.
#
# A brief explanation of SYN packets goes as follows. TCP connections
# are initiated via a hand shaking protocol between the client and server
# programs at either end of the connection. The very first TCP packet
# is sent by the client to the server and is called a SYN packet,
# because it has the SYN flag set to 1 in the TCP packet header. We
# only allow SYN packets for the specific servers running on specific
# ports of specific hosts. Subsequently, we only permit further TCP
# packets in that are determined to be part of a connection whose
# initial SYN packet was already accepted and responded to by one of our
# servers. This is done via ‘Stateful Packet Inspection’ provided by the
# netfilter functionality added to linux as of kernel 2.4. By stopping all
# other packets in their tracks, we limit attempts to attack our internal
# network.
#
# There are subtle ways that Denial of Service attacks can be performed
# if an attacker is able to somehow gain access to a machine inside our
# network or otherwise hijack a connection. However, even in such
# cases, current research is leading to ways to greatly limit the effect
# of such attacks. For further reading, see: http://www.cs3-inc.com/ddos.html.
#
# For detailed background reading about iptables, please refer to:
# http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO.html
#
# begin oceanpark.com firewall rules (using iptables)
# —————————————————

# Here we go…

#
# Configure default policies (-P), meaning default rule to apply if no
# more specific rule below is applicable. These rules apply if a more specific rule below
# is not applicable. Defaults are to DROP anything sent to firewall or internal
# network, permit anything going out.
#
iptables -P INPUT DROP
iptables -P FORWARD DROP
iptables -P OUTPUT ACCEPT

#
# Flush (-F) all specific rules
#
iptables -F INPUT
iptables -F FORWARD
iptables -F OUTPUT
iptables -F -t nat
# The rest of this file contains specific rules that are applied in the order
# listed. If none applies, then the above policy rules are used.

#
# Forward all packets from eth1 (internal network) to eth0 (the internet).
#
iptables -A FORWARD -i eth1 -o eth0 -j ACCEPT

#
# Forward packets that are part of existing and related connections from eth0 to eth1.
#
iptables -A FORWARD -i eth0 -o eth1 -m state –state ESTABLISHED,RELATED -j ACCEPT

#
# Permit packets in to firewall itself that are part of existing and related connections.
#
iptables -A INPUT -i eth0 -m state –state ESTABLISHED,RELATED -j ACCEPT

# Note, in the above two rules, a connection becomes ESTABLISHED in the
# iptables PREROUTING chain upon receipt of a SYNACK packet that is a
# response to a previously sent SYN packet. The SYNACK packet itself is
# considered to be part of the established connection, so no special
# rule is needed to allow the SYNACK packet itself.

#
# Allow all inputs to firewall from the internal network and local interfaces
#
iptables -A INPUT -i eth1 -s 0/0 -d 0/0 -j ACCEPT
iptables -A INPUT -i lo -s 0/0 -d 0/0 -j ACCEPT
#
# Enable SNAT functionality on eth0
#
# SNAT (Source NAT) is used to map private source IP numbers of
# interfaces on the internal LAN to one of my public static IP numbers.
# SNAT performs this mapping when a client running on one of the
# internal hosts (x.y.z.c) initiates a TCP connection (SYN) through
# eth0.
#
iptables -A POSTROUTING -t nat -s 192.168.0.0/24 -o eth0 -j SNAT –to-source x.y.z.c

#
# Alternative to SNAT — MASQUERADE
#
# If your firewall has a dynamic IP number because it connects to the
# internet itself via DHCP, then you probably cannot predict what the IP
# number is of your firewall’s interface connected to the internet. In
# this case, you need a rule like the following that assigns the (an) IP
# number associated with eth0 to outgoing connections without you needing
# to know in advance (at time of writing this rule) what that IP number is:
#
# iptables -A POSTROUTING -t nat -o eth0 -j MASQUERADE
#
# Note that the above SNAT and MASQUERADE rules are applicable
# independent of how a host on the internal network is assigned its own
# internal IP number. The host could be assigned a static IP number on
# an internal nonpublic network (e.g. 10. or 192.168.) or it could be
# itself assigned a dynamic IP number from your own DHCP server running
# on the firewall, or it could even have a public static IP number.
# However, it seems unlikely that one would want to assign a public IP
# number to a host and then proceed to hide that number from the public.
#

#
# Deny any packet coming in on the public internet interface eth0
# which has a spoofed source address from our local networks:
#
iptables -A INPUT -i eth0 -s x.y.z.s/32 -j DROP
iptables -A INPUT -i eth0 -s x.y.z.c/32 -j DROP
iptables -A INPUT -i eth0 -s 192.168.0.0/24 -j DROP
iptables -A INPUT -i eth0 -s 127.0.0.0/8 -j DROP

#
# Accept all tcp SYN packets for protocols SMTP, HTTP, HTTPS, and SSH:
# (SMTP connections are further audited by our SMTP server)
#
iptables -A INPUT -p tcp -s 0/0 -d x.y.z.m/32 –destination-port 25 –syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 80 –syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 443 –syn -j ACCEPT
iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 22 –syn -j ACCEPT

#
# Notice that the above rules are all INPUT rules. My current network
# does not require me to make use of FORWARD rules, since I run all
# publicly accessible servers directly on my firewall machine. But I
# promised above in the description of my network to give examples of
# rules used when there are servers running on machines on the internal
# network. Following are examples of FORWARD rules I would use if I ran
# mail, web, and ssh servers on machines on the internal network inside
# the firewall.
#
# iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.m/32 –destination-port 25 –syn -j ACCEPT
# iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 –destination-port 80 –syn -j ACCEPT
# iptables -A FORWARD -p tcp -s 0/0 -d x.y.z.w/32 –destination-port 443 –syn -j ACCEPT
# iptables -A FORWARD -p tcp -s 0/0 -d 0/0 –destination-port 22 –syn -j ACCEPT
#
#
# The first three of the above four rules would be used if my routing
# delivered packets having destination IP x.y.z.m, port 25, or IP
# x.y.z.w, port 80 or 443, to an interface connected to my internal
# network (i.e. the packet was being FORWARDed). The fourth of the above
# four rules is similar but operates on any destination IP, port 22.
#
# The difference between an INPUT rule and a FORWARD rule is that an
# INPUT rule applies to packets that are ‘input’ to this machine (the
# machine on which these iptables firewall rules are installed), whereas
# a FORWARD rule applies to packets that are being ‘fowarded’, i.e. to
# packets that are passing through this machine to some other machine,
# such as a machine on my internal network.
#
# If I ran my mail server on an internal machine, I would no longer
# need my previous INPUT rule for x.y.z.m and would use the above
# FORWARD rule instead.
#

#
# Begin Caveat, More about NAT and routing
#
# The above talk of routing is independent of the rules defined here.
# I.e., routing is determined by ifconfig, route, et. al. I have not
# yet seen any very good explanation of how to setup the static routing
# table (what you see as output from the `route` command). I will not
# attempt to remedy that lacuna at this time. If you know of some
# good documenation that completely and accurately explains the
# semantics of the ifconfig and route commands, i.e., explains what
# affect each has such that I can reliably predict what the output
# of `route` will be after executing a sequence of ifconfig and
# route commands, then please do let me know.
#
# What *can* be done by IPTABLES rules that has the ‘feel’ of routing is
# DNAT (Destintion NAT) and SNAT (Source NAT). DNAT and SNAT rules are,
# respectively, mechnisms to map the incoming destination IP number and
# outgoing source IP number to different IP numbers. For example, SNAT
# can be used to map an internal source IP number to any one of your
# external public IP numbers so that a workstation on your internal
# network will appear to servers on the internet to which it connects to
# have a source IP number equal to the mapped public IP number.
#
# DNAT goes the other way. It is a mechanism used typically to map
# public destination IP numbers to internal private IP numbers. (In
# fact, DNAT could also map public to public or private to private or
# private to public, but that is left as an exercise for the reader).
# So, for example, if you run a mail server on a machine configured with
# an internal IP number but wish to expose that service to the external
# world via a public IP number, DNAT is for you.
#
# Now, DNAT and SNAT are *not* routing but can *interact* with routing.
# Routing decides whether a packet is going to be INPUT to this machine
# or be FORWARDed to another machine. That decision is done by routing.
# Once that decision is made, and only then, are the IPTABLES filtering
# rules (FORWARD and INPUT rules) applied to a given packet. On the
# other hand DNAT is applied by a PREROUTING rule and SNAT by a POSTROUTING
# rule. It is now time for you to read the following Packet Filtering
# HOWTO section:
#
# http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTO-9.html
#
# which states:
#
# It’s common to want to do Network Address Translation (see the
# NAT HOWTO) and packet filtering. The good news is that they mix
# extremely well. [editor- The NAT HOWTO can be found at:
# http://www.netfilter.org/documentation/HOWTO/NAT-HOWTO.html]
#
# You design your packet filtering completely *ignoring* any NAT you
# are doing. The sources and destinations seen by the packet filter
# will be the `real’ sources and destinations. For example, if you
# are doing DNAT to send any connections to 1.2.3.4 port 80 through
# to 10.1.1.1 port 8080, the packet filter would see packets going
# to 10.1.1.1 port 8080 (the real destination), not 1.2.3.4 port 80.
# Similarly, you can ignore masquerading: packets will seem to come
# from their real internal IP addresses (say 10.1.1.1), and replies
# will seem to go back there.
#
#
# Hence, INPUT/FORWARD rules would operate on destination IP numbers
# *after* a DNAT rule is applied. But if you don’t have any DNAT rules,
# then INPUT/FORWARD would apply to the IP numbers as they are in the
# incoming packet.
#
# INPUT or FORWARD would be needed purely depending on whether your
# routing would cause the packet to stay on the machine where the
# firewall is installed or be forwarded to another machine. THAT
# decision is done by routing and *not* by DNAT or SNAT or anything
# else in this firewall script.
#
# It is perfectly possible for the machine having the firewall to have
# both public and internal IPs configured and/or for some packets to be
# INPUT and others to be FORWARDed.
#
# DNAT is done by a PREROUTING rule, so you should think of things as
# proceeding in the following order:
#
# 1. apply PREROUTING DNAT rules (if any) to map destination IP
# 2. apply routing decisions (see ifconfig et. al.)
# 3a. apply INPUT rules to packets having a destination IP on this machine
# 3b. apply FORWARD rules to packets having a destination IP elsewhere
# 4. apply POSTROUTING SNAT rules (if any) to map source IP
#
# (3a and 3b can be done in either order since they apply to a mutually
# exclusive set of packets)
#
# I *think* that’s correct.
#
# End Caveat, More about NAT and routing
#
#
# Sometimes I run older versions of SSH on port 2200:
#
iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 2200 –syn -j ACCEPT

#
# For imapd via stunnel (instead of xinetd-based imapd):
#
iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 993 –syn -j ACCEPT

#
# For xinetd-based IMAP server (see /etc/xinetd.conf for who can use it):
#
#iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 143 –syn -j ACCEPT

#
# For DHCP server:
#
iptables -A INPUT -i eth1 -p tcp –sport 68 –dport 67 -j ACCEPT
iptables -A INPUT -i eth1 -p udp –sport 68 –dport 67 -j ACCEPT

#
# For LDAP clients:
#
#iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port 389 -syn -j ACCEPT
#dga- worry about LDAP later (after I decode LDAP documentation (-;)
#
# DNS queries:
#
# Permit responses from our ISP’s DNS server. When a client running on our
# host makes a DNS query, the outgoing query is allowed since we permit all
# outgoing packets. The reply will be a UDP connection back to the high
# numbered client port from which the query was made. So we only need to
# permit UDP packets from our ISP’s DNS servers back to high numbered ports:
#
#iptables -A INPUT -p udp -s <ISP DNS server IP>/32 –source-port 53 -d 0/0 –destination-port 1024:65535 -j ACCEPT
#
# But since we trust our ISP DNS Server not not have been hacked and we may
# not be sure what our client IP range is, we loosen this to:
#
iptables -A INPUT -p udp -s <ISP DNS server IP>/32 –source-port 53 -d 0/0 -j ACCEPT
#
# Running a caching DNS Server
#
# We need to permit querying a remote DNS server. Since I am running
# a caching DNS server on x.y.z.d that makes requests for DNS lookups
# to external DNS servers, those servers send back responses via UDP to
# the high numbered client port on x.y.z.d where the caching server listens.
# I could of course increase security by running the dns cache on its own
# machine/IP and restricting to just that machine/IP.
#
iptables -A INPUT -p udp -s 0/0 –source-port 53 -d x.y.z.d/32 –destination-port 1024:65535 -j ACCEPT
#
# Running a DNS server (tinydns)
#
# When we run a DNS server, we have to accept UDP from anywhere to port 53
#
iptables -A INPUT -p udp -s 0/0 -d 0/0 –destination-port 53 -j ACCEPT
#
# Running a Master DNS Server to update slave DNS servers
#
# You may have your server colocated at an ISP and may arrange to have your
# ISP provide your primary and secondary DNS with the ISP DNS servers slaving
# off of your master DNS server. This has the advantage of letting you be
# in full control of the DNS zone files yet keeping the DNS servers exposed
# to the public outside of your network. To achieve this, in addition to
# permitting vanilla DNS responses from the ISP DNS serves, you also need
# to allow TCP connections from the ISP Master DNS Server:
#
# Allow DNS zone transfers via TCP from ISP Master DNS server:
#
# iptables -A INPUT -p tcp -s <ISP Master DNS server IP>/32 -d 0/0 –destination-port 53 –syn -j ACCEPT
#
# For some other custom server running here listening on port <port number>:
#
iptables -A INPUT -p tcp -s 0/0 -d 0/0 –destination-port <port number> –syn -j ACCEPT

#
# For FTP server, restricted to specific local hosts (and see /etc/xinetd.conf):
# (for public file transfers we use scp, sftp, and related SSH file transfer tools)
#
iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 –destination-port 20 –syn -j ACCEPT
iptables -A INPUT -p tcp -s x.y.z.s/32 -d 0/0 –destination-port 21 –syn -j ACCEPT
iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 –destination-port 20 –syn -j ACCEPT
iptables -A INPUT -p tcp -s 127.0.0.1/8 -d 0/0 –destination-port 21 –syn -j ACCEPT

#
# For Samba (smbd and nmbd), restricted to specific local client hosts (x.y.z.c):
#
iptables -A INPUT -p tcp -s x.y.z.c/32 -d x.y.z.s/32 –destination-port 139 –syn -j ACCEPT
iptables -A INPUT -p udp -s x.y.z.c/32 -d x.y.z.s/32 –destination-port 137 -j ACCEPT

#
#Special cable modem rules. I used to have a third ethernet card,
#eth2, attached to a separate ISP via a cable modem and used the rules
#shown below to cause a specific Windows machine on my internal network
#(192.168.0.128) to send traffic out via DSL and get it back via cable.
#This violates ingres filtering rules but seems to work. It was neat
#since my cable modem had higher inbound bandwidth and it permitted
#me to do downloads without impacting my DSL inbound bandwidth.
#I no longer have that third interface, so no longer use this technique.
#
#iptables -A INPUT -i eth2 -s 68.65.209.39/32 -j DROP
#iptables -A INPUT -i eth2 -s 127.0.0.0/8 -j DROP
#iptables -t nat -A POSTROUTING -s 192.168.0.128/32 -d 0/0 -j SNAT –to-source 68.65.209.39

#
# Finally, DENY all connection requests to any UDP port not yet provided
# for and all SYN connection requests to any TCP port not yet provided
# for. Using DENY instead of REJECT means that no ‘ICMP port
# unreachable’ response is sent back to the client attempting to
# connect. I.e., DENY just ignores connection attempts. Hence, use of
# DENY causes UDP connection requests to time out and TCP connection
# requests to hang. Hence, using DENY instead of REJECT may have
# the effect of frustrating attackers due to increasing the amount of
# time taken to probe ports.
#
# Note that there is a fundamental difference between UDP and TCP
# protocols. With UDP, there is no ‘successful connection’ response.
# With TCP, there is. So an attacking client will be left in the dark
# about whether or not the denied UDP packets arrived and will hang
# waiting for a response from denied TCP ports. An attacker will not
# be able to immediately tell if UDP connection requests are simply
# taking a long time, if there is a problem with connectivity between
# the attacking client and the server, or if the packets are being
# ignored. This increases the amount of time it takes for an attacker
# to scan all UDP ports. Similarly, TCP connection requests to denied
# ports will hang for a long time. By using REJECT instead of DENY, you
# would prevent access to a port in a more ‘polite’ manner, but give out
# more information to wannabe attackers, since the attacker can positively
# detect that a port is not accessible in a small amount of time from
# the ‘ICMP port unreachable’ response.

iptables -A INPUT -s 0/0 -d 0/0 -p udp -j DROP
iptables -A INPUT -s 0/0 -d 0/0 -p tcp –syn -j DROP

# ————————————————-

 

 

Thanks for visiting this site…………………..Welcome Genowin Technologies.
Happy To Help You ….
All Linux Solution & Training.
Genowin Technologies(www.genowin.com)

Leave a Reply

Your email address will not be published. Required fields are marked *