@flaxking That may work and is worth a try, but it's likely not to work because the client is passing along to SQL Server and it's not known whether or not they implemented, or allow, encrypted traffic within their SQL Server connection library. Even if implemented in the library, it doesn't mean the client allows it, and even may be intentionally disabled for God only knows what reason. It isn't an SQL client, it's an application which just connects to SQL Server or passes raw SQL along to an application server to avoid client connection licensing limits.

@Dashrender said in SQL security over the LAN:

@tonyshowoff said in SQL security over the LAN:

@Dashrender said in SQL security over the LAN:

Setup a TS and run the app from there. RDP into TS.

That doesn't fix the problem because the weak point is the client, it would just be moving the problem to another place, in fact it may be worse because then they could see the traffic of all the clients in a single place.

Right so keep that on its own network and only allow rdp traffic through to that network.

That's still the same attack vector. If the client is on RDP and you watch within the RDP session, it doesn't matter if it's separate or not. In fact, as I said, it widens the amount of traffic you can listen to because you'll be able to spy on all clients on that RDP server.

@Dashrender said in SQL security over the LAN:

Setup a TS and run the app from there. RDP into TS.

That doesn't fix the problem because the weak point is the client, it would just be moving the problem to another place, in fact it may be worse because then they could see the traffic of all the clients in a single place.

@Donahue said in SQL security over the LAN:

Ok, so I have this vulnerability. Short of stopping use of this application, what can be done to mitigate the risk this presents?

Not if the application does not have it built in, such as TLS/SSL connections. There are way to mitigate it over the network such as a tunnel between the client and server, but on the client there's no defence at all, and that's really your vulnerable part.

@Donahue said in SQL security over the LAN:

@tonyshowoff said in SQL security over the LAN:

@Dashrender said in SQL security over the LAN:

@tonyshowoff said in SQL security over the LAN:

@Donahue said in SQL security over the LAN:

I don't know this this is to be expected, but a lot of the traffic is also smb2

Since SQL Server 2008 you can use SQL over SMB2 rather than just TCP/IP or named pipes or shared memory. So I imagine that's how they're doing it, seems like needless overhead but based on everything else that's to be expected.

Curious - why would you want to do it over SMB?

It's sort of pseudo-configureless, you need not worry about ports or IPs and just go by name. The other side of that is you have to deal with SMB locking and other problems and it slows things down sometimes significantly.

plus, it probably ties the customer in tighter into the MS ecosystem.

Exactly, same reason they have all that COM+ garbage and other things that just add layers and layers of complexity to things. Ever wonder why Exchange Server and AD are such a bitch to get working and their clones aren't? Part of the justification for all these extra products is Microsoft tries to put them to use in their own, making them more and more bloated and difficult to get working. They've started to fix this in recent years by abandoning their own product lines and just doing things a more proper way. But if you installed Exchange 2003 or 2007 and had issues with it or with AD around that time, and all the tons of countless tools, scripts, etc you had to use, you'd get why these things happen to Windows but not as often on the same protocols hosted elsewhere.

@Dashrender said in SQL security over the LAN:

@tonyshowoff said in SQL security over the LAN:

@Donahue said in SQL security over the LAN:

I don't know this this is to be expected, but a lot of the traffic is also smb2

Since SQL Server 2008 you can use SQL over SMB2 rather than just TCP/IP or named pipes or shared memory. So I imagine that's how they're doing it, seems like needless overhead but based on everything else that's to be expected.

Curious - why would you want to do it over SMB?

It's sort of pseudo-configureless, you need not worry about ports or IPs and just go by name. The other side of that is you have to deal with SMB locking and other problems and it slows things down sometimes significantly.

@Donahue said in SQL security over the LAN:

I don't know this this is to be expected, but a lot of the traffic is also smb2

Since SQL Server 2008 you can use SQL over SMB2 rather than just TCP/IP or named pipes or shared memory. So I imagine that's how they're doing it, seems like needless overhead but based on everything else that's to be expected.

This situation is fairly common, I saw the same thing with Everest/Greenestep. Even though they had "an application server" all it did was handle licensing, the clients did literally everything else. I demonstrated to one of their developers (and this was nearly 10 years ago) how with little effort one could easily execute anything on the database. He said it wasn't possible if the client machine was properly locked down, and I explained that's the literal exact opposite of how clients are supposed to be treated. Forget the fact that it wasn't just creating a simple TCP proxy to sit between the client/server and watch all traffic (which I showed and shared) and could be done with minimal Windows rights, but also in their custom reports you could do SQL injections since no fields had any sort of sanitation... they "fixed" this in some fields (in things other than reports) by banning the use of semicolon. Really.

