> If we're talking about some speficic systems, enumerate them.
>
> Windows - learn how to use EMET. Btw - i am aware of that "here's
> another way to bypass EMET". Most, if not all of them are build up on
> a bad assumption - like, the process beeing attacked has full
> Administrator/Local System privileges, with write access to debug
> registers. If your MSSQL can do that - you aready have a bigger
> problem.
EMET is a nice tool (I don't hear it mentioned too often. Another neat
one is BinScope, which allows you to examine platform security
integration, such as ASLR and DEP.
> Do not trust defaults. Run services into separate accounts and give
> them only what they need. Same goes for user applications, as someone
> has pointed out already. Get some _kernel_ enforced software that can
> whitelist binaries that can be run. Use build-in things in Windows,
> like (parts of, at least) MAC and MIC (Mandatory Access Control and
> Mandatory Integrity Control, if anyone wonders).
So much for "Secure Out of the Box".
> Linux - learn how to use PaX in a right way. How to make your
> executables into proper PIE. Learn some MAC system and use it - RSBAC,
> for example. Â Or Grsec RBAC.
Don't hold your breathe for --noexec-heap (unless its a hardend
distribution). Checksec is a good tool to audit binaries for this.
> 0-days aren't some kind of black magic, that if it's done to your
> servers will make them all turn into kitten-killing-zombies. They are
> ordinary exploits - made by people who know a lot more than you. Use
> exploit mittigation techniques.
According to Verizon Data Breach Report, most breaches are not 0-day,
which probably makes them closer to 90-day, 6-month-dat, or
Forever-day.
> After all, there's not much you can do on Linux system, with PaX, with
> PIE binaries, NX + full ASLR enforced, with mprotect() restrictions.
> Unless you have some information leak in application _before_ it is
> exploited, that's it.
ROP anyone? I understand a new iPhone break for iOS 5.1 will be out shortly ;)
> On May 22, 2012, at 5:32 PM, Stephanus J Alex Taidri wrote:
>
>> Seconded to Rob....
>>
>> Limit the OS to run with least privilege as possible instead of
>> granting administrator access to normal user.
>> This is common for Linux OS, Mac OS and Windows 7 onwards to have apps
>> running with normal user privilege and required User Access Control
>> (UAC) to confirmed any changes that required root/admin privilege.
>>
>> Train the end-users to not simply ignore any UAC pop-up window(s), to
>> read carefully and understand it well before accepting the action
>> requested. If in doubt, always train end-users to choose No/Reject as
>> usually there's less harm to do this.
>>
>> Kind regards,
>> SJ Alex Taidri
>>
>> On Tue, May 22, 2012 at 11:10 PM, <synja (at) synfulvisions (dot) com [email concealed]> wrote:
>>>
>>> A layered security model.
>>>
>>> If browsers are run as limited users, and you set ACLs on the temp folders
>>> to deny execute permission, etc... You've just prevented most 0day malware.
>>>
>>> Compartmentalization of services limits the scope of compromise. You can
>>> limit the priveleges of older software by running their services as
>>> NetworkService or LocalService instead of LocalSystem.
>>>
>>> There are thousands of ways, but you need to define a scope and
>>> environment.
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate. We look at how SSL works, how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.
> try to be aware of them
>
> Envoyé à partir de mon Windows Phone
> De : MichaÅ? PurzyÅ?ski
> Envoyé : 22/05/2012 17:20
> Ã? : sjalex (at) taidri (dot) com [email concealed]
> Cc : synja (at) synfulvisions (dot) com [email concealed]; amishra.jsr (at) gmail (dot) com [email concealed];
> listbounce (at) securityfocus (dot) com [email concealed]; security-basics (at) securityfocus (dot) com [email concealed]
> Objet : Re: How to prevent zero day attacks
> Are we talking about some specific systems or just generic techniques?
>
> If generic - you've got some good answeres already. I would add -
> segment your networking. Assume every system will be owned, sooner or
> later - and plan for it. Local firewall is nice, but when (not if)
> someone will get "root/Administrator" access he will bypass it anyway.
> Inwest into good network design, think - what could i do, as the
> attacker, after taking this machine? How would i extend my attack?
> Don't waste your time & money on yet another "innovative" way of
> signature based detection. Are layer 2 attacks possible in your setup,
> after one of the machines been taken over? What about access to
> another machines in your network - how much easier it will be to
> extend the attack?
> If we're talking about some speficic systems, enumerate them.
>
> Windows - learn how to use EMET. Btw - i am aware of that "here's
> another way to bypass EMET". Most, if not all of them are build up on
> a bad assumption - like, the process beeing attacked has full
> Administrator/Local System privileges, with write access to debug
> registers. If your MSSQL can do that - you aready have a bigger
> problem.
EMET is a nice tool (I don't hear it mentioned too often. Another neat
one is BinScope, which allows you to examine platform security
integration, such as ASLR and DEP.
> Do not trust defaults. Run services into separate accounts and give
> them only what they need. Same goes for user applications, as someone
> has pointed out already. Get some _kernel_ enforced software that can
> whitelist binaries that can be run. Use build-in things in Windows,
> like (parts of, at least) MAC and MIC (Mandatory Access Control and
> Mandatory Integrity Control, if anyone wonders).
So much for "Secure Out of the Box".
> Linux - learn how to use PaX in a right way. How to make your
> executables into proper PIE. Learn some MAC system and use it - RSBAC,
> for example. Â Or Grsec RBAC.
Don't hold your breathe for --noexec-heap (unless its a hardend
distribution). Checksec is a good tool to audit binaries for this.
> 0-days aren't some kind of black magic, that if it's done to your
> servers will make them all turn into kitten-killing-zombies. They are
> ordinary exploits - made by people who know a lot more than you. Use
> exploit mittigation techniques.
According to Verizon Data Breach Report, most breaches are not 0-day,
which probably makes them closer to 90-day, 6-month-dat, or
Forever-day.
> After all, there's not much you can do on Linux system, with PaX, with
> PIE binaries, NX + full ASLR enforced, with mprotect() restrictions.
> Unless you have some information leak in application _before_ it is
> exploited, that's it.
ROP anyone? I understand a new iPhone break for iOS 5.1 will be out shortly ;)
http://www.redmondpie.com/jailbreak-5.1-untethered-successfully-complete
d-by-pod2g-on-iphone-4/
Jeff
> On May 22, 2012, at 5:32 PM, Stephanus J Alex Taidri wrote:
>
>> Seconded to Rob....
>>
>> Limit the OS to run with least privilege as possible instead of
>> granting administrator access to normal user.
>> This is common for Linux OS, Mac OS and Windows 7 onwards to have apps
>> running with normal user privilege and required User Access Control
>> (UAC) to confirmed any changes that required root/admin privilege.
>>
>> Train the end-users to not simply ignore any UAC pop-up window(s), to
>> read carefully and understand it well before accepting the action
>> requested. If in doubt, always train end-users to choose No/Reject as
>> usually there's less harm to do this.
>>
>> Kind regards,
>> SJ Alex Taidri
>>
>> On Tue, May 22, 2012 at 11:10 PM, <synja (at) synfulvisions (dot) com [email concealed]> wrote:
>>>
>>> A layered security model.
>>>
>>> If browsers are run as limited users, and you set ACLs on the temp folders
>>> to deny execute permission, etc... You've just prevented most 0day malware.
>>>
>>> Compartmentalization of services limits the scope of compromise. You can
>>> limit the priveleges of older software by running their services as
>>> NetworkService or LocalService instead of LocalSystem.
>>>
>>> There are thousands of ways, but you need to define a scope and
>>> environment.
------------------------------------------------------------------------
Securing Apache Web Server with thawte Digital Certificate
In this guide we examine the importance of Apache-SSL and who needs an SSL certificate. We look at how SSL works, how it benefits your company and how your customers can tell if a site is secure. You will find out how to test, purchase, install and use a thawte Digital Certificate on your Apache web server. Throughout, best practices for set-up are highlighted to help you ensure efficient ongoing management of your encryption keys and digital certificates.
http://www.dinclinx.com/Redirect.aspx?36;4175;25;1371;0;5;946;e13b6be442
f727d1
------------------------------------------------------------------------
[ reply ]