Vulnerability in MS SQL Server 2000

    Hello, habryludi!

    Today I want to share with you one very unpleasant observation about the work of MS SQL Server 2000.

    I work for a company that still uses MS SQL Server 2000 in its branches. I don’t know what goals they pursue with this, but it doesn’t matter, since the system works stably and fulfills goals and objectives.

    Let's start in order. I ask for a habrakat.


    Objectives of the Solution Goal


    MS SQL Server 2000 acts as a database server, collecting and storing information and exchanging it with Moscow and our subordinate offices, which are located at a distance of more than 100 km from our branch, while we ourselves are located at a distance of more than 2500 km from Moscow., this is so for the big picture.

    When a normal and stable Internet access appeared in our branch, as well as in subordinate missions, it was decided to connect files by mail for data exchange. For this, it was decided to connect at that time two ADSL modems in my office and through the DynDNS service for data exchange.

    No sooner said than done

    We register two free accounts on DynDNS.org, get the host, register it in modems in the DDNS section, configure virtual servers in the modems and forward to port 3389 (RDP), for more convenient operation. On this, when connecting to a remote host, via Linux, rdesktop received a mapped drive of his Linux machine and quietly exchanged files.

    The files are Access databases, which are generated on a remote MS SQL Server 2000, and, using programs written by Moscow, are uploaded to my MS SQL Server 2000.

    After such tricky manipulations, the work went faster, but did not work for one, every day started with one :
    In the morning, I came to work, formed a file at my place, connected, formed a file on a remote server, transferred my file to a remote one, transferred from a remote file to my own, uploaded special programs to MS SQL Server. Tired.

    It was decided to combine the two MS SQL Servers using DynDNS with port forwarding in TCP 1433-1434 and UDP 1433-1434 modems.

    No sooner said than done

    We go into the ADSL modem in the virtual servers section, forward the TCP UDP ports. We connect special programs to the remote server and exchange data:
    MS SQL Server branch <-> MS SQL Server representative. Ur would say everything, as I said, but in the morning the most terrible and incomprehensible thing happened. Intrigue?

    The next morning after the automatic exchange of data at night between SQL servers was configured, I received two dead MS Windows 2003. What does the dead mean:
    • my MS Windows 2003 on which there was a branch SQL server, fell off the domain on the network, did not let it go on the ball over the network and after reboot did not connect to the domain.

    • the remote MS Windows 2003 on which the SQL server of the representative office stood, although it somehow responded to the connections, but it behaved extremely inadequately, it would not allow to connect via RDP, then IIS crashed, which was simply necessary in the representative office.

    Fortunately, the backup for my MS Windows 2003 was in the branch for such cases, and the SQL databases were backed up to the SLES server. The work of the branch server was restored in a short period of time. I will remind the remote 100 km. go, was checked for viruses that were not detected! After checking the server manually what was wrong with it, it was found that the owner of the C: drive and the remaining disks on the indefinite one changed on the server. For the sake of interest, I tried to return the administrator on all disks, the Administrator. After several hours of changing the attributes, the server began to work normally. With a calm mind, I checked the exchange and info in the databases, everything was in place.

    In the next morning. The same picture !!! Horror.

    I decided to try the method of restoring the owner on the branch server because the owner was not defined. Restored at home, restored to the remote everything worked. And then the question arose because of what this is happening. The answer was found the next morning, when before that I had remotely cleaned the forwarding of SQL Server ports and remind you of TCP UDP 1433-1434. In the morning, the servers worked without errors.

    Bug? Breaking? Vulnerability? What? It tormented me for a long time, while I was transferring files between computers in the old way. And finally, a fiber optic Internet with white IP appeared in the branch. Well now I think everything will be fine. Although the representative office remained dynamic IP with forwarding to 3389 (RDP).

    Solving the problem of combining SQL servers using OpenSUSE, DynDNS


    The task remains the same, combine the two SQL servers.

    No sooner said than done

    At first there was a simple goal, through OpenSUSE acting as a Router, to forward the port to the SQL network server in the firewall, we write:

    FW_FORWARD_MASQ = "0/0, ip_sql_server, tcp, 1433,1434, our_white_IP 0/0, ip_sql_server, udp, 1433,1434,

    We open ports 1433-1434

    This means that traffic going to the machine with white ip on ports 1433 1434 is redirected to the machine from the SQL server on the internal network.

    From a remote computer, we are trying to connect to the SQL of our network, the connection was successful. Hurrah! But one thing remains, how can my SQL server connect to a remote server. I still decide to forward the SQL port to the ADSL modem of the remote computer. And by means of DynDNS to connect from yourself to it. I forward, connect, exchange data. Well, wait for the morning.

    Morning. Nde. Not so bad this time!
    1. on my server in the root of the C drive: the files are:
    xp5.exe
    server.exe
    hex.exe
    and a bunch of strange dlls
    on the server someone was! :) Also, tasks like a.exe server.exe appeared in job SQL server, and so on, and it’s interesting not to detect it all as an antivirus.
    2. The same story on the remote server.
    But also the ADSL modem is hanging, I can’t remove the probros.
    Simple manual cleaning, deleting these files, killing processes, cleaning SQL job.
    I am connected via telnet, completely reset the modem.
    Reboot

    In general, the solution to this problem was always in sight.

    Climax


    Raise on openSUSE vpn server pptpd (did not bother with openvpn) in the firewall we write:

    FW_FORWARD = ”net_vpn, ip_server_sql_local ip_server_sql_local, net_vpn” The

    remote server connects to the server and only receives IP in the network and the server receives IP. The exchange is normal and calm in the morning.

    That's all. It works like a clock.

    Threat. I wrote from myself, without going into the details of the settings, if I suffer anything wrong in the comments.

    Also popular now: