Re: How 2 secure PC-PC data transfer

See below...
On Fri, 2 Oct 2009 05:51:33 -0700 (PDT), Paul <energymover@xxxxxxxxx> wrote:

On Oct 1, 8:37 pm, Joseph M. Newcomer <newco...@xxxxxxxxxxxx> wrote:
See below...

On Thu, 1 Oct 2009 15:23:44 -0700 (PDT), Paul <energymo...@xxxxxxxxx> wrote:
Hi,

Lets face it, IMO there's a good chance any online PC will be silently
hacked one day, and you'll probably never know it. How can I prevent
hackers from ripping off my years of Windows app source code? My
present solution is to use 2 PC's. One offline (contains my code), one
online (for searching and stuff).

****
I use a similar technique; I have one machine that is online and has a LOT of limitations
(the logged-in user 'email' can only access a VERY limited set of resources).  The other
machines are connected to it.  All machines live behind a SonicWall firewall (a nice
machine; it just sits there and runs for years, requiring no attention).  I also disable
ANY ActiveVirus (also called ActiveX) control, and all forms of client-side scripting. Any
executable attachment to an email is removed by my ISP.  I never double-click an email
attachment.

The assumption that you are going to open your machine to attack is one of the worst ideas
that Web designers ever tried to shove down our throats.
****

So I code on the PC that is offline, completely disconnected form the
world, but that's such a pain! Anytime I need to search online to do
something or get some example code, I have to go to my online PC,
search the Internet for sample code, copy files to USB drive, go to my
other PC, put in USB drive, and copy files.

I need a better way! I'm told that connecting a Ethernet cable between
PCs is not that secure. How about a parallel cable? Both of my PCs
have parallel slots, and I have the cable. Is it as simple as plugging
the cable from PC to PC, and writing some simple low level data
transfer code, or does it require hardware?

****
I have no idea what you mean by "not that secure".  Security is not a function of an
Ethernet cable.  Security is a frame of mind, and it starts with firewalls, antivirus
tools, securing your machine against obvious attack vectors, etc.  It means making sure
you don't do stupid things, like allow client-side scripting from unknown sites.  
****

I would have a small app, that I wrote, on both machines, each
listening. On my online PC I would copy text in app textarea box,
click send, and offline PC gets it and places text in a file. All low
level stuff. I could even use a parallel port switch to disconnect
when not in use. Maybe it's a good idea, but I don't know if simply
connecting a parallel port cable from PC to PC will work.

****
The "small app" on your online machine is called an "FTP Server" and the small app on your
client machine is called an "FTP client".  Open source (free) versions of these utilities
are downloadable from a variety of sites.

If you have a front-end software that blocks all incoming FTP requests from the WAN (look
at products like Black Ice), it is safe from random people, and you don't need to write
anything special, because it has already been written.

You are trying to create a complex solution to what is actually a non-problem.  Use the
simple solutions.  That's what I did, and therefore security is no longer a problem I deal
with, because the site is intrinsically secure.

Your approach has been used for years by all kinds of sites; a potentially vulnerable
machine lives outside the "security zone" but it doesn't matter if it is attacked; secure
data lives behind a set of security barriers that do not supply any attack vector.  

My firewall blocks ALL incoming requests.  Every port.  There is *nothing* that I supply
as a service that I want visible to anyone outside my corporate walls.  My Web site is
managed by my ISP, and I therefore have no reason to allow ANY incoming TCP or UDP
connection, so I block them all.  I also block all outgoing requests except to port 80
(HTTP), FTP, SMTP, and NTP (Network Time Protocol).  So even if something gets into my
machine, it can't send anything out.  Since your secure machine has no FTP server, your
online machine can't retrieve anything from it.  If your firewalls reject all WAN
connections and allow only LAN connections, you can't have anyone get to it from outside.

So you can create security without redefining the problem so that the only solution is
hand-rolled code.  The reason I call it a non-problem is that there are commercial,
shareware, and freeware solutions out there already that solve the security problem
without creating new problems to solve.
                                joe
****


There never seems to be an end to MS vulnerabilities. Not that long
ago a hacker could use even an image at a website to hack into your
machine.

The problem with using widely used data transfer software such as ftp
software is that hackers know the protocol and vulnerabilities. If I
built my own simple data transfer protocol to communicate over
parallel port than any existing viruses on my offline machine would
not know how to communicate to the online machine.

The reason for not using Ethernet is some viruses might have the code
to detect if such a cable is connected to another computer, but I
doubt such viruses would bother with parallel ports.

