Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Frackin script kiddies!!



Matthew Gillen wrote:
> Right, but my point is that solutions like that are almost by definition
> reactive: you don't add something to your script until you get burned by it
> once (except maybe for some obviously foreseeable things).  For most

The catalyst of the reaction is more times than not me reading about
something from a mailing list or website where something happened to
someone else.  Learning from others' mistakes is even better.

> configuration issues, yours is probably the best approach.  But for
> security-related configuration, the trial-and-error is disruptive and
> potentially costly (if you have two weeks of backups, and the attack goes
> unnoticed for 15 days...).

Security-related configurations are generally administered by real full
time Sysadmins.  I am not a Sysadmin, and I cannot work on my server
full-time (I am, however, real).

> I find it's much easier to secure one service (ssh) to a reasonable level, and
> ignore 'security' for most everything else.

That's nice, but I can't do that.  Like I said, most every port is
blocked at work.







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org