Controller security against network hacking?
fogled@mizzou
Posts: 549
Every so often, I get a spate of controller lockups across my campus (10+ Netlinx controllers), and the controller and panel has to be rebooted before the panel will come back online. Right now the controllers are all 'out of the box' condition in terms of security and passwords.
I suspect it's either our network group or a rogue student with access to our wired network doing invasive scanning / hacking. Is there a "best practice" for locking controllers down so they are reasonably secure against hackers? Or should I try to have our networking group firewall the device from everything but the panel and the local and my own remote subnet?
Thanks,
I suspect it's either our network group or a rogue student with access to our wired network doing invasive scanning / hacking. Is there a "best practice" for locking controllers down so they are reasonably secure against hackers? Or should I try to have our networking group firewall the device from everything but the panel and the local and my own remote subnet?
Thanks,
0
Comments
The other issue that shows up in this way is strong wireless interference - are you using MVP panels? If so it might be worth looking around with Netstumbler to see what activity is going on locally.
Surely the network admin, doesn't allow scanning of the network regardless. The password protection on the Masters is unlikly to foil a determined hacker, but it is definately worth deploying if randoms have access to the network, at least it will deter casual browsing of the masters web and telnet interfaces.
I am using one MVP8400 panel. I used to have it running from a discreet WAP, but was experiencing this problem. I finally removed the discreet WAP and got the panel set up on our campus wireless network, and the problem - at least on this system - went away for several months, but has come back. There's a microwave about 15 feet away from the equipment, but there shouldn't be much of anything else in terms of possible wireless interference. Oh, I haven't investigated for new cordless phone handsets yet, either.
I think I may be working at 2 different problems here:
One is a campus-wide, extremely intermittent controller lockup problem. The last time it happened was when our Networking group started a new scanning policy to find and eradicate "unauthorized" devices (discreet hubs, switches, and WAPs) from the network. But just late last week and early this week, I've seen a handful of controller lockups pop back up.
I think this one I'm working on today may have additional problems - likely what Jim noted above, or something similar along those lines, or possibly some other glitch coming from our network system.
Thanks for the tips!
---------------------------------------------------------------------------\par 1: 01-10-2031 FRI 15:59:25 Interpreter \par CIpEvent::OffLine 10001:1:1\par 2: 01-10-2031 FRI 15:59:25 ConnectionManager \par No Ping Response (s=1 d=10001) wait time=30000 mS\par 3: 01-10-2031 FRI 16:48:23 Interpreter \par CIpEvent::OffLine 32001:1:1\par 4: 01-10-2031 FRI 16:46:27 Interpreter \par CIpEvent::OnLine 32001:1:1\par 5: 01-10-2031 FRI 16:46:12 Interpreter \par CIpEvent::OffLine 32001:1:1\par 6: 01-10-2031 FRI 16:12:22 ConnectionManager \par Memory Available = 41632984 <57296>\par 7: 01-10-2031 FRI 16:10:50 ConnectionManager \par Memory Available = 41690280 <14400>\par 8: 01-10-2031 FRI 16:10:49 ConnectionManager \par Memory Available = 41704680 <11808>\par 9: 01-10-2031 FRI 16:10:47 ConnectionManager \par Memory Available = 41716488 <16064>\par 10: 01-10-2031 FRI 16:10:45 ConnectionManager \par Memory Available = 41732552 <77776>\par 11: 01-10-2031 FRI 16:10:37 ConnectionManager \par Memory Available = 41810328 <66208>\par 12: 01-10-2031 FRI 16:10:08 TelnetSvr \par Accepted Telnet connection:socket=32 addr=128.206.58.13 port=50634\par 13: 01-10-2031 FRI 16:09:37 Interpreter \par CIpEvent::OnLine 32001:1:1\par 14: 01-10-2031 FRI 16:04:46 ConnectionManager \par Memory Available = 41876536 <18480>\par 15: 01-10-2031 FRI 16:04:45 ConnectionManager \par Memory Available = 41895016 <25936>\par 16: 01-10-2031 FRI 16:04:35 ConnectionManager \par Memory Available = 41920952 <14816>\par 17: 01-10-2031 FRI 16:04:34 ConnectionManager \par Memory Available = 41935768 <160824>\par 18: 01-10-2031 FRI 16:04:31 ConnectionManager \par Memory Available = 42096592 <13528>\par 19: 01-10-2031 FRI 16:04:31 Unknown \par 16:04:31.749 EVENT Started HttpContext[/]\par 20: 01-10-2031 FRI 16:04:30 ConnectionManager \par Memory Available = 42110120 <79544>\parBTW, I did reset the date / time in the controller. I have no idea how it got so wacked out. Could that contribute to the problem?
Thanks,
You might also want to try going into debug to see if it complains about the program tkn not matching. If that is the case, it's possible someone hijacked your processor
Just a couple thoughts,
Jeff
No complaints about non-matching tokens in Debug. That seems to work OK. I do have code stored on the master. In a big org like this, with me, others, and sometimes outside vendors working on systems, I've been bitten - totally hosed really - by not having the code stored on the master. I'll consider changing that practice, but I want to make sure I've always got good backups of the code somewhere. Any installs I've done in the last year, I've burnt a copy of the code to a CD whenever I change it, and slip the CD in a sleeve in the cabinet. But before that, and before I started doing the AMX programming, it was just luck and pluck whether or not I could even get code to do updates.
I've only seen one problem like this and it was on a system that we were required to use the existing network. I think there were seven or eight masters linked up and one or more were locking up very frequently -- within ten minutes of being put on line. The situation was one of those with a tightly controlled network with managed Cisco switches and no real access to network configuration or information. Just about the only thing we could get from the network people was the IP addresses they wanted us to use and even that was a problem. Typical OCD network people. We tried everything we could think of without success but when we turned off UDP (after stumbling on TN544) we never saw the problem again. Not sure if that was what fixed it or not, but it's probably worth a test.
That made me laugh out loud. Thank you for making my day. And here at MU, yes: not just OCD, but the emotional maturity of 10-year-olds.
And on a serious note, thanks for turning me on to the TN. That shoe fits my problem foot fairly well, I'll definitely wear it.
My old alma matter.
I can't find the actual "set udp bc rate" command in any references anywhere except that TN - not the NetLinx software history or the Netlinx Keywords help, or anywhere else. I would think this command would either go in the DEFINE_START or an ONLINE event for the master, but where is the best place to park this command?
thanks,
The value you set is saved permanently, so it only has to be done once.
Oh... duh. Being a little bit dense of late.
FYI - I updated the master firmware on this unit from 3.21.something to the latest 3.30.371, and the device firmware from 1.12.140 to 1.13.7. So far, the system has not had any more problems since that firmware update.
One more word to the UDP broadcast.
The broadcast is only required if you run a panel in System Setting Mode "Auto".
Auto: panel listens to master UDP broadcast messages, and will connect to a master if the system number set in the system settings matches
URL: panel directly tries to connect to the master URL defined, system number in panel is not considered
Listen: master must try (by an URL list entry) to connect to a panel's url, system number in panel is not considered