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

connections from 192.168.1.0, our LAN. For xinetd's purposes, this denotes any IP address beginning

with "192.168.1". Note that the syntax is different from inetd. The server statement in this case is the

tftp daemon, in.tftpd. Again, this assumes that libwrap/tcpwrappers support is compiled into xinetd. The

user running the daemon will be "nobody". Yes, there is a user account called "nobody", and it is wise to

run such daemons as non−root users whenever possible. Lastly, the disable statement is xinetd's way of

turning services on or off. In this case, it is "on". This is on here only as an example. Do NOT run tftp as a

public service as it is unsafe.

5.4. PortSentry

Portsentry works quite differently than the other tools discussed so far. Portsentry does what its name implies

−− it guards ports. Portsentry is configured with the /etc/portsentry/portsentry.conf file.

Unlike the other applications discussed above, it does this by actually becoming the listening server on those

ports. Kind of like baiting a trap. Running netstat −taup as root while portsentry is running, will show

portsentry as the LISTENER on whatever ports portsentry is configured for. If portsentry senses a connection

attempt, it blocks it completely. And then goes a step further and blocks the route to that host to stop all

further traffic. Alternately, ipchains or iptables can be used to block the host completely. So it makes an

excellent tool to stop port scanning of a range of ports.

But portsentry has limited flexibility as to whether it allows a given connection. It is pretty much all or

nothing. You can define specific IP addresses that it will ignore in

/etc/portsentry/portsentry.ignore. But you cannot allow selective access to individual ports.

This is because only one server can bind to a particular port at the same time, and in this case that is

portsentry itself. So it has limited usefulness as a stand−alone firewall. As part of an overall firewall strategy,

yes, it can be quite useful. For most of us, it should not be our first line of defense, and we should only use it

in conjunction with other tools.

Suggestion on when portsentry might be useful:

As a second layer of defense, behind either ipchains or iptables. Packet filtering will catch the

packets first, so that anything that gets to portsentry would indicate a misconfiguration. Do not use in

conjunction with inetd services −− it won't work. They will butt heads.

•

As a way to catch full range ports scans. Open a pinhole or two in the packet filter, and let

portsentry catch these and re−act accordingly.

•

If you are very sure you have no exposed public servers at all, and you just want to know who is up

to what. But do not assume anything about what portsentry is protecting. By default it does not watch

all ports, and may even leave some very commonly probed ports open. So make sure you configure it

accordingly. And make sure you have tested and verified your set up first, and that nothing is

exposed.

•

All in all, the packet filters make for a better firewall.

5.5. Proxies

The dictionary defines "proxy" as "the authority or power to act on behalf of another". This pretty well

describes software proxies as well. It is an intermediary in the connection path. As an example, if we were

Security Quick−Start HOWTO for Red Hat Linux

5.4. PortSentry 29

1 2 ... 27 28 29 30 31 32 33 34 35 36 37 ... 81 82

Nessun commento

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