Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #5462 > unrolled thread

Re: obviscating python code for distribution

Back to article view | Back to comp.lang.python

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: obviscating python code for distribution Daniel Kluev <dan.kluev@gmail.com> - 2011-05-16 13:21 +1100
    Re: obviscating python code for distribution "Rhodri James" <rhodri@wildebst.demon.co.uk> - 2011-05-16 23:42 +0100
      Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-18 08:36 +0100
        Re: obviscating python code for distribution Dotan Cohen <dotancohen@gmail.com> - 2011-05-18 17:42 +0300
        Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-18 09:54 -0700
          Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-18 18:33 +0100
            Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-18 12:07 -0700
              Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-18 20:56 +0100
                Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-18 14:34 -0700
                  Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-19 06:21 +0100
                    Re: obviscating python code for distribution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-19 08:47 +0000
                      Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-19 10:16 +0100
                    Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-19 10:23 -0700
                      Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-19 19:23 +0100
                        Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-19 17:56 -0700
                          Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-20 05:48 +0100
                            Re: obviscating python code for distribution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-20 07:04 +0000
                              Re: obviscating python code for distribution Hans Georg Schaathun <hg@schaathun.net> - 2011-05-20 09:54 +0100
                              Re: obviscating python code for distribution harrismh777 <harrismh777@charter.net> - 2011-05-20 15:24 -0500
                                Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-20 15:45 -0700
                                  Re: obviscating python code for distribution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-21 00:54 +0000
                                    Re: obviscating python code for distribution harrismh777 <harrismh777@charter.net> - 2011-05-20 23:26 -0500
                          Re: obviscating python code for distribution Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2011-05-20 07:10 +0000
                            Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-20 09:26 -0700
                            Re: obviscating python code for distribution Nobody <nobody@nowhere.com> - 2011-05-20 18:48 +0100
                        Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-20 11:33 +1000
                        Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-19 19:30 -0700
                        Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-20 12:35 +1000
        Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-19 03:24 +1000
          Re: obviscating python code for distribution John Bokma <john@castleamber.com> - 2011-05-18 12:31 -0500
            Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-19 03:52 +1000
        Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-18 10:40 -0700
        Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-19 04:07 +1000
        Re: obviscating python code for distribution "Littlefield, Tyler" <tyler@tysdomain.com> - 2011-05-18 12:26 -0600
          Re: obviscating python code for distribution harrismh777 <harrismh777@charter.net> - 2011-05-18 21:54 -0500
            Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-19 10:50 -0700
              Re: obviscating python code for distribution harrismh777 <harrismh777@charter.net> - 2011-05-20 01:17 -0500
        Re: obviscating python code for distribution Dotan Cohen <dotancohen@gmail.com> - 2011-05-18 21:30 +0300
        Re: obviscating python code for distribution Dotan Cohen <dotancohen@gmail.com> - 2011-05-18 21:31 +0300
        Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-19 04:37 +1000
        Re: obviscating python code for distribution Chris Angelico <rosuav@gmail.com> - 2011-05-19 04:49 +1000
        Re: obviscating python code for distribution geremy condra <debatem1@gmail.com> - 2011-05-18 14:47 -0700

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#5895

On Fri, 20 May 2011 15:45:03 -0700, geremy condra wrote:

> On Fri, May 20, 2011 at 1:24 PM, harrismh777 <harrismh777@charter.net>
> wrote:

>> ... as it goes, De Carte leads his horse into town   ;-)  and having
>> hitched it to the rail outside the local saloon and sauntering up to
>> the bar,  the tender asks, "Would you be hav'in an ale sir?"
>>
>> ... De Carte replies, "I think not..."     ... and then disappeared.
> 
> At risk of being pedantic, I think you mean Descartes rather than De
> Carte.

Being a drunken old fart, I can't imagine Descartes turning down an ale...

http://www.bbc.co.uk/dna/h2g2/A3651545



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#5900

Steven D'Aprano wrote:
>>> ... as it goes, De Carte leads his horse into town;-)    and having
>>> >>  hitched it to the rail outside the local saloon and sauntering up to
>>> >>  the bar,  the tender asks, "Would you be hav'in an ale sir?"
>>> >>
>>> >>  ... De Carte replies, "I think not..."     ... and then disappeared.
>> >
>> >  At risk of being pedantic, I think you mean Descartes rather than De
>> >  Carte.
> Being a drunken old fart, I can't imagine Descartes turning down an ale...
>
> http://www.bbc.co.uk/dna/h2g2/A3651545
>
>

