At 10:55 PM 1/12/2009, you wrote:
>Mark Wendt (Contractor) wrote:
> > Realistic? I get messages from my intrusion detectors every day of
> > folks from all over the world scanning my ports, trying to find a way
> > in. They hit a block of IP addresses and scan all of them in that
> > block.
>A ve
Mark Wendt (Contractor) wrote:
> Realistic? I get messages from my intrusion detectors every day of
> folks from all over the world scanning my ports, trying to find a way
> in. They hit a block of IP addresses and scan all of them in that
> block.
A very effective way to stop this is to use d
Realistic? I get messages from my intrusion detectors every day of
folks from all over the world scanning my ports, trying to find a way
in. They hit a block of IP addresses and scan all of them in that
block. One thing you can do is to use tcp wrappers on your IP
stack. Deny everybody but
On Sunday 11 January 2009, Leslie Newell wrote:
> A much more likely scenario is a malicious user trying to mess around
> with a CNC machine that is on the same local network.
Or it could be a curious login user - For anyone interested in system security
and stability, try poing a few hal variabl
Realistic? Chances are exactly 100%. Looking at my linux firewall I see
tons of scans on all kinds of ports every day so chances are they will
scan your system in less than an day if not in few hours or minutes.
I'm not saying you won't get scanned. The point is that very, very few
hacker
Remember, emcrsh is using a Telnet compatible interface but it isn't a
Telnet shell like rsh for example. Something like emcrsh isn't going to
allow anyone to execute code on your machine or read your user or root
passwords.
If you have a port open then a hacker can try accessing it. The worst
Hi Leslie,
Leslie Newell wrote:
> Let's be realistic about this. What are the chances of a hacker randomly
> scanning IP addresses and ports on the web and finding a running emcrsh
Realistic? Chances are exactly 100%. Looking at my linux firewall I see
tons of scans on all kinds of ports every
On Sunday 11 January 2009, Stephen Wille Padnos wrote:
>Rafael Skodlar wrote:
>>[snip]
>>
>>It's safer to use more secure methods for communicating between the
>>systems on the network from the beginning rather than trying to fix it
>>later. You newer know when next newbie will put your code on the
Rafael Skodlar wrote:
>[snip]
>
>It's safer to use more secure methods for communicating between the
>systems on the network from the beginning rather than trying to fix it
>later. You newer know when next newbie will put your code on the system
>and then bad things might happen. Just my experienc
On Sun, 2009-01-11 at 19:28 +, Leslie Newell wrote:
> Let's be realistic about this. What are the chances of a hacker randomly
> scanning IP addresses and ports on the web and finding a running emcrsh
> session? Even if one did, what is the likelihood of him then recognizing
> the connectio
Eric,
Eric H. Johnson wrote:
> Rafael,
>
> As the author of that particular interface, my main objectives were:
>
> 1> As simple a network interface as possible.
>
> 2> An interface that does not change with each version of EMC.
>
> I don't see how it could be much simpler than this. All one h
Let's be realistic about this. What are the chances of a hacker randomly
scanning IP addresses and ports on the web and finding a running emcrsh
session? Even if one did, what is the likelihood of him then recognizing
the connection and trying to take over your machine? I'd say you have
probab
Rafael,
As the author of that particular interface, my main objectives were:
1> As simple a network interface as possible.
2> An interface that does not change with each version of EMC.
I don't see how it could be much simpler than this. All one has to do to
work out an interface is to put "loa
Eric H. Johnson wrote:
> Les,
>
> The passwords are passed as plain text, so a determined hacker would not
> have much difficulty sniffing out the passwords. One option for increasing
> security over the Internet is to run the telnet session over an ssh
> connection. That way all transactions will
Les,
The passwords are passed as plain text, so a determined hacker would not
have much difficulty sniffing out the passwords. One option for increasing
security over the Internet is to run the telnet session over an ssh
connection. That way all transactions will be encrypted and it adds an
additi
Les,
That's security by obscurity, and hasn't really worked well
for a good many years. There are port scan and port mapping tools
out there that can read all the ports on your machine in a heartbeat,
and know which ones are open, which ones are closed, and what process
is behind eac
One good security measure is to change the port number. First the hacker
has to find your port then they have to crack the password (obviously
don't use the standard password). Of course that assumes you want to
connect remotely over the internet (why???). Otherwise just block the
port on your
Andrew wrote:
> Hi Guys,
>
> ...It is totally remotable,
> in that you could have a screen with the estop button on it in the US,
> and I could have the cycle start button here in Australia and the
> machine could be in Timbuktu. (Not sure why you would do this, but you
> could if your little he
I don't have any suggestions - the code guys are better in that regard -
butI do have a question - is your pendant project a commercial venture or an
open source that you'll publish somewhere? I'm interested in what you're
doing. Making my own "intelligent" pendant would be appealing (ok, pretty
On Saturday 10 January 2009, Alex Joni wrote:
> > Remove the 'queue' type from the emcError buffer line in your *.nml
> > config.
>
> Removing the 'queue' type might lead to problems, as more than one error
> messages won't get stored.
> Any subsequent error messages will overwrite existing ones in
> Remove the 'queue' type from the emcError buffer line in your *.nml
> config.
Removing the 'queue' type might lead to problems, as more than one error
messages won't get stored.
Any subsequent error messages will overwrite existing ones in the channel.
Currently task and iocontrol are 2 exampl
On Saturday 10 January 2009, Leslie Newell wrote:
> The problem is that the messages are deleted once they have been read.
> In most cases the GUI will get the messages because it is polling them
> quite frequently. By the time emcrsh gets there they have been swallowed
> by the gui.
>
> Unfortunat
Hi Andrew,
The problem is that the messages are deleted once they have been read.
In most cases the GUI will get the messages because it is polling them
quite frequently. By the time emcrsh gets there they have been swallowed
by the gui.
Unfortunately to change this would require a major redes
23 matches
Mail list logo