Mike Smith's excellent guide to Linux network security
"Security is always a calculated risk, it's a matter of minimizing that risk."
-mike
These are notes from a demo/class/lecture given to the monthly meeting of the
Eugene Linux Users Group. meeting at ComSource associates(thanx bob)
Mike started off by giving an overview of important configuration files and
tools for analysing network security and then went into a fair amount of detail
covering ipchains.
/etc/hosts.deny /etc/hosts.allow
hosts.deny being notable as one place where you can deny access to your machine
by particular hosts to particular services. Or deny all services to all hosts.
inetd.conf
inetd listens to ports and starts servers on request
certain servers should be run standalone (apache,samba)
nmap
nmap is a fully featured portscanning tool that can be run against a host
or network, when testing a firewall or network server you want to run it from
the outside as well as running it through localhost.
ippl
IP Protocol Logger tracks all kinds of tcp/ip transactions
logcheck
can email you if certain things show up in the log files
in other words if somebody tries to log in as root you'll know within minutes
snort
another log analyser, this one is based on rulesets and can tell you
the who, what, where and when of various security exploits, new rulesets
are constantly being developed and introduced.
_______________________________________________________________________
IPCHAINS packet filtering and forwarding
The way ipchains works is that it has a set of three rule chains:
INPUT OUTPUT and FORWARD you can also define your own rule chains.
Rules have source, destination and protocol information. and can be set to
ACCEPT, DENY, REJECT, MASQ, or FORWARD packets.
When a packet hits one of the interfaces the rules are consulted in series
until a rule matching the packet is found, at which point the action named in
the rule is executed.
For each rule chain there are a set of rules that the kernel looks at and then
a default rule known as the policy.
usage:
ipchains -A --add INPUT
-D --delete OUTPUT
-I --insert FORWARD
-F --flush
-L --list
-P --policy
also:
ipchains-save and ipchains-restore are useful in storing the state of
the rule tables to a file and then resurrecting them later, mike suggests
that its a good idea to run ipchains-save from a cron job and ipchains-restore
at boot time. Seth mentioned that it can be a good idea to save a known-good
configuration elsewhere and check it occasionally.
caveats:
cavalier use of the -F option can lock you out of a remote box, what happens
is that either the input or the output policy was set to either REJECT or
DENY and if there's no rules to tell it not to blow away your ssh packets...
you'll need to reboot the machine.
------------
note:
ipchains will be superseded by iptables once kernel 2.4 is deployed, it's
newer, faster, simpler, more feature rich etc.... hopefully someone smart
will figure it out and explain it to us like mike just did with ipchains
------------
other things:
portsentry: portscan detection
features scan triggers and retaliatory action i.e. can lock someone out
if they try to get fresh with the server, or launch a script of your choice
to go out and track 'em down, etc.
Tripwire && Aide
these are intrusion detection and recovery packages, they basically run a
checksum on your binaries and config files and let you know if they change
in any significant manner. Useful in recovering things if you do get hacked.
So these are the notes i took from mikes presentation, any errors,
misleading information and dangerously wrong advice is belong to me.
Use at own risk, may cause drowsiness, sleeplessness and delusions of
grandeur.
I'll try to track down various URLs and slap a few <tags> on it to make it
presentable for the website.... later.
Larry Price | "We have seen the truth.
[EMAIL PROTECTED] | And the truth makes no sense." -chesterton
_______________________________________________________________