.. .uh, yes...   playing on  'de carte before de horse...'

<sorry>

... as for Steven's link:

     And Rene Descartes was a drunken old fart:
     "I drink, therefore I am",

René Descartes (1596-1650)


I am not sure about Descartes drinking habits, but he was one true 
philosopher and mathematician...  so we honor him... with jokes !


:)


(how many of you guys are they going to be joking about 450 years from 
now ?)

[toc] | [prev] | [next] | [standalone]

#5832

On Thu, 19 May 2011 17:56:12 -0700, geremy condra wrote:

> TL;DR version: large systems have indeed been verified for their
> security properties.

How confident are we that the verification software is sufficiently bug-
free that we should trust their results?

How confident are we that the verification software tests every possible 
vulnerability, as opposed to merely every imaginable one?


-- 
Steven

[toc] | [prev] | [next] | [standalone]

#5858

On Fri, May 20, 2011 at 12:10 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> On Thu, 19 May 2011 17:56:12 -0700, geremy condra wrote:
>
>> TL;DR version: large systems have indeed been verified for their
>> security properties.
>
> How confident are we that the verification software is sufficiently bug-
> free that we should trust their results?

Pretty confident. Most formal verification systems are developed in
terms of a provably correct kernel bootstrapping the larger system.
The important thing is that since that kernel doesn't need to be
complete (only correct) it can typically be easily verified, and in
some cases exhaustively tested. There are also techniques which
generate certificates of correctness for verifiers that aren't
provably correct, but that isn't an area I know much about, and I
don't know if that gets used in practice. The bigger risk is really
that the model you're feeding it is wrong.

> How confident are we that the verification software tests every possible
> vulnerability, as opposed to merely every imaginable one?

Formal provers typically don't work by just throwing a bunch of input
at a piece of software and then certifying it. They take a set of
specifications (the model), a set of assumptions, and the program in
question, and provide a proof (in the mathematical sense) that the
program is exactly equivalent to the model given the assumptions.
Testing the assumptions and model are typically part of the
development process, though, and that's definitely a possible source
of errors.

Geremy Condra

[toc] | [prev] | [next] | [standalone]

#5864

On Fri, 20 May 2011 07:10:45 +0000, Steven D'Aprano wrote:

> How confident are we that the verification software tests every possible 
> vulnerability,

Formal verification is based upon mathematical proof, not empirical
results.

As Dijkstra said: "Program testing can be used to show the presence of
bugs, but never to show their absence".

For complex algorithms, it may be infeasible to cover even all of the
"interesting" cases, let alone a representative sample of all possible
cases. For concurrent (multi-threaded) code, it's often impractical to 
methodically test various interleavings.

[toc] | [prev] | [next] | [standalone]

#5802

On Fri, May 20, 2011 at 10:56 AM, geremy condra <debatem1@gmail.com> wrote:
>> Speaking of reasonable assumptions, one necessary assumption which is
>> particularly dodgy is that whoever deploys and configures it
>> understands all the assumptions and do not break them through ignorance.
>
> Yup. Nothing is safe from idiots.
>

Which means that the assumption really is that you are evaluating a
system, not a bald piece of code. I don't consider that an assumption.
When you're writing code that you will yourself deploy, you take full
responsibility; when you let other people deploy it, they have to take
ultimate responsibility (although they will legitimately expect you to
provide an install script and/or instructions).

There are idiots in this world.
Have you met them?
Met them? I listen to you every week!
-- The Goon Show, and so absolutely true

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#5803

On Thu, May 19, 2011 at 6:33 PM, Chris Angelico <rosuav@gmail.com> wrote:
> On Fri, May 20, 2011 at 10:56 AM, geremy condra <debatem1@gmail.com> wrote:
>>> Speaking of reasonable assumptions, one necessary assumption which is
>>> particularly dodgy is that whoever deploys and configures it
>>> understands all the assumptions and do not break them through ignorance.
>>
>> Yup. Nothing is safe from idiots.

I actually think I need to take this statement back. The more I think
about it, the less convinced I am that it's correct- I can at least
conceive of violable systems which cannot be misconfigured. So, sorry
about that.

> Which means that the assumption really is that you are evaluating a
> system, not a bald piece of code. I don't consider that an assumption.
> When you're writing code that you will yourself deploy, you take full
> responsibility; when you let other people deploy it, they have to take
> ultimate responsibility (although they will legitimately expect you to
> provide an install script and/or instructions).

Sure, although I would personally still call it an assumption.

Geremy Condra

[toc] | [prev] | [next] | [standalone]

#5804

On Fri, May 20, 2011 at 12:30 PM, geremy condra <debatem1@gmail.com> wrote:
>> On Fri, May 20, 2011 at 10:56 AM, geremy condra <debatem1@gmail.com> wrote:
>>> Yup. Nothing is safe from idiots.
>
> I actually think I need to take this statement back. The more I think
> about it, the less convinced I am that it's correct- I can at least
> conceive of violable systems which cannot be misconfigured. So, sorry
> about that.

If it is, then you're not deploying it, you're just pushing buttons
and acting like a user. I still stand by the view that the one with
the root password is the one responsible for the computer's security;
and if you have the root filesystem password, there's no way that
something can be made unmisconfigurable. (You CAN, however, make
something that's out-of-the-box secure, so someone just does a 'sudo
apt-get install yoursystem' and it's specced up nicely. This is a Good
Thing.)

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#5709

On Thu, May 19, 2011 at 2:54 AM, geremy condra <debatem1@gmail.com> wrote:
> On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun <hg@schaathun.net> wrote:
>> But then, nothing is secure in any absolute sense.
>
> If you're talking security and not philosophy, there is such a thing
> as a secure system. As a developer you should aim for it.

Agreed. Things can be secure if you accept caveats. A good server
might be secure as long as attackers cannot, say:
* Get physical access to the server, remove the hard disk, and tamper with it
* Hold a gun to the developer and say "Log me in as root or you die"
* Trigger a burst of cosmic rays that toggle some bits in memory

If someone can do that, there's really not much you can do to stop
them. But you CAN make a system 100% secure against network-based
attacks.

