It may have worked years ago before telcos started switching everything to digital, but the security industry is so far behind in communications technology, it's staggering.
Modern panels still have 2400 baud phone connections. If you're lucky enough to get a panel with an ethernet connection, it's 10mbit and still only an analog to digital converter so communication is still limited to 2400bps.
The constant conversion between analog and digital and back wreaks havoc for reliable data transfer, both when trying to report an alarm (like a burglary alarm) and when trying to do remote programming to the panel.
Shit, the #1 programming software for Honeywell alarm panels still doesn't support the scrollwheel on mice.
Are we talking card access systems or other types of security systems? Because screw any of either of those that don't have Ethernet controllers built in.
Also I'm starting to see some of your possible frustrations with Doors.Net, but I'm still finding most of these have some roots in user error.
donavannj on
0
TL DRNot at all confident in his reflexive opinions of thingsRegistered Userregular
A certain former mayor of NYC will join the Trump administration in order to 'share his expertise and insight on cyber-security matters.'
Look, anonymous binds are ok. If anonymous binds consider me and asset I think that's a win for all of us.
I mean anonymous binds are very smart and what do we know when computers are involved anyway?
Seidkona on
Mostly just huntin' monsters.
XBL:Phenyhelm - 3DS:Phenyhelm
+1
RandomHajileNot actually a SnatcherThe New KremlinRegistered Userregular
About mid-way through my 12-year time in this job, I got an urgent call from one of the plants about a DOS machine running a homegrown QBasic program for river temperature tracking. Next to it, there was a sheet of instructions on how to back up the program/data to floppy disk weekly. Guess how often they had done that (spoiler, never). Now, a little bit on this program: it needs the average river temperature for the entire previous year, the average for the same month of the previous year, and the data for the same day of the previous year. Oh, did I mention that it is hourly data entered manually? "Luckily" I guess, they also saved the printed versions of this data just in case. Also luckily, I had previously taught a QB class at a local community college, so I fixed the program to save to a network drive and print to a network printer via LPT1 on an XP machine. (And a couple minor date bugs that the guy who wrote it--chemical engineer--left in.) Anyway, they paid a temp to come in and type in the entire previous year up to the current date. And I'm pretty sure that program is still running in an XP Mode VM on that clerk's Win 7 PC. Man, I'll have to check.
dollars to donuts the admin password is p4ssw0rd or some variation of that
not a doctor, not a lawyer, examples I use may not be fully researched so don't take out of context plz, don't @ me
+2
jungleroomxIt's never too many graves, it's always not enough shovelsRegistered Userregular
edited January 2017
Our software updates are a pain.
It's like this: first we have to transfer the files via vpn tunnel. This is a security thing, I suppose.
Then we have an installer system that uses a local and distant service to put the new files in place and NGEN the shit to death.
Then, we run some scripts manually (they do need to be adjusted per bank, something that's thankfully going away soon).
Then we turn on the services and test.
It sucks but eh, I've had worse... except when some jackass decides they need to "hop on real quick" and screws the pooch on the entire process.
Some guy, right after the banks sysop told everyone to log off, got back on the teller station to "check something out", and started an .exe that we needed to remain dormant until we were done.
So, instead of 30 minutes, we had to spend 30 just restoring the database and then 30 minutes reconfiguring the components (mostly cfgs) and THEN 30 minutes installing it.
Thankfully we got the guys name and reported him to the president of the bank. His tone told me everything I needed to hear about how it was about to be handled.
It may have worked years ago before telcos started switching everything to digital, but the security industry is so far behind in communications technology, it's staggering.
Modern panels still have 2400 baud phone connections. If you're lucky enough to get a panel with an ethernet connection, it's 10mbit and still only an analog to digital converter so communication is still limited to 2400bps.
The constant conversion between analog and digital and back wreaks havoc for reliable data transfer, both when trying to report an alarm (like a burglary alarm) and when trying to do remote programming to the panel.
Shit, the #1 programming software for Honeywell alarm panels still doesn't support the scrollwheel on mice.
Are we talking card access systems or other types of security systems? Because screw any of either of those that don't have Ethernet controllers built in.
Also I'm starting to see some of your possible frustrations with Doors.Net, but I'm still finding most of these have some roots in user error.
Burglary alarm panels (and fire alarm panels, too).
Doors.NET is passable if all you have to do is user management. If you have to do things like time schedules or anything mildly advanced, it's convoluted as fuck.
It's like this: first we have to transfer the files via vpn tunnel. This is a security thing, I suppose.
Then we have an installer system that uses a local and distant service to put the new files in place and NGEN the shit to death.
Then, we run some scripts manually (they do need to be adjusted per bank, something that's thankfully going away soon).
Then we turn on the services and test.
It sucks but eh, I've had worse... except when some jackass decides they need to "hop on real quick" and screws the pooch on the entire process.
Some guy, right after the banks sysop told everyone to log off, got back on the teller station to "check something out", and started an .exe that we needed to remain dormant until we were done.
So, instead of 30 minutes, we had to spend 30 just restoring the database and then 30 minutes reconfiguring the components (mostly cfgs) and THEN 30 minutes installing it.
Thankfully we got the guys name and reported him to the president of the bank. His tone told me everything I needed to hear about how it was about to be handled.
Tl;dr: fuck users God I hate them
tbf, if your process allows for user fuckup like that, it's your own fault.
It's like this: first we have to transfer the files via vpn tunnel. This is a security thing, I suppose.
Then we have an installer system that uses a local and distant service to put the new files in place and NGEN the shit to death.
Then, we run some scripts manually (they do need to be adjusted per bank, something that's thankfully going away soon).
Then we turn on the services and test.
It sucks but eh, I've had worse... except when some jackass decides they need to "hop on real quick" and screws the pooch on the entire process.
Some guy, right after the banks sysop told everyone to log off, got back on the teller station to "check something out", and started an .exe that we needed to remain dormant until we were done.
So, instead of 30 minutes, we had to spend 30 just restoring the database and then 30 minutes reconfiguring the components (mostly cfgs) and THEN 30 minutes installing it.
Thankfully we got the guys name and reported him to the president of the bank. His tone told me everything I needed to hear about how it was about to be handled.
Tl;dr: fuck users God I hate them
tbf, if your process allows for user fuckup like that, it's your own fault.
I get to do a 2016 server today. That's mildly exciting.
oooo, That actually interests me. I haven't had a chance to play with it yet.
Yeah I haven't even actually seen it yet. I get the first deployment of it at my company. It's for a tiny 3 user client of ours who just have a single 2011 SBS server doing DC, file, and print, so it's pretty much the best possible case scenario for a first deployment. No exchange, no SQL, they're not using sharepoint or anything crazy off the SBS. Just AD, file & print, DHCP and DNS, and a super small environment.
0
TL DRNot at all confident in his reflexive opinions of thingsRegistered Userregular
It's like this: first we have to transfer the files via vpn tunnel. This is a security thing, I suppose.
Then we have an installer system that uses a local and distant service to put the new files in place and NGEN the shit to death.
Then, we run some scripts manually (they do need to be adjusted per bank, something that's thankfully going away soon).
Then we turn on the services and test.
It sucks but eh, I've had worse... except when some jackass decides they need to "hop on real quick" and screws the pooch on the entire process.
Some guy, right after the banks sysop told everyone to log off, got back on the teller station to "check something out", and started an .exe that we needed to remain dormant until we were done.
So, instead of 30 minutes, we had to spend 30 just restoring the database and then 30 minutes reconfiguring the components (mostly cfgs) and THEN 30 minutes installing it.
Thankfully we got the guys name and reported him to the president of the bank. His tone told me everything I needed to hear about how it was about to be handled.
Tl;dr: fuck users God I hate them
tbf, if your process allows for user fuckup like that, it's your own fault.
Went on site this morning to a client (apartment complex - distributed internet) because a resident didn't have internet access.
Go into the data closet only to find my client switched internet providers and the ISP removed the existing equipment (router, switches) and put in their own. Called the ISP since I know many of the people there and they're like, "Yeah we did that back in early December. They never told you?"
I checked to make sure the run from the apartment to the data closet was good but ultimately told the resident I couldn't help him. Gotta love clients making changes without letting you know.
so after 6 weeks working the new job, I'm finally starting to implement things that were so desperately needed.
- The barely working exchange server is now working properly (next up on that is building the second redundant exchange server)
- Starting Monday I'm moving to differential backups instead of running a full backup of everything every day. Final straw on that was they got me to add a bunch of things to the backup, and the backups are now taking between 23 and 24 hours to complete. (currently backing up to tape). So the hand is kind of being forced there, but my god, not doing a full backup every single day is going to be so nice.
-Win7 clients here haven't been patched, from what I can see, since last june. I implemented a test group, pushed all updates through November to them 2 weeks ago, and am pushing those updates to the rest of the organization on Monday. PC's will be much closer to up to date, and things will be much easier to manage going forward.
Next up.... a proper system imaging solution. Currently it's 90% manual, with a basic ghost image sitting on a hard drive and most of the rest of things installed manually.
About mid-way through my 12-year time in this job, I got an urgent call from one of the plants about a DOS machine running a homegrown QBasic program for river temperature tracking. Next to it, there was a sheet of instructions on how to back up the program/data to floppy disk weekly. Guess how often they had done that (spoiler, never). Now, a little bit on this program: it needs the average river temperature for the entire previous year, the average for the same month of the previous year, and the data for the same day of the previous year. Oh, did I mention that it is hourly data entered manually? "Luckily" I guess, they also saved the printed versions of this data just in case. Also luckily, I had previously taught a QB class at a local community college, so I fixed the program to save to a network drive and print to a network printer via LPT1 on an XP machine. (And a couple minor date bugs that the guy who wrote it--chemical engineer--left in.) Anyway, they paid a temp to come in and type in the entire previous year up to the current date. And I'm pretty sure that program is still running in an XP Mode VM on that clerk's Win 7 PC. Man, I'll have to check.
It's all just manually entered data, that from your description only has some averaging calculations thrown on top, that doesn't tie into anything besides needing to print, right? Sounds like they should just be using a spreadsheet rather than relying a qbasic program running on an end-of-life OS, running as a VM, in a specialized hypervisor that only exists on an OS that's EOL in 3 years.
Just remember that half the people you meet are below average intelligence.
+1
jungleroomxIt's never too many graves, it's always not enough shovelsRegistered Userregular
It's like this: first we have to transfer the files via vpn tunnel. This is a security thing, I suppose.
Then we have an installer system that uses a local and distant service to put the new files in place and NGEN the shit to death.
Then, we run some scripts manually (they do need to be adjusted per bank, something that's thankfully going away soon).
Then we turn on the services and test.
It sucks but eh, I've had worse... except when some jackass decides they need to "hop on real quick" and screws the pooch on the entire process.
Some guy, right after the banks sysop told everyone to log off, got back on the teller station to "check something out", and started an .exe that we needed to remain dormant until we were done.
So, instead of 30 minutes, we had to spend 30 just restoring the database and then 30 minutes reconfiguring the components (mostly cfgs) and THEN 30 minutes installing it.
Thankfully we got the guys name and reported him to the president of the bank. His tone told me everything I needed to hear about how it was about to be handled.
Tl;dr: fuck users God I hate them
tbf, if your process allows for user fuckup like that, it's your own fault.
It's not my process, I just have to deal with it.
I have equal amounts of vitriol for developers.
Oh yeah, I meant that as the general 'you'
society, i guess
In all fairness, it's just one set of developers engaging in this indulgence of their fathers sins.
The other flagship product is run by a different group altogether, and they've spent the last year ripping out all the outdated/horrible stuff and building a brand new core so we can ditch DNN.
Yes. DNN.
Those guys are a-OK with me.
jungleroomx on
0
RandomHajileNot actually a SnatcherThe New KremlinRegistered Userregular
About mid-way through my 12-year time in this job, I got an urgent call from one of the plants about a DOS machine running a homegrown QBasic program for river temperature tracking. Next to it, there was a sheet of instructions on how to back up the program/data to floppy disk weekly. Guess how often they had done that (spoiler, never). Now, a little bit on this program: it needs the average river temperature for the entire previous year, the average for the same month of the previous year, and the data for the same day of the previous year. Oh, did I mention that it is hourly data entered manually? "Luckily" I guess, they also saved the printed versions of this data just in case. Also luckily, I had previously taught a QB class at a local community college, so I fixed the program to save to a network drive and print to a network printer via LPT1 on an XP machine. (And a couple minor date bugs that the guy who wrote it--chemical engineer--left in.) Anyway, they paid a temp to come in and type in the entire previous year up to the current date. And I'm pretty sure that program is still running in an XP Mode VM on that clerk's Win 7 PC. Man, I'll have to check.
It's all just manually entered data, that from your description only has some averaging calculations thrown on top, that doesn't tie into anything besides needing to print, right? Sounds like they should just be using a spreadsheet rather than relying a qbasic program running on an end-of-life OS, running as a VM, in a specialized hypervisor that only exists on an OS that's EOL in 3 years.
Yep! (The clerk is very set in her ways, though, and it works for now.)
About mid-way through my 12-year time in this job, I got an urgent call from one of the plants about a DOS machine running a homegrown QBasic program for river temperature tracking. Next to it, there was a sheet of instructions on how to back up the program/data to floppy disk weekly. Guess how often they had done that (spoiler, never). Now, a little bit on this program: it needs the average river temperature for the entire previous year, the average for the same month of the previous year, and the data for the same day of the previous year. Oh, did I mention that it is hourly data entered manually? "Luckily" I guess, they also saved the printed versions of this data just in case. Also luckily, I had previously taught a QB class at a local community college, so I fixed the program to save to a network drive and print to a network printer via LPT1 on an XP machine. (And a couple minor date bugs that the guy who wrote it--chemical engineer--left in.) Anyway, they paid a temp to come in and type in the entire previous year up to the current date. And I'm pretty sure that program is still running in an XP Mode VM on that clerk's Win 7 PC. Man, I'll have to check.
It's all just manually entered data, that from your description only has some averaging calculations thrown on top, that doesn't tie into anything besides needing to print, right? Sounds like they should just be using a spreadsheet rather than relying a qbasic program running on an end-of-life OS, running as a VM, in a specialized hypervisor that only exists on an OS that's EOL in 3 years.
Yep! (The clerk is very set in her ways, though, and it works for now.)
Welp, I checked. It looks like they quit using it in late 2014.
About mid-way through my 12-year time in this job, I got an urgent call from one of the plants about a DOS machine running a homegrown QBasic program for river temperature tracking. Next to it, there was a sheet of instructions on how to back up the program/data to floppy disk weekly. Guess how often they had done that (spoiler, never). Now, a little bit on this program: it needs the average river temperature for the entire previous year, the average for the same month of the previous year, and the data for the same day of the previous year. Oh, did I mention that it is hourly data entered manually? "Luckily" I guess, they also saved the printed versions of this data just in case. Also luckily, I had previously taught a QB class at a local community college, so I fixed the program to save to a network drive and print to a network printer via LPT1 on an XP machine. (And a couple minor date bugs that the guy who wrote it--chemical engineer--left in.) Anyway, they paid a temp to come in and type in the entire previous year up to the current date. And I'm pretty sure that program is still running in an XP Mode VM on that clerk's Win 7 PC. Man, I'll have to check.
It's all just manually entered data, that from your description only has some averaging calculations thrown on top, that doesn't tie into anything besides needing to print, right? Sounds like they should just be using a spreadsheet rather than relying a qbasic program running on an end-of-life OS, running as a VM, in a specialized hypervisor that only exists on an OS that's EOL in 3 years.
Yep! (The clerk is very set in her ways, though, and it works for now.)
Welp, I checked. It looks like they quit using it in late 2014.
Hooray for small miracles!
Just remember that half the people you meet are below average intelligence.
Posts
I think you just broke my brain.
XBL:Phenyhelm - 3DS:Phenyhelm
I have a bridge to sell you guys, too. :rotate:
Is it made with Legos?
XBL:Phenyhelm - 3DS:Phenyhelm
and you did this
This is why we cannot have nice things.
XBL:Phenyhelm - 3DS:Phenyhelm
Mistake, the first...
https://www.scribd.com/document/336399802/MISys-Pre-Installation-Guide-6-3
Edit: also it's a hilarious read. Especially the part about MS SQL Express licensing and the weird aside about accounting software.
XBL:Phenyhelm - 3DS:Phenyhelm
Dude knows how to run a business for sure, he's trying to lay down the law to make sure others aren't making dumb mistakes.
XBL:Phenyhelm - 3DS:Phenyhelm
Are we talking card access systems or other types of security systems? Because screw any of either of those that don't have Ethernet controllers built in.
Also I'm starting to see some of your possible frustrations with Doors.Net, but I'm still finding most of these have some roots in user error.
Presented without comment:
I mean anonymous binds are very smart and what do we know when computers are involved anyway?
XBL:Phenyhelm - 3DS:Phenyhelm
This is a clickable link to my Steam Profile.
Let me just sit here and try domain passwords until something lets me in. Fucking brilliant.
It's like this: first we have to transfer the files via vpn tunnel. This is a security thing, I suppose.
Then we have an installer system that uses a local and distant service to put the new files in place and NGEN the shit to death.
Then, we run some scripts manually (they do need to be adjusted per bank, something that's thankfully going away soon).
Then we turn on the services and test.
It sucks but eh, I've had worse... except when some jackass decides they need to "hop on real quick" and screws the pooch on the entire process.
Some guy, right after the banks sysop told everyone to log off, got back on the teller station to "check something out", and started an .exe that we needed to remain dormant until we were done.
So, instead of 30 minutes, we had to spend 30 just restoring the database and then 30 minutes reconfiguring the components (mostly cfgs) and THEN 30 minutes installing it.
Thankfully we got the guys name and reported him to the president of the bank. His tone told me everything I needed to hear about how it was about to be handled.
Tl;dr: fuck users God I hate them
OpenSSH 4.7 is almost 10 years old, for one. They're also running a EOL'd version of PHP and a 9 year-old version of FreeBSD.
You don't even have to *try* to find security holes in it, because you have 10 years of CVEs to basically tell you how.
Burglary alarm panels (and fire alarm panels, too).
Doors.NET is passable if all you have to do is user management. If you have to do things like time schedules or anything mildly advanced, it's convoluted as fuck.
What's reported my not necessarily be what's there, Open source is open source. But the BSD/PHP versions must be from another source.
Positive.
Eh, the bar for bad passwords seems to have been raised, albeit minutely. What I see most these days is <companyname><4 digit year>.
somebody try "guilianisecurity2001"
Needs more 9/11
Little things like that bug the shit out of me.
tbf, if your process allows for user fuckup like that, it's your own fault.
oooo, That actually interests me. I haven't had a chance to play with it yet.
It's not my process, I just have to deal with it.
I have equal amounts of vitriol for developers.
Yeah I haven't even actually seen it yet. I get the first deployment of it at my company. It's for a tiny 3 user client of ours who just have a single 2011 SBS server doing DC, file, and print, so it's pretty much the best possible case scenario for a first deployment. No exchange, no SQL, they're not using sharepoint or anything crazy off the SBS. Just AD, file & print, DHCP and DNS, and a super small environment.
Oh yeah, I meant that as the general 'you'
society, i guess
Go into the data closet only to find my client switched internet providers and the ISP removed the existing equipment (router, switches) and put in their own. Called the ISP since I know many of the people there and they're like, "Yeah we did that back in early December. They never told you?"
I checked to make sure the run from the apartment to the data closet was good but ultimately told the resident I couldn't help him. Gotta love clients making changes without letting you know.
:rotate:
- The barely working exchange server is now working properly (next up on that is building the second redundant exchange server)
- Starting Monday I'm moving to differential backups instead of running a full backup of everything every day. Final straw on that was they got me to add a bunch of things to the backup, and the backups are now taking between 23 and 24 hours to complete. (currently backing up to tape). So the hand is kind of being forced there, but my god, not doing a full backup every single day is going to be so nice.
-Win7 clients here haven't been patched, from what I can see, since last june. I implemented a test group, pushed all updates through November to them 2 weeks ago, and am pushing those updates to the rest of the organization on Monday. PC's will be much closer to up to date, and things will be much easier to manage going forward.
Next up.... a proper system imaging solution. Currently it's 90% manual, with a basic ghost image sitting on a hard drive and most of the rest of things installed manually.
It's all just manually entered data, that from your description only has some averaging calculations thrown on top, that doesn't tie into anything besides needing to print, right? Sounds like they should just be using a spreadsheet rather than relying a qbasic program running on an end-of-life OS, running as a VM, in a specialized hypervisor that only exists on an OS that's EOL in 3 years.
In all fairness, it's just one set of developers engaging in this indulgence of their fathers sins.
The other flagship product is run by a different group altogether, and they've spent the last year ripping out all the outdated/horrible stuff and building a brand new core so we can ditch DNN.
Yes. DNN.
Those guys are a-OK with me.
This is a clickable link to my Steam Profile.
This is a clickable link to my Steam Profile.
Hooray for small miracles!