Remote Desktop - How to access the remote drive locally ?

Hello All,

I would like to copy some files to and from the Remote Desktop connected
computer to the local one. Point is that I want to share the remote drive
with the local computer, not the other way around (local drive sharing with
remote computer).

How do I do this ? Google only seems to have info about the latter
method.

If that is not possible, is there any way to limit the remote computer in
what it can access on the local one (like only giving it access to a single
folder) ?

Regards,
Rudy Wieser

Ron,

File sharing, if you're on the same LAN.

Yeah, I also thought of that one. Apart from the LAN requirement, not the
solution I was looking for. The fewer services active and ports open to
the outside world the better. Apart from having to deal with enabeling and
disabeling that extra service seperatily every time.

Regards,
Rudy Wieser


-- Origional message:
Ron Hardin schreef in berichtnieuws
...
R.Wieser wrote:

Hello All,

I would like to copy some files to and from the Remote Desktop connected
computer to the local one. Point is that I want to share the remote
drive
with the local computer, not the other way around (local drive sharing
with
remote computer).

How do I do this ? Google only seems to have info about the latter
method.

If that is not possible, is there any way to limit the remote computer
in
what it can access on the local one (like only giving it access to a
single
folder) ?

Regards,
Rudy Wieser

File sharing, if you're on the same LAN.
In My Computer, click a folder, then click Share This Folder.
Ignore the wizard, Just Share Anyway.
You can allow remote write or not.
--


On the internet, nobody knows you're a jerk.

R.Wieser wrote:

Hello All,

I would like to copy some files to and from the Remote Desktop connected
computer to the local one. Point is that I want to share the remote drive
with the local computer, not the other way around (local drive sharing with
remote computer).

How do I do this ? Google only seems to have info about the latter
method.

If that is not possible, is there any way to limit the remote computer in
what it can access on the local one (like only giving it access to a single
folder) ?

Regards,
Rudy Wieser

File sharing, if you're on the same LAN.
In My Computer, click a folder, then click Share This Folder.
Ignore the wizard, Just Share Anyway.
You can allow remote write or not.
--


On the internet, nobody knows you're a jerk.

From: "R.Wieser"

Hello All,

I would like to copy some files to and from the Remote Desktop connected
computer to the local one. Point is that I want to share the remote drive
with the local computer, not the other way around (local drive sharing
with
remote computer).

How do I do this ? Google only seems to have info about the latter
method.

If that is not possible, is there any way to limit the remote computer in
what it can access on the local one (like only giving it access to a
single
folder) ?

Regards,
Rudy Wieser


Just Copy and Paste. That's it. Treat the RDP as a Window and load
whatever Folder on whatever PC you want to copy to or copy from.

Choose the files and/or folders and choose "Copy" then go to the destination
and choose "Paste".

You can't use Drag 'n Drop over RDP.

You can't move, only copy. The source file(s) will not be deleted.

I use this scenario...

Server 2008 Domain behind a NAT Router.

RDP, TCP Port 3389, is Port-Forwarded to Server 2008. Server 2008 has
Firewall Rules to block ingress from networks not allowed RDP access.

Domain Participant computers can be accessed from the Server 2008 via RDP.
Thus I can open a RDP Session with the server then open a RDP session ( from
the POV of the server ) with a Domain Participant computer and I can copy a
file(s) to any of the Domain Participant computers.

NOTE: RDP security has been improved with Vista and above and its another
reasonm to drop XP if you want to use RDP nad take advantage of the
increased data security models.

--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp

David,

Just Copy and Paste. That's it.

I already go the feeling that that might be the only way to do it. Oh well,
if it doesn't go like I want, it has to go as it allows I guess. :-)

I have to say that I find it a bit remarkable, from a security perspective,
that the target, server computer must have access to the local, client
computer to be able to transfer files. If that target computer has any
kind of infection it could (I think) easily (and silently?) infect the
client too.

Regards,
Rudy Wieser


-- Origional message:
David H. Lipman schreef in berichtnieuws
...

Just Copy and Paste. That's it. Treat the RDP as a Window and load
whatever Folder on whatever PC you want to copy to or copy from.

Choose the files and/or folders and choose "Copy" then go to the
destination
and choose "Paste".

You can't use Drag 'n Drop over RDP.

You can't move, only copy. The source file(s) will not be deleted.

I use this scenario...

Server 2008 Domain behind a NAT Router.

RDP, TCP Port 3389, is Port-Forwarded to Server 2008. Server 2008 has
Firewall Rules to block ingress from networks not allowed RDP access.

Domain Participant computers can be accessed from the Server 2008 via RDP.
Thus I can open a RDP Session with the server then open a RDP session
from
the POV of the server ) with a Domain Participant computer and I can copy
a
file(s) to any of the Domain Participant computers.

NOTE: RDP security has been improved with Vista and above and its another
reasonm to drop XP if you want to use RDP nad take advantage of the
increased data security models.

--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp

From: "R.Wieser"

David,

Just Copy and Paste. That's it.

I already go the feeling that that might be the only way to do it. Oh
well,
if it doesn't go like I want, it has to go as it allows I guess. :-)

I have to say that I find it a bit remarkable, from a security
perspective,
that the target, server computer must have access to the local, client
computer to be able to transfer files. If that target computer has any
kind of infection it could (I think) easily (and silently?) infect the
client too.


Huh ?

No. First you can change the XDaemon port from TCP port 3389 to another,
unepected, port. Secondly you should the TCP connection as a tunnel where
the screen, keystrokes, mouse movements, sound, etc., and files travel
through. This tunnel uses encryption and authentication. Malware is not
sophiticated enough to "worm" through RDP. However onnce the tunnel has
been created based upon authentication, it is possible that malware can be
passed through the tunnel. This is a case of what is called the "Insider
Threat" and would exist if you had physical access or RDP access. But, that
is why there are layers and protocols to limit the use of RDP to help
eliminate the threat.

In the client-server model this is always present. RDP is just an extension
of the client-server model.

--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp

David,

Huh ?

Well, this is what it looks to me: The Remote computer is allowed, because
of the necessity of copying, access to a drive on the client machine. As
I've not seen any restrictions to that this means that the remote machine
can read, write and alter anything on that drive.

Now if the remote machine is infected with anything, isn't that (the
attached drive) the perfect place to see if any files/executables can be
found to store some viri-offspring in ?

However onnce the tunnel has been created based upon
authentication, it is possible that malware can be passed
through the tunnel.

Yes, thats always a possibility. But do we really need to open the barn
doors for any viri that are in search for files to infect by giving the
remote machine full access to our/a local drive ?

In other words, its not about which port the data is coming thru, or how
many bits the encryption key is. Its way simpler to exploit than that.

If you know anything that proves me wrong than please do so, as I do now not
at all feel at ease using Remote Desktop.

Regards,
Rudy Wieser


-- Origional message:
David H. Lipman schreef in berichtnieuws
...

Huh ?

No. First you can change the XDaemon port from TCP port 3389 to another,
unepected, port. Secondly you should the TCP connection as a tunnel where
the screen, keystrokes, mouse movements, sound, etc., and files travel
through. This tunnel uses encryption and authentication. Malware is not
sophiticated enough to "worm" through RDP. However onnce the tunnel has
been created based upon authentication, it is possible that malware can be
passed through the tunnel. This is a case of what is called the "Insider
Threat" and would exist if you had physical access or RDP access. But,
that
is why there are layers and protocols to limit the use of RDP to help
eliminate the threat.

In the client-server model this is always present. RDP is just an
extension
of the client-server model.

--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp

From: "R.Wieser"

David,

Huh ?

Well, this is what it looks to me: The Remote computer is allowed, because
of the necessity of copying, access to a drive on the client machine. As
I've not seen any restrictions to that this means that the remote machine
can read, write and alter anything on that drive.

Now if the remote machine is infected with anything, isn't that (the
attached drive) the perfect place to see if any files/executables can be
found to store some viri-offspring in ?

However onnce the tunnel has been created based upon
authentication, it is possible that malware can be passed
through the tunnel.

Yes, thats always a possibility. But do we really need to open the barn
doors for any viri that are in search for files to infect by giving the
remote machine full access to our/a local drive ?

In other words, its not about which port the data is coming thru, or how
many bits the encryption key is. Its way simpler to exploit than that.

If you know anything that proves me wrong than please do so, as I do now
not
at all feel at ease using Remote Desktop.

Regards,
Rudy Wieser


Don't use it then.

--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp

Dave,

Don't use it then.

I rather would have seen you prove my description/explanation false.

As you have not -- and combined with the "get outof my face" type of
response you gave instead -- I must assume that its 1) correct and 2)
something you haven't considered yourself (or, simply wish to ignore).

Regards,
Rudy Wieser


-- Origional message:
David H. Lipman schreef in berichtnieuws
...
From: "R.Wieser"

David,

Huh ?

Well, this is what it looks to me: The Remote computer is allowed,
because
of the necessity of copying, access to a drive on the client machine.
As
I've not seen any restrictions to that this means that the remote
machine
can read, write and alter anything on that drive.

Now if the remote machine is infected with anything, isn't that (the
attached drive) the perfect place to see if any files/executables can be
found to store some viri-offspring in ?

However onnce the tunnel has been created based upon
authentication, it is possible that malware can be passed
through the tunnel.

Yes, thats always a possibility. But do we really need to open the barn
doors for any viri that are in search for files to infect by giving the
remote machine full access to our/a local drive ?

In other words, its not about which port the data is coming thru, or how
many bits the encryption key is. Its way simpler to exploit than that.

If you know anything that proves me wrong than please do so, as I do now
not
at all feel at ease using Remote Desktop.

Regards,
Rudy Wieser


Don't use it then.

--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp

From: "R.Wieser"



Don't use it then.

I rather would have seen you prove my description/explanation false.

As you have not -- and combined with the "get outof my face" type of
response you gave instead -- I must assume that its 1) correct and 2)
something you haven't considered yourself (or, simply wish to ignore).

