Linux Security Cookbook [Electronic resources] نسخه متنی

اینجــــا یک کتابخانه دیجیتالی است

با بیش از 100000 منبع الکترونیکی رایگان به زبان فارسی ، عربی و انگلیسی

Linux Security Cookbook [Electronic resources] - نسخه متنی

Daniel J. Barrett, Robert G. Byrnes, Richard Silverman

| نمايش فراداده ، افزودن یک نقد و بررسی
افزودن به کتابخانه شخصی
ارسال به دوستان
جستجو در متن کتاب
بیشتر
تنظیمات قلم

فونت

اندازه قلم

+ - پیش فرض

حالت نمایش

روز نیمروز شب
جستجو در لغت نامه
بیشتر
لیست موضوعات
توضیحات
افزودن یادداشت جدید










Chapter 2. Firewalls with iptables and ipchains


Your network's first barrier against unwanted
infiltrators is your firewall. You

do have a
firewall in place, right? If you think you don't
need one, monitor your incoming network traffic some time: you might
be amazed by the attention you're receiving. For
instance, one of our home computers has never run a publicly
accessible service, but it's hit 10-150 times per
day by Web, FTP, and SSH connection requests from unfamiliar hosts.
Some of these could be legitimate, perhaps web crawlers creating an
index; but when the hits are coming from

dialup12345.nowhere.aq in faraway
Antarctica, it's more likely that some script kiddie
is probing your ports. (Or the latest Windows worm is trying in vain
to break in.)

Linux has a wonderful firewall built right into the kernel, so you
have no excuse to be without one. As a superuser, you can configure
this firewall with interfaces called
ipchains
and
iptables. ipchains models a

stateless
packet filter. Each packet reaching the firewall is evaluated against
a set of rules. Stateless means that the
decision to accept, reject, or forward a packet is not influenced by
previous packets.

iptables, in contrast,
is

stateful: the firewall can make decisions
based on previous packets. Consider this firewall rule:
"Drop a response packet if its associated request
came from

server.example.com ."
iptables can manage this because it can associate
requests with responses, but ipchains cannot.
Overall, iptables is significantly more powerful,
and can express complex rules more simply, than
ipchains.

ipchains is found in
kernel Versions 2.2 and up, while
iptables requires kernel Version
2.4 or higher.[1] The two cannot
be used together: one or the other is chosen when the kernel is
compiled.

[1] Kernel 2.0 has another interface
called ipfwadm, but it's so old
we won't cover it.


A few caveats before you use the recipes in this chapter:


  • We're definitely not providing a complete course in
    firewall security. ipchains and
    iptables can implement complex configurations, and
    we're just scratching the surface. Our goal, as
    usual, is to present useful recipes.


  • The recipes work individually, but not necessarily when combined. You
    must think carefully when mixing and matching firewall rules, to make
    sure you aren't passing or blocking traffic
    unintentionally. Assume all rules are flushed at the beginning of
    each recipe, using iptables -F or
    ipchains -F as appropriate. [Recipe 2.17]


  • The recipes do not set default policies (-P
    option) for the chains. The default policy specifies what to do with
    an otherwise unhandled packet. You should choose intelligent defaults
    consistent with your site security policy. One example for
    iptables

    is:

    # iptables -P INPUT DROP
    # iptables -P OUTPUT ACCEPT
    # iptables -P FORWARD DROP

    and for ipchains:

    # ipchains -P input DENY
    # ipchains -P output ACCEPT
    # ipchains -P forward DENY

    These permit outgoing traffic but drop incoming or forwarded packets.



The official site for
iptables
is http://www.netfilter.org, where you can also
find the

Linux 2.4 Packet Filtering Howto at
http://www.netfilter.org/documentation/HOWTO/packet-filtering-HOWTOl.
Another nice iptables article is at http://www.samag.com/documents/s=1769/sam0112a/0112a.


Our Firewall Philosophy


In designing a set
of firewall rules
for a Linux host, there are
several different models we could follow. They correspond to
different positions or functions of the host in your network.


Single computer



The host has a single network interface, and the
firewall's purpose is to protect that host from the
outside world. The principle distinction here is
"this host" versus
"everything else." One example is a
home computer connected to a cable modem.


Multi-homed host



The host has multiple network interfaces connected to different
networks, but is

not acting as a router. In
other words, it has an address on each of its connected networks, but
it does not forward traffic across itself, nor interconnect those
networks for other hosts. Such a host is called
multi-homed and
may be directly connected to various networks. In this case, firewall
rules must distinguish among the different interfaces, addresses, and
networks to which the host/router is attached, perhaps implementing
different security policies on different networks. For example, the
host might be connected to the Internet on one side, and a trusted
private network on the other.


Router



The host has multiple network interfaces and is configured as a
router. That is, the
kernel's "
IP forwarding" flag is
on, and the host will forward packets between its connected networks
as directed by its routing table. In this case, firewall rules not
only must control what traffic may reach the host, but also might
restrict what traffic can

cross the host (as
router), bound for other hosts.



For this chapter, we decided to take the first approachsingle
computeras our model. The other models are also valid and
common, but they require a more detailed understanding of topics
beyond the scope of this book, such as IP routing, routing protocols
(RIP, OSPF, etc.), address translation (NAT/NAPT), etc.

We also assume your single computer has source address verification
turned on, to prevent remote hosts from pretending to be local. [Recipe 2.1] Therefore we don't address
such spoofing directly in the firewall rules.

/ 247