This one time, at band camp, Brian Furry said:
> (Speaking as the Net Admin)
> I have described the Linux project, its uses, and its physical placement
> within our network, to four knowledgeable people, and asked for their
> thoughts and recommendations.
>
> A. Partner in a consulting company based in Hunterdon County. Their
> mission is to encourage Linux use in small/medium companies.
>
> B. Lt. Col. (ret.) USAF, now a contractor for the Air Force (process
> compliance and Unix network administrator)
>
> C. Network technician. This person builds wide-area networks for
> corporations and financial institutions
>
> D. Computer consultant. This person has extensive employment experience
> (programming, documentation, database, networking) with HP, Agilent, and
> others. Husband and brother also do design work for top computer firms.
>
>
> They all insisted that a dedicated firewall is a requirement. They are
> unanimous in their exhortation that the server be properly secured. "B"
> gave specific items to examine in this regard, and "A" offered to scan it
> from inside and outside our building.
>
> "A," "B," and "C" state that, even if it IS properly secured, this does
> not prevent some types of malicious behavior. "A" and "B" think that the
> risk is no greater than our current setup, while "C" has reservations that
> we should not increase our susceptibility, and that the 24-hour
> availability of this server leaves us open to mischief.
>
> I share "C"'s concern. In-school computer use is subject to various
> controls, not the least of which is teacher oversight. By design, a
> publicly accessible server on which students can run their own programs at
> 3 a.m. lacks this important security.
>
> In light of this last point, let me pose a situation: A student loads and
> runs a program onto this Linux server which then launches attacks on other
> computers or routers on the Internet. Such attacks could be as simple as
> participating in a Denial-of-Service attack. In our earlier meeting, you
> said that proper settings, permissions, and restrictions could prevent that.
>
> Since this is one of the situations for which I am most concerned, can you
> give me (in excruciating detail) the steps which would prevent this?
iptables combined with login restrictions can solve this - I believe
setting up time-dependant logins is relatively painless (user can log in
only from 8AM to 4PM, for example). iptables can easily restrict
outgoing traffic, and the rate of outgoing traffic, so that you could
allow regular web requests, but not ping floods or other attacks. There
are other restrictions that you can use to limit user's ability to do
things - check out
usr/share/doc/libpam-doc/sgml/modules/pam_limits.sgml.gz in libpam-doc
or man 5 limits for more things that are configurable.
Some brief examples:
/sbin/iptables -P OUTPUT DROP # This prevents outgoing connections
/sbin/iptables -A OUTPUT -p (tcp, icmp, whatever) -m limit --limit \
1/second -j ACCEPT # This would limit rate of
# outgoing connections instead
In /etc/security/limits.conf:
@student hard nproc 50 # Limits max cpu processes
These are just off the top of my head - the others on this list can
probably give you more (and much better suggestions than this.
Good luck,
Steve
--
Finagle's Seventh Law:
The perversity of the universe tends toward a maximum.
Attachment:
pgpkISU64Jv8I.pgp
Description: PGP signature