I also pointed out other issues such as with the timeclock, since it didn't rely on the time of the SQL Server or their "application server" you could adjust the clock time in Windows and clock yourself in/out in the past or future. Again, claims about properly locked down clients. I asked if most of their customers use proper GPO and so forth to lock down as much of this as they can, he said he didn't even think they knew how to do that. I spoke to an old friend recently who still uses their software, their latest version which finally supports Microsoft SQL Server 2012, and no, none of these things have been fixed despite the software costing $100,000 a year.

This also is the case with Eaglesoft dental software, except they require the client have total local administrative rights to work properly at all. And they do SELECT queries with no TOP (or other functionality in newer versions of Microsoft SQL Server) and instead request every row, slowing down the network, and then sorting in the client. They abandoned multioffice for this reason. Further, for updating it, you have to send a bak of your database via plain FTP so they can run scripts or whatever on it, then you have to get the new version before updating the software. This is the most popular dentist software there is. When I did this for a client, I saw on the FTP server literally hundreds of dumps of other company databases and I had read access to all of them. They can't seem to figure out how to properly update their software.

Incompetence and just sheer stupidity is almost a requirement for ERPs and medical software and nobody wants to change. It's honestly a surprise to me that more information isn't leaked more often.

There needs to be someone who can shake things up by simply doing things correctly, as shocking and innovative of an idea that is.

@stacksofplates said in MongoDB Major Change to Licensing:

Didn't read the whole thread but they apparently didn't learn from Redis. They will have to move back or fail. There's nothing stopping anyone from forking under the previous license and essentially copying fixes.

This helps no one at all.

Just FYI, this is what he's talking about, a very similar license scheme they walked back on after realising it was a stupid idea, but MongoDB thinks it's great

https://www.techrepublic.com/article/why-redis-labs-made-a-huge-mistake-when-it-changed-its-open-source-licensing-strategy/

@scottalanmiller said in MongoDB Major Change to Licensing:

I think this describes my position best...

I think that the true intent of the license was to trick people into thinking that the intent was to cover only limited scenarios. But no law firm would have been so clumsy if that was the goal for real. In reality, I think the intent was to actually cover anything and everything while providing plausible deniability as to how evil the license is in reality.

I agree, that was my impression simply on first reading it.

@DustinB3403 said in MongoDB Major Change to Licensing:

The intent is, if you sell a service to a THIRD PARTY, that you need to purchase a license or open source your shit.

Pretty straightforward.

No, not straight forward, it doesn't say sell, it is providing and not being open source. And it isn't straight forward because it's poor legal language and potentially ambiguous. You have to remember that if ever it came up in arbitration, as most technical disagreements do, the judge or whomever is likely to not going to understand the distinction. Just because it's closed source doesn't mean it's being sold.

@DustinB3403 said in MongoDB Major Change to Licensing:

@scottalanmiller said in MongoDB Major Change to Licensing:

@DustinB3403 said in MongoDB Major Change to Licensing:

It's targeting profitiers, not internal uses.

Those are one and the same. No one runs software internally if not for profit from doing so. You can't find a way to differentiate these two.

Sure I can, MongoDB and my company "Dustin's Dough" have a database.

My customers aren't accessing that database. Hence no third party, hence no need to open source everything or purchase a license.

That's my point about vague language, again let's say that's protected and the intent, it's fairly easy to make an argument especially to non-technical arbiters or other legal-minded people that because the customer used your software and your software accesses the database, therefore your customers are.

@DustinB3403 said in MongoDB Major Change to Licensing:

@tonyshowoff said in MongoDB Major Change to Licensing:

@DustinB3403 said in MongoDB Major Change to Licensing:

@tonyshowoff said in MongoDB Major Change to Licensing:

@DustinB3403 said in MongoDB Major Change to Licensing:

@scottalanmiller said in MongoDB Major Change to Licensing:

@DustinB3403 said in MongoDB Major Change to Licensing:

No. . . only if I was selling a service that used MongoDB as the backend would I be forced to purchase a license or Open Source everything. If I ran a mongoDB internally and not sold it as a service I wouldn't have to contribute or open a single line of code for whatever I built internally that uses MongoDB.

