They should have configured threat detection to scan executables, not text files, and scan on write, not on read, so there's no good reason why a source code repository should need to be exempted in the first place. That's just dumb.
We have Swift/Obj-C frameworks quarantined as "threats" all the time, breaking our builds. "Oh yeah, they're not signed."
Nobody is quite sure who would be "signing" it, or with what. You know, given we're trying to build them and all. And we wrote 'em. And they're from our internal SCM repo.
Could be worse. Someone had their SQL server quarantined. In prod.
+9
Inquisitor772 x Penny Arcade Fight Club ChampionA fixed point in space and timeRegistered Userregular
It typically takes two full business days for our devs to get a new laptop fully unfucked so they can actually do work.
"Sales doesn't need admin; it's okay if you guys don't have admin, right? And no installing anything! Especially not open-source!" (Being fair, that's just what they want, not what they currently get.)
If they weren't Macbooks, we'd be so, so fucked. Only so much you can fuck up a Macbook.
+1
Inquisitor772 x Penny Arcade Fight Club ChampionA fixed point in space and timeRegistered Userregular
I'm just dev-adjacent, and the amount of tickets I had to submit and bullshit hand-holding I had to go through to get basic stuff installed and configured on my laptop two weeks ago was annoying AF. My boss even had to "escalate" tickets to get them to look at them immediately, otherwise it would've taken another week for them to respond. Week where I would've been without basic software needed to do my job.
A good third of my stuff comes out of homebrew. I'm sure that gives someone in infosec hives, but like... Development environment? Hello?
0
TL DRNot at all confident in his reflexive opinions of thingsRegistered Userregular
An interesting realization that came from my recent RDP / account lockout adventure:
Why was the new server getting hammered with login attempts, while the old servers with identical configurations were not?
One eagle-eyed tech noticed that the old servers used the public DNS records TS4.domain.com and TS5.domain.com, while the new ones restarted at TS and TS2, respectively. Clever bots.
A good third of my stuff comes out of homebrew. I'm sure that gives someone in infosec hives, but like... Development environment? Hello?
It's fine, as long as there's segregation between dev environment and production.
But if you're using a certain PC to, say, check email, or manipulate Office files, by definition that's production and not dev, so dev code shouldn't run there.
Virtualization exists. There's literally no reason (other than laziness & stubbornness) why a developer needs admin access to their workstation. Build a VM farm, off the AD domain (or with its own AD domain), sandbox it as much as you can, and give the devs full permissions on it.
Worst case scenario, you're doing really low level stuff with hardware or drivers that doesn't play nice with virtualization. But that describes a minority of developers. In that case, just give them a KVM and a second machine.
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
Virtualization exists. There's literally no reason (other than laziness & stubbornness) why a developer needs admin access to their workstation.
Just to be clear, the laziness and stubbornness isn't necessarily all on the part of developers. I mean, it often is. But sometimes it's IT's fault, too
If three devs in a row request Visual Studio with add-ons & redistributables for C++ development, just make it part of the standard build. Find out what the silent install strings are, put them in your SCCM task sequence or just do a post-imaging script. This shit isn't hard.
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
the "no true scotch man" fallacy.
+3
TL DRNot at all confident in his reflexive opinions of thingsRegistered Userregular
Speaking of imaging, is anyone aware of a good source for comparing various imaging solutions in terms of complexity / recommended scale, licensing costs, etc? Even just a 'Microsoft license talk decrypted for a human audience' would be helpful. We have some clients who are still using various Acronis products, etc and I feel like migrating to WDS or SCCM would be a logical progression, but I don't have hands-on experience with either.
A good third of my stuff comes out of homebrew. I'm sure that gives someone in infosec hives, but like... Development environment? Hello?
It's fine, as long as there's segregation between dev environment and production.
But if you're using a certain PC to, say, check email, or manipulate Office files, by definition that's production and not dev, so dev code shouldn't run there.
Virtualization exists. There's literally no reason (other than laziness & stubbornness) why a developer needs admin access to their workstation. Build a VM farm, off the AD domain (or with its own AD domain), sandbox it as much as you can, and give the devs full permissions on it.
Worst case scenario, you're doing really low level stuff with hardware or drivers that doesn't play nice with virtualization. But that describes a minority of developers. In that case, just give them a KVM and a second machine.
Xcode really likes having admin rights, and if you want to develop for Apple products, you're using Xcode. It's also against licensing to virtualise/run Mac OS on anything other than Apple hardware, and most VM farms don't tend to enjoy being made of Mac Minis. (Needless to say, Xcode isn't running on anything other than the version of MacOS it wants to run on, and they'll tell YOU when you have to update your OS, btw.)
I'm sure it's POSSIBLE with enough banging, but when the alternative is "Just let them use their laptop like a normal human", well.
Speaking of imaging, is anyone aware of a good source for comparing various imaging solutions in terms of complexity / recommended scale, licensing costs, etc? Even just a 'Microsoft license talk decrypted for a human audience' would be helpful. We have some clients who are still using various Acronis products, etc and I feel like migrating to WDS or SCCM would be a logical progression, but I don't have hands-on experience with either.
Depends - how big are the companies? Once you get near enterprise, pricing is just a suggestion.
A good third of my stuff comes out of homebrew. I'm sure that gives someone in infosec hives, but like... Development environment? Hello?
It's fine, as long as there's segregation between dev environment and production.
But if you're using a certain PC to, say, check email, or manipulate Office files, by definition that's production and not dev, so dev code shouldn't run there.
Virtualization exists. There's literally no reason (other than laziness & stubbornness) why a developer needs admin access to their workstation. Build a VM farm, off the AD domain (or with its own AD domain), sandbox it as much as you can, and give the devs full permissions on it.
Worst case scenario, you're doing really low level stuff with hardware or drivers that doesn't play nice with virtualization. But that describes a minority of developers. In that case, just give them a KVM and a second machine.
Xcode really likes having admin rights, and if you want to develop for Apple products, you're using Xcode. It's also against licensing to virtualise/run Mac OS on anything other than Apple hardware, and most VM farms don't tend to enjoy being made of Mac Minis. (Needless to say, Xcode isn't running on anything other than the version of MacOS it wants to run on, and they'll tell YOU when you have to update your OS, btw.)
I'm sure it's POSSIBLE with enough banging, but when the alternative is "Just let them use their laptop like a normal human", well.
Gotcha. If you're talking an Apple-centric environment, I don't know enough about that to argue.
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
In what world does one disable IMAP? Literally drives the world for everyone not on exchange. Exchange is probably more open to attack than IMAP anyways.
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
Like if you've got any third party tools that need an email, you need IMAP and SMTP full stop. If all you have is a bunch of people checking their email why are you even self managing that anyways?
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
So, last Friday, it's closing time, my wireless engineer comes to my office, "Hey we have a problem. Chunk of our network is down, and I can't log into the backhauls that feed it. They won't take any of my passwords."
Well, fuck. Probably a hack or a worm or both. Fuck fuck fuck. We both exclaim this aloud. Fuck fuck fuck. But how did they get into our network, I wonder aloud. Yes, how indeed, he wonders also.
Well, our management software is still monitoring them, still pulling stats, and I'm like, "How the fuck is that happening, it uses SSH to pull this shit, and it uses our credentials." I should have listened to myself, but as the problem continued, self-doubt crept in and I questioned my own understanding too much to continue down that path. "Well, since we're still connected, lemme try some shit."
Pulled down the config off the backhauls, saw the hashed password, decided that cracking that was maybe the best path forward. If 10 minutes went by and I didn't have results, we'd go out, manually reset the radios, and I had the config to paint by numbers by. In the meantime I'm slapping in all sorts of truncated versions of our passwords, because I know some older firmwares truncated to 8.
Cleaning guy rolls by, "Hey you guys working late?" Smile on his face. I immediately blush with anger, I don't have time for a fuckin' peanut gallery. "Well, just so you know, such-and-such district has no power right now. Saw it on my way in."
I'm too angry to acknowledge this, I say, "Okay, thanks, but that doesn't explain everything." He leaves. Then I realize that yeah, everyone that's currently down, lives in that district. I call our after-hours support, nobody's called in (which tells me it's definitely power, because the only reason our customers wouldn't call in when they're down is if they knew why they were down). The engineer and I come to the conclusion that the backhauls are unrelated, but we should still try to fix our access issue before we leave. 5 minutes later, he's in. He used a truncated version of our password to get in. I tell him I tried that, what did he do?
Simple. He accurately counted to 8 while I was counting to 9 like some sort of fucking moron.
A few minutes later, power was restored to that district, and everyone came online simultaneously.
I thanked the cleaning guy for his information, he probably saved us another hour of our time being idiots. Clearly we should switch jobs. I hear his pays better anyways.
Like if you've got any third party tools that need an email, you need IMAP and SMTP full stop. If all you have is a bunch of people checking their email why are you even self managing that anyways?
We have imap enabled, but only for very specific client apps.
Like if you've got any third party tools that need an email, you need IMAP and SMTP full stop. If all you have is a bunch of people checking their email why are you even self managing that anyways?
We have imap enabled, but only for very specific client apps.
TBH I'd be far more concerned with an exchange endpoint than an IMAP. IMAP is open source and basically powers email on the internet. Exchange is closed source, and y'all know how that goes.
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
Like if you've got any third party tools that need an email, you need IMAP and SMTP full stop. If all you have is a bunch of people checking their email why are you even self managing that anyways?
We have imap enabled, but only for very specific client apps.
TBH I'd be far more concerned with an exchange endpoint than an IMAP. IMAP is open source and basically powers email on the internet. Exchange is closed source, and y'all know how that goes.
Like if you've got any third party tools that need an email, you need IMAP and SMTP full stop. If all you have is a bunch of people checking their email why are you even self managing that anyways?
We have imap enabled, but only for very specific client apps.
TBH I'd be far more concerned with an exchange endpoint than an IMAP. IMAP is open source and basically powers email on the internet. Exchange is closed source, and y'all know how that goes.
Just to be that guy: it's really SMTP that powers email on the Internet.
Like if you've got any third party tools that need an email, you need IMAP and SMTP full stop. If all you have is a bunch of people checking their email why are you even self managing that anyways?
We have imap enabled, but only for very specific client apps.
TBH I'd be far more concerned with an exchange endpoint than an IMAP. IMAP is open source and basically powers email on the internet. Exchange is closed source, and y'all know how that goes.
Just to be that guy: it's really SMTP that powers email on the Internet.
Yeah but how you gonna check your email?
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
Like if you've got any third party tools that need an email, you need IMAP and SMTP full stop. If all you have is a bunch of people checking their email why are you even self managing that anyways?
We have imap enabled, but only for very specific client apps.
TBH I'd be far more concerned with an exchange endpoint than an IMAP. IMAP is open source and basically powers email on the internet. Exchange is closed source, and y'all know how that goes.
Just to be that guy: it's really SMTP that powers email on the Internet.
Yeah but how you gonna check your email?
Wireshark.
+10
TL DRNot at all confident in his reflexive opinions of thingsRegistered Userregular
Suggestion that the threat title read "[Sysadmin] Wire Shark do do do do do do"
Like if you've got any third party tools that need an email, you need IMAP and SMTP full stop. If all you have is a bunch of people checking their email why are you even self managing that anyways?
We have imap enabled, but only for very specific client apps.
TBH I'd be far more concerned with an exchange endpoint than an IMAP. IMAP is open source and basically powers email on the internet. Exchange is closed source, and y'all know how that goes.
Just to be that guy: it's really SMTP that powers email on the Internet.
life's a game that you're bound to lose / like using a hammer to pound in screws
fuck up once and you break your thumb / if you're happy at all then you're god damn dumb
that's right we're on a fucked up cruise / God is dead but at least we have booze
bad things happen, no one knows why / the sun burns out and everyone dies
A good third of my stuff comes out of homebrew. I'm sure that gives someone in infosec hives, but like... Development environment? Hello?
It's fine, as long as there's segregation between dev environment and production.
But if you're using a certain PC to, say, check email, or manipulate Office files, by definition that's production and not dev, so dev code shouldn't run there.
Virtualization exists. There's literally no reason (other than laziness & stubbornness) why a developer needs admin access to their workstation. Build a VM farm, off the AD domain (or with its own AD domain), sandbox it as much as you can, and give the devs full permissions on it.
Worst case scenario, you're doing really low level stuff with hardware or drivers that doesn't play nice with virtualization. But that describes a minority of developers. In that case, just give them a KVM and a second machine.
Xcode really likes having admin rights, and if you want to develop for Apple products, you're using Xcode. It's also against licensing to virtualise/run Mac OS on anything other than Apple hardware, and most VM farms don't tend to enjoy being made of Mac Minis. (Needless to say, Xcode isn't running on anything other than the version of MacOS it wants to run on, and they'll tell YOU when you have to update your OS, btw.)
I'm sure it's POSSIBLE with enough banging, but when the alternative is "Just let them use their laptop like a normal human", well.
Gotcha. If you're talking an Apple-centric environment, I don't know enough about that to argue.
Anymore my basic stance on dev machines is "Keep it off my prod network and I don't wanna hear a fucking word about it. Here's a VLAN, here's your admin rights, it's your problem. If you break it, you fix it."
Like if you've got any third party tools that need an email, you need IMAP and SMTP full stop. If all you have is a bunch of people checking their email why are you even self managing that anyways?
We have imap enabled, but only for very specific client apps.
TBH I'd be far more concerned with an exchange endpoint than an IMAP. IMAP is open source and basically powers email on the internet. Exchange is closed source, and y'all know how that goes.
MAPI over RPC is insecure as all hell but that hasn't been standard since Exchange 2007 or 2010.
Exchange 2013/2016 with HTTPS access for clients (as is the default now) is pretty solid, security-wise. Obviously everything has vulnerabilities but there's nothing glaring. If an attacker wants to compromise a Windows network, there are much lower-hanging fruit.
every person who doesn't like an acquired taste always seems to think everyone who likes it is faking it. it should be an official fallacy.
Posts
We have Swift/Obj-C frameworks quarantined as "threats" all the time, breaking our builds. "Oh yeah, they're not signed."
Nobody is quite sure who would be "signing" it, or with what. You know, given we're trying to build them and all. And we wrote 'em. And they're from our internal SCM repo.
Could be worse. Someone had their SQL server quarantined. In prod.
If they weren't Macbooks, we'd be so, so fucked. Only so much you can fuck up a Macbook.
Why was the new server getting hammered with login attempts, while the old servers with identical configurations were not?
One eagle-eyed tech noticed that the old servers used the public DNS records TS4.domain.com and TS5.domain.com, while the new ones restarted at TS and TS2, respectively. Clever bots.
IMAP is useful for some third party software; we have a few systems that use it to check for incoming email
the "no true scotch man" fallacy.
It's fine, as long as there's segregation between dev environment and production.
But if you're using a certain PC to, say, check email, or manipulate Office files, by definition that's production and not dev, so dev code shouldn't run there.
Virtualization exists. There's literally no reason (other than laziness & stubbornness) why a developer needs admin access to their workstation. Build a VM farm, off the AD domain (or with its own AD domain), sandbox it as much as you can, and give the devs full permissions on it.
Worst case scenario, you're doing really low level stuff with hardware or drivers that doesn't play nice with virtualization. But that describes a minority of developers. In that case, just give them a KVM and a second machine.
the "no true scotch man" fallacy.
Just to be clear, the laziness and stubbornness isn't necessarily all on the part of developers. I mean, it often is. But sometimes it's IT's fault, too
If three devs in a row request Visual Studio with add-ons & redistributables for C++ development, just make it part of the standard build. Find out what the silent install strings are, put them in your SCCM task sequence or just do a post-imaging script. This shit isn't hard.
the "no true scotch man" fallacy.
Xcode really likes having admin rights, and if you want to develop for Apple products, you're using Xcode. It's also against licensing to virtualise/run Mac OS on anything other than Apple hardware, and most VM farms don't tend to enjoy being made of Mac Minis. (Needless to say, Xcode isn't running on anything other than the version of MacOS it wants to run on, and they'll tell YOU when you have to update your OS, btw.)
I'm sure it's POSSIBLE with enough banging, but when the alternative is "Just let them use their laptop like a normal human", well.
Depends - how big are the companies? Once you get near enterprise, pricing is just a suggestion.
Gotcha. If you're talking an Apple-centric environment, I don't know enough about that to argue.
the "no true scotch man" fallacy.
Well, fuck. Probably a hack or a worm or both. Fuck fuck fuck. We both exclaim this aloud. Fuck fuck fuck. But how did they get into our network, I wonder aloud. Yes, how indeed, he wonders also.
Well, our management software is still monitoring them, still pulling stats, and I'm like, "How the fuck is that happening, it uses SSH to pull this shit, and it uses our credentials." I should have listened to myself, but as the problem continued, self-doubt crept in and I questioned my own understanding too much to continue down that path. "Well, since we're still connected, lemme try some shit."
Pulled down the config off the backhauls, saw the hashed password, decided that cracking that was maybe the best path forward. If 10 minutes went by and I didn't have results, we'd go out, manually reset the radios, and I had the config to paint by numbers by. In the meantime I'm slapping in all sorts of truncated versions of our passwords, because I know some older firmwares truncated to 8.
Cleaning guy rolls by, "Hey you guys working late?" Smile on his face. I immediately blush with anger, I don't have time for a fuckin' peanut gallery. "Well, just so you know, such-and-such district has no power right now. Saw it on my way in."
I'm too angry to acknowledge this, I say, "Okay, thanks, but that doesn't explain everything." He leaves. Then I realize that yeah, everyone that's currently down, lives in that district. I call our after-hours support, nobody's called in (which tells me it's definitely power, because the only reason our customers wouldn't call in when they're down is if they knew why they were down). The engineer and I come to the conclusion that the backhauls are unrelated, but we should still try to fix our access issue before we leave. 5 minutes later, he's in. He used a truncated version of our password to get in. I tell him I tried that, what did he do?
Simple. He accurately counted to 8 while I was counting to 9 like some sort of fucking moron.
A few minutes later, power was restored to that district, and everyone came online simultaneously.
I thanked the cleaning guy for his information, he probably saved us another hour of our time being idiots. Clearly we should switch jobs. I hear his pays better anyways.
XBL:Phenyhelm - 3DS:Phenyhelm
We have imap enabled, but only for very specific client apps.
TBH I'd be far more concerned with an exchange endpoint than an IMAP. IMAP is open source and basically powers email on the internet. Exchange is closed source, and y'all know how that goes.
We do it for data management reasons.
Just to be that guy: it's really SMTP that powers email on the Internet.
Yeah but how you gonna check your email?
Wireshark.
ssh in and use vim ya pansy.
using vim for email is like stabbing yourself
just use pine's suite of tools instead
Oooh, I'll settle for alpine.
XBL:Phenyhelm - 3DS:Phenyhelm
fuck up once and you break your thumb / if you're happy at all then you're god damn dumb
that's right we're on a fucked up cruise / God is dead but at least we have booze
bad things happen, no one knows why / the sun burns out and everyone dies
This is a clickable link to my Steam Profile.
Our voicemail-to-email transcription system connects over imap. I don't know what else does off-hand.
That's going to be stuck in my head all goddamn day you son of a bitch
Anymore my basic stance on dev machines is "Keep it off my prod network and I don't wanna hear a fucking word about it. Here's a VLAN, here's your admin rights, it's your problem. If you break it, you fix it."
what's emacs then?
A poorly configured lisp interpreter.
Our helpdesk ticketing system connects over IMAP to do ticket-to-email.
We have two automation platforms. Both of them watch a number of inboxes for incoming email and then trigger workflows based on those emails.
One of them only supports IMAP or POP3. The other one ostensibly supports Exchange, but we had some glitchiness with that so we switched to IMAP.
the "no true scotch man" fallacy.
MAPI over RPC is insecure as all hell but that hasn't been standard since Exchange 2007 or 2010.
Exchange 2013/2016 with HTTPS access for clients (as is the default now) is pretty solid, security-wise. Obviously everything has vulnerabilities but there's nothing glaring. If an attacker wants to compromise a Windows network, there are much lower-hanging fruit.
the "no true scotch man" fallacy.