Red Hat NETSCAPE MANAGEMENT SYSTEM 6.2 - COMMAND-LINE Guida di Installazione Scaricare il pdf (Pagina 81)

$IPTABLES −A DEFAULT −m state −−state NEW −i ! $WAN_IFACE −j ACCEPT

# Enable logging for anything that gets this far.

$IPTABLES −A DEFAULT −j LOG −m limit −−limit 30/minute −−log−prefix "Dropping: "

# Now drop it, if it has gotten here.

$IPTABLES −A DEFAULT −j DROP

# This is the 'bottom line' so to speak. Everything winds up

# here, where we bounce it to our custom built 'DEFAULT' chain

# that we defined just above. This is for both the FORWARD and

# INPUT chains.

$IPTABLES −A FORWARD −j DEFAULT

$IPTABLES −A INPUT −j DEFAULT

echo "Iptables firewall is up `date`."

##−− eof iptables.sh

8.10.3. Summary

A quick run down of the some highlights...

We added some host based access control rules: "blacklisted", and "trusted". We then showed several types of

service and port based access rules. For instance, we allowed some very restrictive access to bigcat's

POP3 server so we could connect only from our workplace. We allowed a very narrow rule for the ISP's

DHCP server. This rule only allows one port on one outside IP address to connect to only one of our ports

and only via the UDP protocol. This is a very specific rule! We are being specific since there is no reason to

allow any other traffic to these ports or from these addresses. Remember our goal is the minimum amount of

traffic necessary for our particular situation.

So we made those few exceptions mentioned above, and all other services running on bigcat should be

effectively blocked completely from outside connections. These are still happily running on bigcat, but are

now safe and sound behind our packet filtering firewall. You probably have other services that fall in this

category as well.

We also have a small, home network in the above example. We did not take any steps to block that traffic. So

the LAN has access to all services running on bigcat. And it is further "masqueraded", so that it has Internet

access (different HOWTO), by manipulating the "forward" chain. And the LAN is still protected by our

firewall since it sits behind the firewall. We also didn't impose any restrictive rules on the traffic leaving

bigcat. In some situations, this might be a good idea.

Of course, this is just a hypothetical example. Your individual situation is surely different, and would require

some changes and likely some additions to the rules above. For instance, if your ISP does not use DHCP

(most do not), then that rule would make no sense. PPP works differently and such rules are not needed.

Please don't interpret that running any server as we did in this example is necessarily a "safe" thing to do. We

shouldn't do it this way unless a) we really need to and b) we are running the current, safe version, and c) we

are able to keep abreast of security related issues that might effect these services. Vigilance and caution are

part of our responsibilities here too.

Security Quick−Start HOWTO for Red Hat Linux

8.10.3. Summary 78

1 2 ... 76 77 78 79 80 81 82

Nessun commento

Red Hat NETSCAPE MANAGEMENT SYSTEM 6.2 - COMMAND-LINE Guida di Installazione Pagina 81