Denial of service attacks are the hardest to truly defend against, and
if your level of business is low enough, you can probably ignore them
in your code, and deal with them by human ("Hmm, we seem to be getting
ridiculous amounts of traffic from XX.YY.ZZ.*, I think I'll put a
temporary ban on that /24"). Although some really nasty DOSes can be
blocked fairly easily, so it's worth thinking about them.

But mainly: Don't panic about the really really obscure attack
possibilities, the ones that would only happen if someone with a lot
of resources is trying to bring you down. Just deal with the obvious
stuff - make sure your server cannot be compromised via a standard
network connection.

Test your server by connecting with a basic TELNET client (or a
hacked-up client, if it uses a binary protocol). Test your client by
connecting it to a hacked-up server. Make sure you can't muck up
either of them. Assume that any attacker will know every detail about
your comms protocol, because chances are he will know most of it.

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#5711

Chris Angelico <rosuav@gmail.com> writes:

> On Thu, May 19, 2011 at 2:54 AM, geremy condra <debatem1@gmail.com> wrote:
>> On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun <hg@schaathun.net> wrote:
>>> But then, nothing is secure in any absolute sense.
>>
>> If you're talking security and not philosophy, there is such a thing
>> as a secure system. As a developer you should aim for it.
>
> Agreed. Things can be secure if you accept caveats. A good server
> might be secure as long as attackers cannot, say:
> * Get physical access to the server, remove the hard disk, and tamper with it
> * Hold a gun to the developer and say "Log me in as root or you die"
> * Trigger a burst of cosmic rays that toggle some bits in memory

You forgot the most important one:

* if none of the software running on it has exploitable issues

Personally, I think it's best to understand that no server is ever
secure and hence one must always be prepared that a breach can happen.

-- 
John Bokma                                                               j3b

Blog: http://johnbokma.com/        Perl Consultancy: http://castleamber.com/
Perl for books:    http://johnbokma.com/perl/help-in-exchange-for-books.html

[toc] | [prev] | [next] | [standalone]

#5713

On Thu, May 19, 2011 at 3:31 AM, John Bokma <john@castleamber.com> wrote:
>> Agreed. Things can be secure if you accept caveats. A good server
>> might be secure as long as attackers cannot, say:
>> * Get physical access to the server, remove the hard disk, and tamper with it
>> * Hold a gun to the developer and say "Log me in as root or you die"
>> * Trigger a burst of cosmic rays that toggle some bits in memory
>
> You forgot the most important one:
>
> * if none of the software running on it has exploitable issues

That's not a caveat. That's a purposeful and deliberate goal. And far
from impossible.

> Personally, I think it's best to understand that no server is ever
> secure and hence one must always be prepared that a breach can happen.

You need to balance the risk of a breach against the effort it'd take
to prevent. See my comments re DOS attacks; it's not generally worth
being preemptive with those, unless you're at a way higher transaction
level than this discussion is about (for those who came in late, it's
a basic network game, and not Google Docs or the DNS root servers or
something). If it's going to impose 500ms latency on all packets just
to prevent the one chance in 1E50 that you get some particular attack,
then it's really not worthwhile. However, it IS possible to ensure
that the server doesn't, for instance, trust the client; those
extremely basic protections are well worth the effort (even if it
seems like a lot of effort).

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#5712

On Wed, May 18, 2011 at 10:24 AM, Chris Angelico <rosuav@gmail.com> wrote:
> On Thu, May 19, 2011 at 2:54 AM, geremy condra <debatem1@gmail.com> wrote:
>> On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun <hg@schaathun.net> wrote:
>>> But then, nothing is secure in any absolute sense.
>>
>> If you're talking security and not philosophy, there is such a thing
>> as a secure system. As a developer you should aim for it.
>
> Agreed. Things can be secure if you accept caveats. A good server
> might be secure as long as attackers cannot, say:
> * Get physical access to the server, remove the hard disk, and tamper with it
> * Hold a gun to the developer and say "Log me in as root or you die"
> * Trigger a burst of cosmic rays that toggle some bits in memory

Just a note: you can do many cool things to prevent the last from
working, assuming you're talking about RSA fault injection attacks.

> If someone can do that, there's really not much you can do to stop
> them. But you CAN make a system 100% secure against network-based
> attacks.
>
> Denial of service attacks are the hardest to truly defend against, and
> if your level of business is low enough, you can probably ignore them
> in your code, and deal with them by human ("Hmm, we seem to be getting
> ridiculous amounts of traffic from XX.YY.ZZ.*, I think I'll put a
> temporary ban on that /24"). Although some really nasty DOSes can be
> blocked fairly easily, so it's worth thinking about them.
>
> But mainly: Don't panic about the really really obscure attack
> possibilities, the ones that would only happen if someone with a lot
> of resources is trying to bring you down. Just deal with the obvious
> stuff - make sure your server cannot be compromised via a standard
> network connection.

Just one caveat I would add to this: make sure you're drawing this
line at the correct place. If your attack model is wrong things have a
tendency to drop from 'impossible' to 'laughably easy' in a hurry.

> Test your server by connecting with a basic TELNET client (or a
> hacked-up client, if it uses a binary protocol). Test your client by
> connecting it to a hacked-up server. Make sure you can't muck up
> either of them. Assume that any attacker will know every detail about
> your comms protocol, because chances are he will know most of it.

I actually like to use scapy a lot. It's a little slow, but you can
really get down deep and still feel sort of sane afterwards, and it
makes it easier on you if you don't need to go all the way to the
metal.

Geremy Condra

[toc] | [prev] | [next] | [standalone]

#5716

On Thu, May 19, 2011 at 3:40 AM, geremy condra <debatem1@gmail.com> wrote:
> Just a note: you can do many cool things to prevent the last from
> working, assuming you're talking about RSA fault injection attacks.

Sure. Each of those caveats can be modified in various ways; keeping
checksums of everything in memory, encrypting stored data with
something that isn't stored on that computer, etc, etc, etc. But in
terms of effort for gain, it's not usually worth it. However, it is a
good idea to be aware of your caveats; for instance, are you aware
that most Linux systems will allow a root login from another file
system (eg a live-boot CD) to access the hard drive read-write,
regardless of file ownership and passwords? (My boss wasn't, and was
rather surprised at how easily it could be done.)

>> But mainly: Don't panic about the really really obscure attack
>> possibilities...
>
> Just one caveat I would add to this: make sure you're drawing this
> line at the correct place. If your attack model is wrong things have a
> tendency to drop from 'impossible' to 'laughably easy' in a hurry.

Absolutely. Sometimes it's worth scribbling comments in your code like:
/* TODO: If someone tries X, it might cause Y. Could rate-limit here
if that's an issue. */
Then, you keep an administrative eye on the production code. If you
start having problems, you can deal with them fast, rather than having
the ridiculous situation of security issues lingering for months or
years before finally getting a band-aid solution.

>> Test your server by connecting with a basic TELNET client...
>
> I actually like to use scapy a lot. It's a little slow, but you can
> really get down deep and still feel sort of sane afterwards, and it
> makes it easier on you if you don't need to go all the way to the
> metal.

Sort of sane? I lost that feeling years ago. :) When I'm working on
Windows, I'll sometimes use SMSniff for packet sniffing, but
generally, I just stick with high level socket services and depend on
the underlying libraries to deal with malformed packets and such. On
Linux, I generally whip up a quick script to do whatever job on the
spot (Python and Pike are both extremely well suited to this), but on
Windows, I use my MUD client, RosMud, which has a "passive mode"
option for playing the part of the server.

Chris Angelico

[toc] | [prev] | [next] | [standalone]

#5720

 >might be secure as long as attackers cannot, say:
You forgot UFOs.
Anyway, again, thanks to everyone for the advice, this is good reading. 
Incidentally, I don't know to much about security. I know about rate 
limiting and dos attacks, as well as some others, but I think there's a 
lot more that I don't know--can someone kind of aim me in the right 
direction for some of this? I want to be able to take techniques, break 
my server and then fix it so that can't be done before I head to public 
with this.

[toc] | [prev] | [next] | [standalone]

#5759

Littlefield, Tyler wrote:
> I know about rate limiting and dos attacks, as well as some others, but
> I think there's a lot more that I don't know--can someone kind of aim me
> in the right direction for some of this? I want to be able to take
> techniques, break my server and then fix it so that can't be done before
> I head to public with this.

Black-hat and gray-hat papers are some of the best resources; and 
entertaining ta-boot...

Four resources that you will what to look into, in no particular order:

Erickson, Jon, "Hacking: The Art of Exploitation," 2nd ed,
	San Francisco: No Starch Press, 2008.


Anonymous, "Maximum Linux Security: A Hacker's Guide to Protecting
	Your Linux Server and Workstation," Indianapolis:
	Sams Publishing, 2000.
	
	(check for other editions)
	(this volume is a good read, even for other platforms,
		but is geared specifically to Linux)


Graves, Kimberly, "CEH Certified Ethical Hacker: Study Guide,"
	Indianapolis: Wiley Publishing, 2010.


Seitz, Justin, "Gray Hat Python: Python Programming for Hackers
	and Reverse Engineers," San Francisco: No Starch Press, 2009.


      The best way to protect your system is first to be able to 
understand how someone else will attempt to compromise it.

      I personally am an *ethical* hacker; by definition, I exploit 
possibilities, for problem solving, and I cause *NO* harm.  Having said 
that, I have studied *all* of the techniques employed in the field for 
causing harm; why? Because that is the *only* way to know how to defend 
against them.

      Its like missile anti missile...    virus anti virus, and the 
like. Because *all* of software is mathematical by nature it is not 
possible to lock software with software... this is partially the 
decidability problem at work. But mostly its a matter of their skills 
getting better... yours better be better yet, and when they get even 
better than you---  well you better be ready to improve ... and on and 
on it goes... But, first you need to understand what you're up against.

      There is absolutely *no* way to prevent reverse engineering. Its 
all just code, and that code can be unraveled with the right math and 
enough time. (time and talent is all it takes; that and the will to be 
tenacious and uncompromising. If someone wants your system badly enough, 
they will own it... its just a matter of time... so be ready for it... 
like the Bible says, "If the master of the house knew what hour the 
thief would break in and steal, he would have kept better watch on his 
house!"



kind regards,
m harris

[toc] | [prev] | [next] | [standalone]

#5780

On Wed, May 18, 2011 at 7:54 PM, harrismh777 <harrismh777@charter.net> wrote:
> Littlefield, Tyler wrote:

<snip>

> Four resources that you will what to look into, in no particular order:
>
> Erickson, Jon, "Hacking: The Art of Exploitation," 2nd ed,
>        San Francisco: No Starch Press, 2008.

This would be a very good choice. It's a bit light on details, but
makes up for it by being exceptionally well-written and very
accessible.

> Anonymous, "Maximum Linux Security: A Hacker's Guide to Protecting
>        Your Linux Server and Workstation," Indianapolis:
>        Sams Publishing, 2000.
>
>        (check for other editions)
>        (this volume is a good read, even for other platforms,
>                but is geared specifically to Linux)

This is a good volume, but very dated. I'd probably pass on it.

> Graves, Kimberly, "CEH Certified Ethical Hacker: Study Guide,"
>        Indianapolis: Wiley Publishing, 2010.

Briefly glancing over the TOC, this actually looks surprisingly good.
CEH itself is a joke among black hats, but if this gets down to the
nitty-gritty of actually performing the attacks it covers it sounds
like a buy.

> Seitz, Justin, "Gray Hat Python: Python Programming for Hackers
>        and Reverse Engineers," San Francisco: No Starch Press, 2009.

I'd skip this one, as it isn't really focused on what you want. The
web application hacker's handbook is probably more along the lines of
what you need, if you're going for a book. There's also an older
volume called 'counter hack' that gives a good overview of some of the
ways that attacks proceed.

Another recommend I'm surprised hasn't popped up already: 'security
power tools' is a good way to get your foot in the door. It has a
practical, no-nonsense approach and is split into self-contained
chapters so you don't waste too much of your time on tools that aren't
relevant to you.

Geremy Condra

[toc] | [prev] | [next] | [standalone]

#5819

geremy condra wrote:
>> Anonymous, "Maximum Linux Security: A Hacker's Guide to Protecting
>> >          Your Linux Server and Workstation," Indianapolis:
>> >          Sams Publishing, 2000.

> This is a good volume, but very dated. I'd probably pass on it.

Actually, although dated, its still a very good manual for concepts, and 
much of it... believe it or not... is still just as valid as the day it 
was written.

Some things of course have changed, like web security and protocols.

Some of the linux admin stuff has now been automated with reasonable 
defaults, *but not all*...

Appendix D is good-- additional resources bibliography !

Maybe try to buy or borrow a used copy [ or just skip it... ]


PS   I really have hoped that Anonymous would be putting out a second 
edition, but I can't find it... so not yet...


kind regards,
m harris

[toc] | [prev] | [next] | [standalone]

#5721

On Wed, May 18, 2011 at 20:24, Chris Angelico <rosuav@gmail.com> wrote:
>  But you CAN make a system 100% secure against network-based
> attacks.
>

Only by unplugging the network cable. This is called an air gap, and
is common in military installations. Anything with a cable plugged in
is hackable.

-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

[toc] | [prev] | [next] | [standalone]

#5722

On Wed, May 18, 2011 at 20:24, Chris Angelico <rosuav@gmail.com> wrote:
> Denial of service attacks are the hardest to truly defend against, and
> if your level of business is low enough, you can probably ignore them
> in your code, and deal with them by human ("Hmm, we seem to be getting
> ridiculous amounts of traffic from XX.YY.ZZ.*, I think I'll put a
> temporary ban on that /24"). Although some really nasty DOSes can be
> blocked fairly easily, so it's worth thinking about them.
>

The python code should not be concerned with DDoS, that is what
iptables is for. Remember, never do in code what Linux will do for
you.


-- 
Dotan Cohen

http://gibberish.co.il
http://what-is-what.com

[toc] | [prev] | [next] | [standalone]

#5724

On Thu, May 19, 2011 at 4:31 AM, Dotan Cohen <dotancohen@gmail.com> wrote:
> The python code should not be concerned with DDoS, that is what
> iptables is for. Remember, never do in code what Linux will do for
> you.

In general, yes. Denial of service is a fairly broad term, though, and
if there's a computationally-expensive request that a client can send,
then it may be worth rate-limiting it. Or if there's a request that
causes your server to send out inordinate amounts of data, and you're
running it on a typical home internet connection, then that's a DOS
vector too. So it's not only an iptables issue.

But yes. The "system" is the entire system, not just the Python code
you're writing.

ChrisA

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.python

csiph-web