Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
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 | |
We also thank MIT for the use of their facilities. |