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

As always, anytime you make system changes, backup the configuration file first, restart the appropriate

daemon afterward, and then check the appropriate logs for error messages.

5.7. Verifying

The final step after getting your firewall in place, is to verify that it is doing what you intended. You would

be wise to do this anytime you make even minor changes to your system configuration.

So how to do this? There are several things you can do.

For our packet filters like ipchains and iptables, we can list all our rules, chains, and associated activity with

iptables −nvL | less (substitute ipchains if appropriate). Open your xterm as wide as possible to

avoid wrapping long lines.

This should give you an idea if your chains are doing what you think they should. You may want to perform

some of the on−line tasks you normally do first: open a few web pages, send and retrieve mail, etc. This will,

of course, not give you any information on tcpwrappers or portsentry. tcpdchk can be used to verify

tcpwrappers configuration (except with xinetd).

And then, scan yourself. nmap is the scanning tool of choice and is included with recent Red Hat releases, or

from http://www.insecure.org/nmap/nmap_download.html. nmap is very flexible, and essentially is a "port

prober". In other words, it looks for open ports, among other things. See the nmap man page for details.

If you do run nmap against yourself (e.g. nmap localhost), this should tell you what ports are open −−

and visible locally only! Which hopefully by now, is quite different from what can be seen from the outside.

So, scan yourself, and then find a trusted friend, or site (see the Links section), to scan you from the outside.

Make sure you are not violating your ISPs Terms of Service by port scanning. It may not be allowed, even if

the intentions are honorable. Scanning from outside is the best way to know how the rest of the world sees

you. This should tell you how well that firewall is working. See the nmap section in the Appendix for some

examples on nmap usage.

One caveat on this: some ISPs may filter some ports, and you will not know for sure how well your firewall

is working. Conversely, they make it look like certain ports are open by using web, or other, proxies. The

scanner may see the web proxy at port 80 and mis−report it as an open port on your system.

Another option is to find a website that offers full range testing. http://www.hackerwhacker.com is one such

site. Make sure that any such site is not just scanning a relatively few well known ports.

Repeat this procedure with every firewall change, every system upgrade or new install, and when any key

components of your system changes.

You may also want to enable logging all the denied traffic. At least temporarily. Once the firewall is verified

to be doing what you think it should, and if the logs are hopelessly overwhelming, you may want to disable

logging.

If relying on portsentry at all, please read the documentation. Depending on your configuration it will either

drop the route to the scanner, or implement a ipchains/iptables rule doing the same thing. Also, since it

"listens" on the specified ports, all those ports will show as "open". A false alarm in this case.

Security Quick−Start HOWTO for Red Hat Linux

5.7. Verifying 32

1 2 ... 30 31 32 33 34 35 36 37 38 39 40 ... 81 82

Nessun commento

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