[Dshield] Being a good Internet citizen - best practices?

Valdis.Kletnieks@vt.edu Valdis.Kletnieks at vt.edu
Sat Feb 4 16:45:41 GMT 2006

On Fri, 03 Feb 2006 15:48:16 PST, Anthony Rodgers said:
> Greetings,
> I am in the IT department of a largish organization (~400 desktops) 
> with our own IP netblocks (5 /24s), and I was wanting to gather ideas 
> from the list for what we could be doing to be a good Internet citizen, 
> along the lines of monitoring abuse@ mail addresses, keeping our WHOIS 
> up to date, etc.
> What are the things that make you say "geez, I wish people 
> would......."?

Well.. I could think of a *lot* of things to list, but here's a dozen or so of
the top ones, in no particular order....

0) Install a backup system and back up *all* important data. Test your backups.
And yes, you need to backup the raid-5 you have too - those things *can* fail.
Make sure you have an off-site copy (not at an employee's home if you can help
it) of the backups, just in case. If all else fails, rent a safe deposit box at
a local bank and keep a current set there.... This may not make you a better
internet citizen, but you'll be glad when you hear the high-pitched whine of a
drive going bad...

1) Proper ingress and egress filtering on your border router. See RFC2827.
Don't allow outbound packets not in your address space, don't allow rfc1918
address block packets to escape, and don't allow *inbound* packets with sources
inside your address space (unless you're multihomed and *really* understand
what you're doing, and your network is partitioned).

2) Working postmaster@, abuse@, and security@ addresses.

3) All machines kept up to current patchlevels, and hardened according to the
applicable benchmark from the Center for Internet Security (http://www.cisecurity.org).
Windows, routers, unix/ linux boxes.  One note - it is *not* expected that you
deploy every line item on every machine - but do what you can, where you can.
(Disclosure note - I'm at least partially to blame for large chunks of the
Solaris, AIX, and Linux benchmarks).

4) Keep a changelog of patching and config changes, so you can remember which
ones you did and which ones the hacker did....  It also comes in handy when
the trivial change you made 2 weeks ago totally badgers the payroll run and
your phone rings at 2:47AM....

5) Deploy alternate operating systems and/or browsers when appropriate.  I don't
expect you to convert *everything* to Linux using Firefox - but if you convert
half, then if something gets loose, you'll still have half your boxes. See

6) User training - no "OOH!! Shiny!" clicky-clicky, *especially* if it promises
dancing hamsters or underdressed celebrities or similar.

7) For Microsoft boxes, choose a good A/V solution and keep the signatures up
to date.  For Unix and Linux, the threat model is different, so traditional A/V
doesn't buy you much - you should run Tripwire or AIDE or similar
change-monitoring system instead (that will catch rootkits and trojaned
binaries, which are a bigger issue than viruses on Unix/Linux). I haven't
decided what to suggest for Mac OSX yet.

8) Run NTP on all machines to keep the system clocks synchronised.  The payback
comes when you have and incident and don't have to keep adding and subtracting
2 minutes and 37 seconds while comparing 2 system's logfiles.

9) Run a centralized syslog server and have everything log to it. This will
both mean there's a second copy of the logs a hacker can't easily erase, and
also give you a box you can do cross-correlation on ("wow, these 37 machines
all got probed by....").  Run a good log summarizing and exception notification
system - 'logwatch' and the venerable 'logcheck' come to mind.

10) Run Snort or other IDS on your net. Configure it correctly. Make sure
somebody actually reads the logs. (Having Snort false-positive on tons of
stuff, and then not reading the false positives, doesn't do anybody any good).
With a bit of cleverness, you can feed these to logwatch/logcheck as well..

11) If your religion requires it, run a properly configured border firewall. If
so, remember this does *not* secure your net - the first laptop onto your
internal net will possibly negate its benefits. Marcus Ranum once called the
average firewalled net a "hard crunchy outside, soft chewy inside" - and don't
forget that the *really* damaging attacks are often *inside* jobs.  You'll wish
you paid that administrative assistant what they were worth. ;) Oh, and tie
this in with item 9 - a firewall with unread logs is useless... ;)

12) Hire a good security guy who can tell you what *your* site's number 12 should be.

Yes, it's a bunch of stuff - but once you get past the one-time setup cost of
all of it, you should find that the ongoing cost of reading the logs and
compliance checking to make sure systems are still patched and configured will
be less than the cost of cleaning up after an incident.  And you'll find that
many of the items will also help with non-security issues as well...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 226 bytes
Desc: not available
Url : http://www.dshield.org/pipermail/list/attachments/20060204/b1917a7b/attachment.bin

More information about the list mailing list