__/ [Technomage Hawke] on Monday 17 October 2005 14:13 \__
> Roy Schestowitz wrote:
>
>
>> What if the hack was requested by the tester for the sake of defence from
>> real attack? That what white-hats are for. My sites came under attack by
>> Windows-based hijacked machines at the beginning of the month. Those
>> zombies requested what could have been 50 GB of generated on-the-fly
>> pages in just 1 day. Had I been more familiar with Linux firewalls, I
>> would have swatted them at a much earlier stage and not after 2 weeks of
>> a gradually-increasing attack pace. I also would not have served as a
>> 'human filter' for 2 consecutive days. I couldn't do any work, so it was
>> costly.
>
> Then there would be a contract, with the usual pleasentries from lawyers,
> etc and actual monies would change hands (its called formal contracted
> services bud!)
>
> Such things are accompanied by (and not limited to):
> 1. internal security audits (as this is where 90% of all security breaches
> originate)
> 2. review of policies and procedures (and their enforcement or lack
> thereof) 3. review of firewall machine (including, but not limited to:
> patch history, code version, current implementation, etc)
>
> now, in any of these, there does not appear the words scan, probe or
> break/hack. The term audit carries a very broad meaning.
>
> as for the firewall, the best tests are usually done "in the lab" under
> controlled conditions. after a suitable "burn-in" time, is the machine
> certified for production use (in the case of my openbsd firewall, 1 week
> burn-in to root out any problems, 2 days to correct, 3 more days to
> recertify and lastly, unit placed in productions with a minimum of rules
> applied (block all in on all interfaces/ pass on all any connection from
> internal to external with state, etc) In this case, all connections are
> relative to the firewall.
>
> in most cases, any external attack can be easily fended off by applying a
> little common sense:
> 1. never run unnecessary services on the firewall
> 2. only open/redirect ports absolutely necessary for the functioning of
> services (such as redirect http to dmz, etc)
> 3. only log those items of concern (port scans and the like). any more
> than that will fill the logs fast and result in a very full file system in
> short order
> 4. review logs daily. patters will reveal themselves over time and can be
> dealt with by minor changes to the firewall
> lastly: security policy to be strictly adhered to. no exceptions for
> anyone.
Your description has been helpful to me as I am still trying to figure out a
permant solution to this second wave of DoS attacks on my site. whether it
will ever end I don't know. I have re-directed common requests this
morning, which seems to do the trick temporarily (with a cost of punishing
SE's and real users). I still wonder if I rubbed someone the wrong way. The
bitterness persists and is directed primarily at: Google - for link greed
(backlinks -> referrer spam); Microsoft - easily caputable O/S; ISP's for
allowing traffic of that scale to flow in/out...
>> ...But I agree with the responder who said that it's not free labour and
>> should hence be paid for...
>
> this is why most linux vendors give away the product and charge huge sums
> for "tech support" (because, there is where the money is!).
...If ever. Some would argue that there are also issues with support-related
revenues. Revenues that otherwise would suffice to make ends meet.
Roy
--
Roy S. Schestowitz | SuSE, Mandriva, Fedora - Gotta love them girls
http://Schestowitz.com | SuSE Linux | PGP-Key: 74572E8E
2:50pm up 53 days 3:04, 4 users, load average: 0.13, 0.27, 0.33
http://iuron.com - next generation of search paradigms
|
|