I am in no mood to disprove nor educate you.
Just the fact you used the made up termininolgy of "viri" shows that you
really do not have a grasp on the "malware" subject matter.
http://linuxmafia.com/~rick/faq/plural-of-virus.html
http://en.wikipedia.org/wiki/Plural_...g_in_-us#Virus

I have been spending a lot of time dealing with actual malware that is being
sent as; XML, DOC and XLS Macro Downlloader trojans deliveriing Dridex and
Hancitor trojans.

Therefore if you have concerns... Don't use it.

If you want to discuss RDP usage and possible ways to secure it, that is a
different matter.



--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp

David,

I am in no mood to disprove nor educate you.

You made that *very* clear, don't worry about that.

Just the fact you used the made up termininolgy of "viri"
shows that you really do not have a grasp on the
"malware" subject matter.

Are you really that much of a snob as to reject people because they do not
speak your exact type of language ? In that case, good riddance.

Or are you simply grasping for the proverbial "stick to hit a dog with"
because mister "does not have a grasp on the subject" has just shown you
something you did not realize yet ?

And by the way: the way how "more than one virus" is blotted down is up for
discussion, with some taking the base word from dead latin, others from as
old greek. Personally I could not care less, as long as the meaning is
conveyed.

Also, English and/or American isn't my first language. Its also quite
possible you would not have the first clue how to write a single flawless
sentence in mine. If language is really what your rejection is all about
(which I sincerely doubt) than take a minute to think about that.

Regards,
Rudy Wieser


-- Origional message:
David H. Lipman schreef in berichtnieuws
...
From: "R.Wieser"



Don't use it then.

I rather would have seen you prove my description/explanation false.

As you have not -- and combined with the "get outof my face" type of
response you gave instead -- I must assume that its 1) correct and 2)
something you haven't considered yourself (or, simply wish to ignore).

I am in no mood to disprove nor educate you.
Just the fact you used the made up termininolgy of "viri" shows that you
really do not have a grasp on the "malware" subject matter.
http://linuxmafia.com/~rick/faq/plural-of-virus.html
http://en.wikipedia.org/wiki/Plural_...g_in_-us#Virus

I have been spending a lot of time dealing with actual malware that is
being
sent as; XML, DOC and XLS Macro Downlloader trojans deliveriing Dridex and
Hancitor trojans.

Therefore if you have concerns... Don't use it.

If you want to discuss RDP usage and possible ways to secure it, that is a
different matter.



--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp

David,

I seem to have terminated my previous message a bit early.

I have been spending a lot of time dealing with actual malware
that is being sent as; XML, DOC and XLS Macro Downlloader
trojans deliveriing Dridex and Hancitor trojans.

Good for you. Now tell me, how is that important for even a simple
virus/trojan horse/malware which only needs to wait for a new drive to
appear and than to access it, looking for files it can write itself into.
Yes, that is how simple it would be. No "worming", "usage of
known-but-yet-unpatched faults" or any other "only known to experts" method
needed.

Therefore if you have concerns... Don't use it.

Thats a decision I will make *after* I've got all the facts, so I can make
an informed one.

Its too bad that you've made clear that you do not want to be part of such a
process, as you seem to consider yourself as knowledgable on this subject.

If you want to discuss RDP usage and possible ways to
secure it, that is a different matter.

All I *really* wanted was to hear that I was wrong in my observation, and no
such problem exists. Maybe even, if it really works that way, to get some
hints as to mitigate it. In short: to be informed.

But no. All you could do was to "attack the messenger". Bad form bub, bad
form.

If you want to discuss RDP usage and possible ways to secure
it, that is a different matter.

Why should I want to do that ? What has that to do with my question about
how to configure my "Remote Desktop" client in a way that would not pose a
threat to my local machine, while still getting the most of it. No, that
"invitation" sounds more like another "get outof my face" kind of
brush-offs.

Regards,
Rudy Wieser


-- Origional message:
David H. Lipman schreef in berichtnieuws
...
From: "R.Wieser"

Don't use it then.

I rather would have seen you prove my description/explanation false.

As you have not -- and combined with the "get outof my face" type of
response you gave instead -- I must assume that its 1) correct and 2)
something you haven't considered yourself (or, simply wish to ignore).

I am in no mood to disprove nor educate you.
Just the fact you used the made up termininolgy of "viri" shows that you
really do not have a grasp on the "malware" subject matter.
http://linuxmafia.com/~rick/faq/plural-of-virus.html
http://en.wikipedia.org/wiki/Plural_...g_in_-us#Virus

I have been spending a lot of time dealing with actual malware that is
being
sent as; XML, DOC and XLS Macro Downlloader trojans deliveriing Dridex and
Hancitor trojans.

Therefore if you have concerns... Don't use it.

If you want to discuss RDP usage and possible ways to secure it, that is a
different matter.

--
Dave
Multi-AV Scanning Tool - http://multi-av.thespykiller.co.uk
http://www.pctipp.ch/downloads/dl/35905.asp

David H. Lipman wrote:
Just the fact you used the made up termininolgy of "viri" shows that you
really do not have a grasp on the "malware" subject matter.

I'd go with "vira." It's second declension neuter.
--


On the internet, nobody knows you're a jerk.