I think hackers want people to use widely used data transfer software.
****
(a) FTP not a "simple data transfer protocol" for very good reasons: the problem is not
simple.
(b) Since your secure site has no FTP server, it cannot be attacked
(c) since your secure site has firewalls that prohibit incoming requests, it cannot be
attacked
(d) since you would never transfer anything insecure to your secure site, it cannot be
attacked
(e) since your insecure site accepts no incoming FTP requests from the WAN, it cannot be
attacked
(f) since your insecure site accepts NO incoming requests from the WAN, it cannot be
attacked
(g) what is a "parallel port"? [When's the last time one of these appeared on a computer?
They don't even appear on printers any longer! None of my machines have them; all my
printers are using network transfers, except two of the smaller ones which are USB].
(h) assuming you have a parallel port, do you have any idea which of the several flavors
it is?
(i) Given you know what kind of parallel port you have, do you have a driver that supports
bidirectional transfer?
(j) if you don't, do you have a clue as to where to find one?
(k) even if someone managed to get an FTP request to you, what would they be able to
retrieve? The FTP server on your insecure site has no access to the files on your secure
site because there is no FTP server on your secure site.
(l) Even if you have an FTP server on your secure site, you would configure it to accept
NO incoming requests, since it would serve no purpose to allow these.
(m) reconfigure your FTP server to use a nonstandard port, and your FTP client to use a
nonstandard port. This adds some additional protection.
(n) what good is it to know if a cable is connected to another computer if the other
computer does not offer any services that can be used as attack vectors?
(o) what good is it to know if a cable is connected to another computer if the firewall on
that other computer prevents any form of connection?

I once had client that insisted "we cannot use TCP/IP because it is not secure" based on
similar misunderstandings of what security means. Their team leader had once heard,
somewhere, that a machine with open TCP/IP ports "could be attacked". By the time they
came to me (with an unrelated problem) they had invested massive $$$ in "inventing their
own" secure protocol using raw sockets and creating packets of their own invention. I
asked them if they had ever tested it outside their lab; the answer was no. So I
convinced them to start testing against their East Coast sales office (they were in CA).
To say the test results were disastrous was to understate the magnitude of the problem.
Nothing worked. Packets got lost. Packets were truncated, so they had to go from a
message protocol to a stream protocol. They did not understand that *every router* along
the path understood TCP/IP protocol, and their own protocols were not supported. Packets
were dropped, or sent redundantly along multiple paths (sort of like UDP). They were not
handling the low-level notification messages coming back from the first-level router,
because these were absorbed in the standard network stack and could not be seen at all.
Downstream failures were not reported at all. They had never heard of VPNs, or SSL, or
any of the other mechanisms for secure transfer over TCP/IP. They were sending
*plaintext* messages containing sensitive (and valuable!) information, which any network
packet sniffer could read! (Somehow, they thought "not using TCP/IP" meant that packet
sniffers wouldn't see their packets).

The guy who invented the idea managed to get me kicked out as a consultant, but
unfortunately I had exposed a set of problems they could not fix. Six months later, he
was out, and six months after that the company disappeared, having used up all its capital
solving nonexistent problems with elaborate and untenable mechanisms, instead of building
product. The product never saw the light of day. (I found this out a few years later at
a trade show, when I handed my card to an exhibitor, who said "Didn't you once consult
for..." and it turned out he was one of their programmers, and told me the whole sad story
of the product demise. He was involved in trying to get the product out, and at the end,
he was the only one working on it because everyone else was diverted into trying to get
the network protocol to work; then they had to try to recover by rewriting everything in
TCP/IP, using SSL, and then they ran out of money)

You have to base security on factual analysis, not random hearsay, folklore, and
unsubstantiated anecdotes. If you do not know what the attack vectors are, how is it you
know your own code is not vulnerable?

You are basing your view on hearsay. If you analyze the problem, you look at where the
vulnerabilities are, and what you have to do to block them. Then you do those things,
which usually take far less effort than inventing your own mechanism.

Remember: the only truly secure computer is turned off, encased in three feet of solid
reinforced concrete, and buried ten feet deep in the middle of an active artillery
practice range. Anything else is a compromise.
joe

Regards,
Paul
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: How many CALs do I need?
    ... > FTP Server: Box will have FTP. ... > 1 login name and password that everyone would share. ... > Secure Web Pages: Our website will have a 'secure' section that you must ... > logging in at any given time, but it will all be under the same account ...
    (microsoft.public.windows.server.sbs)
  • How many CALs do I need?
    ... FTP Server: Box will have FTP. ... login name and password that everyone would share. ... Secure Web Pages: Our website will have a 'secure' section that you must ... logging in at any given time, but it will all be under the same account ...
    (microsoft.public.windows.server.sbs)
  • Re: Ask EU - Norton AV 2006
    ... >>It is true that an attacker could reprogram a network card so that his ... >>knowledge of your network setup before he could construct his attack. ... When you are on a secure site, ... from a "certificate authority" as a means of getting your browser to ...
    (uk.media.radio.archers)
  • Re: My little something...
    ... Its more unlikely that attack on 1024 ECC to subvert it to weaker than ... More secure ofcourse. ... Dont give BS about two cascading ciphers not neccessarely being more ... 10101 as hash. ...
    (sci.crypt)
  • RE: [OT] M$ collaborates with Suse
    ... Most hosting facilities do allow FrontPage and/or FTP access...FrontPage ... Remote Administration to an actual server can be done with a Terminal ... Secure Administration on the inside can be done with Scripting. ... decent free SSH Servers out there for Windows and I like freeSSHd. ...
    (Debian-User)
Loading