obviscating python code for distribution

[geremy condra]

On Wed, May 18, 2011 at 10:24 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Thu, May 19, 2011 at 2:54 AM, geremy condra <debatem1 at gmail.com> wrote:
>> On Wed, May 18, 2011 at 12:36 AM, Hans Georg Schaathun <hg at 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