11–20 of 20 posts
Isn't the 440 figure disingenuous? Surely you must count UDP/TCP header size, which would bring the value closer to 21/461 ~= 22. Still an interesting discovery. DDoS amplification is a security risk few people consider when developing applications.
Header size is 8-20 (without options) and if you read the article closelyer you'll see the total packet size was 480ish.
I dont know how you are getting 21/461 = 22 ?
Isn't the 440 figure disingenuous? Surely you must count UDP/TCP header size, which would bring the value closer to 21/461 ~= 22. Still an interesting discovery. DDoS amplification is a security risk few people consider when developing applications.
Agreed. As I see it there are two main design methods for overcoming this issue. The first is better for 'anonymous' services; require the client to send a packet of the same size as the buffer they want to receive. It's network in-efficient but for small requests better than the delay in setting up an actual session. It eliminates the chance of amplification attacks. The second is to establish /some/ kind of session…
I'm genuinely curious - What are the reasons for exposing an SQL server directly to the internet? Obviously there's a bunch of people who have mis-configured and have accidently exposed their systems, but are there real-world reasons to expose a SQL server directly to the net? I would think most people who are sharing datasets would do so with some sort of API - and there'd need to be room for rate limiting / blackli…
In a word "laziness." It is just easier to log in and manage an SQL server if it is available on the internet. I know I'm certainly guilty of doing so for short periods when I'm off-site with no VPN and need to manage a server. Some sysadmins just get lazy and leave it available on the internet with strong passwords 24/7, just so once in a blue moon they can log in and manage it. Or are doing some kind of site to sit…
client told me they got a big IO bill from AWS & i was deathly afraid it was from bots just probing the SQL server ports. thankfully it wasn't (it was from s3, they are a media heavy site with many users) but it reminded me not to just leave things accessible via internet, cuz even though it seems irrational to think someone would just probe you over & over, the fact is you have to pay an AWS bill, & attackers are just operating from their laptop.... if the amplification is right they can cost you looooots of $$ with no cost to them.
This is one of those legacy services that Microsoft keeps around just in case somebody wants it but it's been a long time since it had any changes or updates. What they really need to do is have it not even included with the product. It should be a download-only utility, for those that really, really want this on their systems.
Earlier quoted context omitted.
It really is simple to use ssh to tunnel a port; that is always how I access SQL Server remotely. Laziness indeed.
You use SSH port tunnelling on a Windows Server to access MS SQL? I'd be surprised if that was "simple." But go ahead and explain it.
Isn't the 440 figure disingenuous? Surely you must count UDP/TCP header size, which would bring the value closer to 21/461 ~= 22. Still an interesting discovery. DDoS amplification is a security risk few people consider when developing applications.
Won't somebody think of the routers?! Header size is 8-20 (without options) and if you read the article closelyer you'll see the total packet size was 480ish. I dont know how you are getting 21/461 = 22 ?
the average packet size was 483 bytes (average data
length = 441 bytes)
My point is: this is important, but not a 440x amplification attack.
I'm genuinely curious - What are the reasons for exposing an SQL server directly to the internet? Obviously there's a bunch of people who have mis-configured and have accidently exposed their systems, but are there real-world reasons to expose a SQL server directly to the net? I would think most people who are sharing datasets would do so with some sort of API - and there'd need to be room for rate limiting / blackli…
I guess 700k is a bunch...
https://www.shodan.io/search?query=port%3A%221434%22
Since we can't expect those jokers to fix anything, it's probably best to drop traffic on that port.
Earlier quoted context omitted.
You use SSH port tunnelling on a Windows Server to access MS SQL? I'd be surprised if that was "simple." But go ahead and explain it.
We do here where I work. We're running Bitvise SSH server on Server R2/2012 and you can use bitvise tunnelier or putty as the client(maybe others, just have used those two myself) and then connect via management studio once the SSH tunnel is connected. We also require both key and password auth. We also do RDP over the SSH connection as you can't remote to those machines directly.
Earlier quoted context omitted.
We do here where I work. We're running Bitvise SSH server on Server R2/2012 and you can use bitvise tunnelier or putty as the client(maybe others, just have used those two myself) and then connect via management studio once the SSH tunnel is connected. We also require both key and password auth. We also do RDP over the SSH connection as you can't remote to those machines directly.
I'm not sure if $200 in third party software counts as easy. In particular when you could be using RRAS instead, which is built in.