@manxam said in Bills and clients subscription management software:

@tonyshowoff said in Bills and clients subscription management software:

Invoice Ninja is pretty good I just wish I could host it.

Why can you not host it?

I was just being ironic

@flaxking said in SQL security over the LAN:

@tonyshowoff said in SQL security over the LAN:

@flaxking said in SQL security over the LAN:

@tonyshowoff said in SQL security over the LAN:

@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.

How would that avoid licencing? The MS SQL licencing doesn't care how a user connects, you have to get CALs for the actual users using it no matter the method used. (Unless using SQL Express)

Because it opens one connection between the application server and the SQL Server rather than a new one for every single client. You can avoid user CAL issues because it's one connection from one user.

I can't speak to there possibility being a point in time when this was true, but it is not true now. You have to get CALs for each actual person, even if they themselves are not in direct communication with the MS SQL Server

I am aware but it isn't relevant, that's just why people do it in the ERP world in addition to having license control over their own client application. There's no inherent transparent encryption with a third party library connecting to SQL Server though. It should be straight forward from the development perspective considering they must be using a fairly modern one to be using SQL over SMB2, but if the company is basically dismissing concerns over encryption by saying "it's up to you to secure your network" that's basically saying "what's encryption? We're morons."

Invoice Ninja is pretty good I just wish I could host it.

And I raise your woman in a pool with a woman in the ocean:

Youtube Video

@flaxking said in SQL security over the LAN:

@tonyshowoff said in SQL security over the LAN:

@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.

How would that avoid licencing? The MS SQL licencing doesn't care how a user connects, you have to get CALs for the actual users using it no matter the method used. (Unless using SQL Express)

Because it opens one connection between the application server and the SQL Server rather than a new one for every single client. You can avoid user CAL issues because it's one connection from one user. This isn't really as big of an issue today as the licensing has become much more free, but many years ago there was a much harder limit on user connection count and how many different users could be connected and it was limited to version of both SQL Server and sometimes even the OS, and the licensing that, that implies. My guess is they may be having their application work with a newer version of SQL Server but I doubt they're using any features not also available on SQL Server 7 from 1998... and that isn't meant to be a joke, from what I've seen that tends to be the standard.

@Obsolesce

After that point I don't know if there is a maintained secure channel from the authenticated app to the SQL server.

Not if you don't use one of those. Having the option doesn't mean it's setup automatically, which I imagine you know, but I'm saying it rhetorically to point out the unfortunate situation.

@Obsolesce said in SQL security over the LAN:

The AD authentication process is secure... Kerberos and all that which MS SQL server can use. After that point I don't know if there is a maintained secure channel from the authenticated app to the SQL server.

Not if you don't use one.

@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.