You sure? "As a service" doesn't imply selling it to third parties. Software is delivered "as a service" internally, too. And it's not just selling, but using. This license is broad, very broad. So broad that I think you might be completely missing how it risks tainting literally everything.

This change specifically targets MongoDB as a service that a (not mongoDB company) is selling a service and profiting from.

Intent isn't the same thing as result, especially if you scare people away with vague language

Sure, I agree wholeheartedly. But the conversation and license change is specifically businesses who are using MongoDB as a backend to whatever service they are selling to a customer.

It's targeting profitiers, not internal uses.

Let's say that's accurate, fine, but we're already moving to another key-value store in our product because of this (among other reasons but this is a good reason to never look back) and also the potential for it to get worse. What if they decided to further lock that down based on some other reason or decided to suddenly start trying to license to closed source products/services that simply use it so they can make money from that?

Again, I agree, but I'm stating what the license change is stating. It's targeting businesses that use MongoDB as a backend for whatever service they are selling to a third party.

Either open the source for the service you sell, or buy a license.

The first part of that sentence says "make the functionality of the program[...]available to third parties" so even API access of any sort applies

@DustinB3403 said in MongoDB Major Change to Licensing:

@tonyshowoff said in MongoDB Major Change to Licensing:

@DustinB3403 said in MongoDB Major Change to Licensing:

@scottalanmiller said in MongoDB Major Change to Licensing:

@DustinB3403 said in MongoDB Major Change to Licensing:

No. . . only if I was selling a service that used MongoDB as the backend would I be forced to purchase a license or Open Source everything. If I ran a mongoDB internally and not sold it as a service I wouldn't have to contribute or open a single line of code for whatever I built internally that uses MongoDB.

You sure? "As a service" doesn't imply selling it to third parties. Software is delivered "as a service" internally, too. And it's not just selling, but using. This license is broad, very broad. So broad that I think you might be completely missing how it risks tainting literally everything.

This change specifically targets MongoDB as a service that a (not mongoDB company) is selling a service and profiting from.

Intent isn't the same thing as result, especially if you scare people away with vague language

Sure, I agree wholeheartedly. But the conversation and license change is specifically businesses who are using MongoDB as a backend to whatever service they are selling to a customer.

It's targeting profitiers, not internal uses.

Let's say that's accurate, fine, but we're already moving to another key-value store in our product because of this (among other reasons but this is a good reason to never look back) and also the potential for it to get worse. What if they decided to further lock that down based on some other reason or decided to suddenly start trying to license to closed source products/services that simply use it so they can make money from that?

@DustinB3403 said in MongoDB Major Change to Licensing:

@scottalanmiller said in MongoDB Major Change to Licensing:

@DustinB3403 said in MongoDB Major Change to Licensing:

No. . . only if I was selling a service that used MongoDB as the backend would I be forced to purchase a license or Open Source everything. If I ran a mongoDB internally and not sold it as a service I wouldn't have to contribute or open a single line of code for whatever I built internally that uses MongoDB.

You sure? "As a service" doesn't imply selling it to third parties. Software is delivered "as a service" internally, too. And it's not just selling, but using. This license is broad, very broad. So broad that I think you might be completely missing how it risks tainting literally everything.

This change specifically targets MongoDB as a service that a (not mongoDB company) is selling a service and profiting from.

Intent isn't the same thing as result, especially if you scare people away with vague language... like GPL 3 and Linux

@scottalanmiller said in MongoDB Major Change to Licensing:

https://www.theregister.co.uk/2018/10/16/mongodb_licensning_change/

"MongoDB, which offers its database as a service, will not be playing by the same rules, however. "Because we own the IP, we are not obligated to open source our underlying management infrastructure," explained Ittycheria, who added that MongoDB has invested more than $300m developing its software."

Basically... customers of MongoDB have to go open source, but MongoDB doesn't have to. Which is fine and legal, but don't pretend this is about being open, this is about shutting down the ecosystem.

You have to be extra stupid to do something like this. Open source projects especially ones with APIs thrive on large ecosystems of all types. If suddenly you create a window for only a few dozen notable projects, and many barely at that, suddenly there's no reason for people to keep using it and thus providing API support in languages and so on.

MongoDB's future

Why must you turn this forum into a house of lies!?