Python on a public library computer

Christos TZOTZIOY Georgiou tzot at sil-tec.gr
Tue May 17 10:15:33 EDT 2005


On 14 May 2005 04:21:04 -0700, rumours say that
"anton.vredegoor at gmail.com" <anton.vredegoor at gmail.com> might have
written:

>I'm typing this in a public library on a computer with OS windows 2000
>server. I can run Internet explorer, word, excel and powerpoint, that's
>it. Maybe java, but it seems to be flaky.
>
>I want to run python scripts from this computer.

<snip>

I am not sure I will help you (uncertainty based on the part I snipped),
but the part so far can be easilly solved if you install Python for
single user inside the "Documents and settings\<username>" folder (or
whatever it is called).  I did in a similar case.


End of reply here; and now for some completely minor python success
story.


Some months ago, I happened to be for full workdays at a client's site,
with strict security rules enforced (no domain login == no access even
to web proxy) but I needed to access my company's internal mail server
from my laptop (which I do by ssh forwarding usually).  I could plug in
my laptop to their network, get an address, but that was all (local
network access only).

So I asked permission from an employee there (working on a computer
logged on to the domain) if I could run a putty session with forwarding
enabled.  He said he'd ask their BOFH; now, the BOFH was strictly a
windows person (I somehow connect "strictly-<industry-standard-OS/app>
persons" with lack of resourcefulness, as if these people have 7 bits
per byte :), and he thought that my case was hopeless, since the
employee's account had only access to a web proxy, and CONNECT requests
were only allowed to port 443, but he said ok anyway (in his place, I
wouldn't; but then again, what do I know? ;).

After a call to a colleague in order to redirect connections to port 443
(from the client's network) of an underused computer at my site to port
22, I set up putty to connect through their web proxy, but that didn't
work (since no authentication was given as requested).

Then it was that I downloaded python, installed it in the employee's
documents folder, and created a 'sniffer' between the web browser and
web proxy to find out the authentication headers.  After testing them by
hand, I wrote a script to pretend it's the web browser requesting a
CONNECT from the web proxy, and putty would connect to my script which
would just pass data back and forth.  It didn't work.

I quickly found out that their web proxy did NOT let anything come and
go, unless its client had sent at least 4 octets (and that was also a
security measure they had taken which I was not told about-- they wanted
only protocols where the client talks first, ie (pun intended) typically
HTTP).  So putty was waiting for the ssh server to announce its version
before announcing itself, but the announcement of the server would not
come through until putty sent something.

So I changed the middle-server [midsrv]: as soon as putty connected to
the listening port of midsrv, it opened the connection to the web proxy,
and instantly sent the putty announcement to the ssh server, consuming
it when putty sent it normally, and happily moving octets around for the
rest of the connection.  From my laptop, I could get my emails with
plain POP3.

That was in 34 minutes time (debugging time included).

When the network guy dropped by a couple of hours later to ask me if I
needed any help, I just thanked him for letting me connect.  He
scratched his head, tried to understand what happened (didn't realise
that the python app was important even though he absent-mindedly passed
over it checking running tasks), so I let him think over it for several
minutes before explaining to him what I did.  He was most impressed with
the python program when I showed it to him, gave a warning to the
employee: "ok, run his program, but don't let him touch your computer
again!", and then came to the following conclusion (much similar to a
Python motto):

"If Python can do this, it {Python} should be forbidden..."


PS Unfortunately, I could not charge "security consulting" fees.
-- 
TZOTZIOY, I speak England very best.
"Be strict when sending and tolerant when receiving." (from RFC1958)
I really should keep that in mind when talking with people, actually...



More information about the Python-list mailing list