(never posted here before, only watched the announcements: if this topic is inappropriate for this list I apologize in advance)
I'm looking for (preferably) a company, or individual, to attempt to breach a standard config I have created to deploy client applications in production. It is intentionally a minimal config which is tightly locked down and audited daily.
I've never had a security incident with a machine I've managed with debian (I (heart) debian), though I've seen plenty of ssh bruteforce attempts and other script-kiddie and slightly more sophisticated attacks - but never a skilled artisan really trying to get in ;)
I would provide:
-an IP address -a username & password
I would want:
-an attack based on knowing the IP address _only_ -an attack knowing the IP + username & password I provide -a report on findings, with a limited overview of techniques and tools used.
Please send any questions & proposals to me off-list: eni...@turingstudio.com
i'm gonna skip the offlist part and raise some questions/comments just because it's a fun topic to cover and see other folks comments and philosophy - there will never be "one solution for 2-3 people" but will be all different solutions maybe even totally different for each
> I would provide: > -an IP address > -a username & password
> I would want: > -an attack based on knowing the IP address _only_ > -an attack knowing the IP + username & password I provide > -a report on findings, with a limited overview of techniques and tools > used.
lets start with "limited overview tools and techniques" for general security issues ( applies to crackers and defenders )
if you have one of those "apps" in your project, you'd probably want to read lot more about its problems and patches
- to break into a box ... i'm guessing/claiming you want to use "exploit tools"
- and we'll save the otehr gazillion googleplex of other security options to consider for later too
with your "white hat test scenario", that will just show that say, a "generic person" cannot login with uid/pwd ... fairly trivial to stop ... ( a "1 min" solution )
stopping ssh login, or using uid/pwd doesn't prevent others from getting into your machines using some other vulnerability and exploit tools designed to break into the boxes
- i guess i dont understand why knowing the uid/pwd is important to know when doing a "security test", why use that restriction for the "security tests"
script kiddies "tools" are just that, meant for the low lying fruits due to the sheer number of machines out there for ez hits
----
questions for you
- what else is in the goals for the security test, where i'm not using audit, pen-test, assessments and other "security words"
- what is the consequence if some whitehat/grayhat/blackhat/malicioushat does get into the box, what is the process/proceedure/consequences and follow up costs to cleanup vs shutdown/change the product line
c ya alvin
-- To UNSUBSCRIBE, email to debian-security-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
> - what else is in the goals for the security test, > where i'm not > using audit, pen-test, assessments and other > "security words"
> - what is the consequence if some > whitehat/grayhat/blackhat/malicioushat > does get into the box, what is the > process/proceedure/consequences > and follow up costs to cleanup vs shutdown/change > the product line
Perhaps the following questions should be asked first
1. How do we know know Mr Black is who he says he is?
2. How can we confirm the machine details he supplies are actually details of a machine that he owns?
3. How can I prove that he is not actually a skid trying to learn how to crack a debian box (which he has set up) so that he can then go on to crack some he has ssh passwords to after successfully brute forcing some on a network somewhere.
blah, blah, blah.
And for Mr Black.
1. How will you know that whoever replies to your email isn't a lurking cracker. I am sure there are plenty on this list considering the topic.
2. In the event that they are is the machine sufficiently isolated that it being compromised will not affect the rest of your or anyone elses network.
3. Do you have a procedure to wipe the machine after the tests are done in a timely fashion. You asked for a summary of what took place on the machine, perhaps you should be monitoring the activity on the machine yourself.
blah, blah, blah.
H.
__________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs
-- To UNSUBSCRIBE, email to debian-security-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Tue, 1 Nov 2005, Harry wrote: > Perhaps the following questions should be asked first
> 1. How do we know know Mr Black is who he says he is? > 2. How can we confirm the machine details he supplies > are actually details of a machine that he owns?
... all valid points ..
- a face to face meeting is the only way to get started on the "security test" per written contract drawn by a lawyer and signed by the "board of directors"
- all else is asking to be tossed in the local pen with the crazies
- even after the face to face meeting, and seeing the machine to be tested, doesn't mean that after leaving, that the "target" box is still where you saw last
/// paranoia is a good thing when doing some "supposedly" /// not-so-legal activities as it depends on who's view /// and who's authority that you got the "free get-out-of-jail-card"
- lots of fun ...
c ya alvin
-- To UNSUBSCRIBE, email to debian-security-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
----- Original Message ----- From: "Harry" <posti...@yahoo.com> To: <> Sent: Tuesday, November 01, 2005 10:48 AM Subject: Re: whitehat to test a security config
> --- Alvin Oga <a...@mail.Linux-Consulting.com> wrote: >> questions for you
>> - what else is in the goals for the security test, >> where i'm not >> using audit, pen-test, assessments and other >> "security words"
>> - what is the consequence if some >> whitehat/grayhat/blackhat/malicioushat >> does get into the box, what is the >> process/proceedure/consequences >> and follow up costs to cleanup vs shutdown/change >> the product line
> Perhaps the following questions should be asked first
> 1. How do we know know Mr Black is who he says he is?
> 2. How can we confirm the machine details he supplies > are actually details of a machine that he owns?
> 3. How can I prove that he is not actually a skid > trying to learn how to crack a debian box (which he > has set up) so that he can then go on to crack some he > has ssh passwords to after successfully brute forcing > some on a network somewhere.
> blah, blah, blah.
> And for Mr Black.
> 1. How will you know that whoever replies to your > email isn't a lurking cracker. I am sure there are > plenty on this list considering the topic.
> 2. In the event that they are is the machine > sufficiently isolated that it being compromised will > not affect the rest of your or anyone elses network.
> 3. Do you have a procedure to wipe the machine after > the tests are done in a timely fashion. You asked for > a summary of what took place on the machine, perhaps > you should be monitoring the activity on the machine > yourself.
> blah, blah, blah.
> H.
agreed these are all very good questions.
Naraki.
-- To UNSUBSCRIBE, email to debian-security-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
In article <5c69840f54112c46968c22cfc3d3d...@turingstudio.com> you wrote: > I'm looking for (preferably) a company, or individual, to attempt to > breach a standard config I have created to deploy client applications > in production. It is intentionally a minimal config which is tightly > locked down and audited daily.
I think it is very bad efficiency to do black-box testing. Because it requires a very good attacker and much time to find a problem. And if you dont find one, you can't be shure you are secure. It is much better to let the external auditor verify your configuration. Give them access to all config files and documentation, your risk matrix etc. This is much cheaper and much more sucessfull.
Gruss Bernd
-- To UNSUBSCRIBE, email to debian-security-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
On Wed, Nov 02, 2005 at 11:14:22PM +0100, Bernd Eckenfels wrote: > In article <5c69840f54112c46968c22cfc3d3d...@turingstudio.com> you wrote: > > I'm looking for (preferably) a company, or individual, to attempt to > > breach a standard config I have created to deploy client applications > > in production. It is intentionally a minimal config which is tightly > > locked down and audited daily.
> I think it is very bad efficiency to do black-box testing. Because it > requires a very good attacker and much time to find a problem. And if you > dont find one, you can't be shure you are secure. It is much better to let > the external auditor verify your configuration. Give them access to all > config files and documentation, your risk matrix etc. This is much cheaper > and much more sucessfull.
(This is tarting to get off-topic)
You are in someway right: black-box testing does not give you as much coverage of present vulnerabilities than a proper security review
But also somewhat wrong: a black-box test is much cheaper than a full security audit of a system. The main difference is that lots of work in the black-box tests are automated and lots of tools are available to do parts of the job, while a full system security review, including even a source code review if there are in-house applications, demands of more brains, skills and time.
On Fri, Nov 04, 2005 at 01:19:36AM +0100, Javier Fernández-Sanguino Peña wrote: > But also somewhat wrong: a black-box test is much cheaper than a full > security audit of a system.
Well, I guess you mean "port scan". A Tiger Team who helps your security is most often quite expensive cause it takes a lot of attacks - including on-site social engeneering.
To run nessus you do not need to spend any money, thats right.
Gruss Bernd
-- To UNSUBSCRIBE, email to debian-security-REQU...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
