I'm creating a program which requires me to access my online MySQL database from a local computer.
In my cpanel there is a section that says 'Remote Database Access Hosts' would I add the local computers IP address in this situation? Will that remain constant, over years time, if its the same computer every time?
If you're trying to access it from a "local" computer meaning another computer on your intranet, then find the intranet ip for that computer. Typically it will be 192.168.1.101 or 101 maybe 102, 103, 104, etc. So, if your router assigns IPs to the 192.168.1.* domain, you can add 192.168.1.% to that list and all computers on you intranet will be able to access the MySQL database.
Note: some routers you might need to add 192.168.10.% or 10.0.0.%, it just depends on how your router assigns internal IPs.
If you're using windows, you can open a command prompt (go to run->"cmd") and type "ipconfig"
Use the first three numbers from the Default Gateway and replace the last with a % sign.
Probably an IP address that you'll have to obtain. We use both, something like 167.155.126.86 or mysql.ourdomain.com (which works when we roll over to our failsafe sites when the main ones are under maintenance)
Will that remain constant, over years time, if its the same computer
every time?
It's not up to the computer, it's up to the IP-Address. If you don't have a static IP-Address, you may be in trouble in the next 24 hours (ISPs tend to do that on 24h basis).
You may want to have a look at services similar to DynDNS, No-IP, FreeDNS or similar.
I just realised that DynDNS is sadly no longer for free...
Go in to Remote database host.
Enter the value %.% within the host input box and Add.
Now that connection will be available to connect from any site and from localhost too.
Related
When tyring to login to RDP the "old" remote dekstop connection gave "an internal error occured"
And the new modern UI remote dekstop from windows store with version 10.2.1810.0 gave: error code 0x4 remote desktop
It seems a colleage has been logged in with wierd screen size. How can I resolve this without rebooting the machine?
I found a solution.
In the new GUI untick:
"Uppdatera fjärrsessionens upplösning vid storleksändring" in Swedish
Which translates to: Update the resolution of the remote session when resizing
Update remote sessions resolution when size change
Actually, even moving the port off 3389 doesn't help (for long)
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\PortNumber
if there is an open port allowing RDP they will find it eventually and you will need to implement one of the above programs noted by Daniel. That was exactly my issue as well. You can usually tell if the problem is intermittent since it's just luck to get by the constant pounding on the open port...
For me, it was the graphic choice. No idea why but as I swap between the 4 options, only one works
I needed to set it to Highest Quality (32 bit)
However, I then restarted the server, and it no longer worked but True Colour (24 bit) did work! So, hopefully by toggling through each will get you through
In my case the cause was AVG Firewall blocking some RDP connections. I had to configure AVG Remote Access Module to allow RDP connections from some known IP addresses.
Hope this helps someone.
Looks like this error code pop up for many things... from screen resolution resize to colour depth to firewall and more... Which is quite odd. You have to check what is your specific case.
In my case, when I had problems with error code 0x4, it was related to unprotected RDP port.
In my case, it was caused by open, unprotected, RDP port 3389. As many would guess, this is a highly targeted port by bots. If your port is open to anyone in the internet, it's just a matter of time that your server or computer will be targeted.
The best solution would be to only allow connections from trusted IP addresses, the ones you use for connecting to your server.
Of course, that can't always be possible, so another solution would be something like the fail2ban utility used on many Linux servers.
The two solution I've found are EvlWatcher which is free and open source, and IPBan that have a free and open source version, but also a paid version.
You only need one of them, as they do the same thing. Do not install both. They will scan your logs and will temporary or permanently block any IP address with repeated fail connections. I suggest you always have your main IP address whitelisted, so you don't lock yourself out.
Best regards to you all.
I'm trying to make my first basic web server to host a wordpress website using a Raspberry pi 3, nginx, php7.0, mysql and phpmyadmin.
I have set everything all right, I can access the wordpress site and edit it when I'm connected to my router, but once I try to access it from outside using my phone network, it loads but it shows no images and the website looks totally disorganized.
I'm using no-ip to get a static IP, I have set the router DMZ on the Pi and it's connected through WiFi, so there should be no firewall between the Pi and my phone.
I really don't get why this is happening, it looks like something is blocking some parts of the info exchange, could this be my ISP and the solution would be to change the website port from 80 to another one? I'm starting to discard this option because when I access from outside to the phpmyadmin management site, it loads correctly, including all images.
As I said this is my first experience and I don't know what else to look, I would really appreciate help from more experienced users.
WordPress uses two configuration variables to determine the address of the site and the address of resources for the site. See changing the site URL for details.
You currently have these values set to an internal address that cannot be resolved to your static IP.
If you set the values to your external address (used by your phone network to access the website), the external access should begin to work, e.g. http://example.ddns.net/. However, a negative side-effect is that internal access may stop working!
You should be able to make both internal and external access work, by removing the scheme and hostname from the values, and setting only the path component, e.g. /.
I got a multisite network, and got subsites on it, unfortunately the main domain has expired, and I cannot access my WP admin. I don't worry about the main site but I need to have the subsite.
I am able to access the main site using the IP but not its WP admin. I tried following this but it didn't help. I saw a way via accessing database (this method) but I couldn't access database as its hosted in Digital Ocean, it's pretty hard without a control panel.
want a way to access main sites WP admin
access my subsite via URL (it has a separate domain which is being masked)
If your domain has expired, ordinary DNS will not work. This means that domain-based hosting on the web server will no longer operate as well.
However, you can easily trick your local machine into thinking the domain still exists. This will work on Linux and OS X. You'll need to know the IP address of your web server - if you do not have this, you'll have this in the welcome emails you've received from your web host, or perhaps by logging onto your customer control panel.
Edit your /etc/hosts/ file. In a blank link at the end, add this:
yourdomain.tld 1.2.3.4
where 1.2.3.4 is your IPv4 address. The gap between the two can be any number of spaces or tabs.
Once this file is saved, you should be able to ping it thus, in a console or terminal utility:
ping yourdomain.tld
and it will show you what IP address you have assigned it to.
You can then access it normally. Bear in mind, though, that only you have the DNS information, so it will not work on any other machine. It will however allow you to access your WordPress control panel.
Three weeks ago, I found a list of my website's users and info on Paste Bin giving away all privacy. I ran updates and protected against SQL Injections. I also added a pre-request to save the SQL in text format in a LOG table whenever user input is required to be able to analyse any injection if my protection wasn't enough.
Then today the same post was on Paste Bin again with recent entries so I checked the LOG table to find only clean entries. Is there anything else than injections I should worry about? The web seems to give info about Injections only!
Could they have had access to the dbpassword in a php file on the server and could they have connected from and external server?
Should I change the dbpassword frequently?
Are there any solution non-script wise like hosting security plan or something like that which should be efficient enough?
I am receiving physical threats from hacked users and would really like to close this quickly...
If you're implementing your own protection against user input, you're probably doing it wrong. Most standard database libraries will give you a way of passing in parameters to queries where it will be sanitised properly, and these will have been coded with more things in mind than you're probably aware of. Reinventing the wheel in anything security-related is a bad idea!
Other things to worry about:
Password policy (strong passwords)
Access to your database server (is it firewalled?)
SSH access to your server (again, firewalled?)
Keeping all of your software up-to-date
Just to add to the other answers that you've had so far. If someone is posting the contents of your database online then you need to assume that the server(s) running the application and database have been compromised, as once they've gained initial access, it's likely that they'll have placed root-kits or similar tools onto the server to keep access to it.
As to how they got in there's a number of potential options, depending on the architecture of your solution, and it's imposssible to say which is the case without more details. Some of the more likely options options would be
SSH passwords
Administrative web apps (e.g. PHPMyAdmin) with common passwords or vulnerabilities
Access via hosting service (e.g. weak passwords on administrative login panels)
If the site is PHP based Remote File Inclusion issues are a distinct possibility
If you can I'd recommend engaging a forensics or incident response company to help you recover the data and rebuild, but failing that I'd recommend getting a backup from before the compromise and using that to rebuild the server, then ensure that all software is updated and patched and passwords are not the same as the compromised system, before bringing it online.
The best protection for this is to allow connections to the mysql database only from the machine where your application runs.
First of all, make sure, network access to the MySQL database is "need to know" - in most cases this is a simplye bind-address 127.0.0.1.
Next change the DB password, just because yes, you can (C)
Now think of this: If somebody got your DB passwd from your PHP files, you already are in deep s***t: Nothing stops him or her from just repeating that stunt! You need to audit your application for backdoors (after the fact problem) and how the guys got in there (before the fact problem). Check your apache logs for requests with unusual GET parameters - a filename in there mostly is a dead givaway.
I agree with Razvan. Also if you're running any CMS or prepackaged web pages, make sure they're the latest version. They most likely access as localhost from the web server. Hackers follow the change logs of those and every time a security patch is released, they attack published vulnerabilities on servers running the older version. It's often performed in bulk by crawlers. Odds are they have a database with your server listed as running old versions of things.
First you need to ensure that this "php file" containing the DB password(s) is not within the web root directory, otherwise they could simply access it like: http://mydomain.com/dbpassword.php.
Second, immediately change the passwords used to access your database.
Third, ensure that mysql will only accept connections from 'localhost', vs allowing connections from anywhere; '%'. And if it is a dedicated server, then you should "harden" the box and add an IP rule to IPTables where mysql access is only allowed from the server's IP. These changes would ensure that if they did get your db username/password creds, they can not access the database from a remote computer, instead they would have to exploit your application, or ssh into your server to gain access to your database.
Next, you should disable all user accounts to your site, and force them to update their passwords using a closed loop verification process. This will ensure no ongoing malicious activity is occurring with your users or their accounts.
These are just a few steps to take, there are others such as tracking local users login activity. It is possible that one of your system's user accounts has been compromised (rooted). The point is, you need to consider all points of access to your system and services therein, if you are unable to do it, it may be time to hire or contract a seasoned sysadmin to help you.
If this is shared web hosting, and another user is logged in with shell access and is able to guess the path to your web root, and the password configuration (PHP or other script) file is world readable, then the user can read it.
This is one of the most common vulnerabilities and is very easy to exploit.
If this is the case:
To correct the issue, you need to move the configuration file out of your web root folder and/or change the permissions on it so that it's not world readable, and then change your database password.
Most likely, the user would not be able to inject anything into your application.
Changing the database server so that it's only accessible locally or to your web server would do no good, since the malicious user would be on the same web server and still be able to access it.
If you did not see any malicious queries, then they are probably accessing your db via the MySQL command line (or PHPMyAdmin or other tool), and not through your application.
Enabling the general query log would allow you to see all queries in plain text in the log, but if this is shared web (and MySQL server) hosting, you probably won't be able to enable this.
This is something you may wish to report to your web host. They may be able to find the attacker and suspend their account or provide you with evidence.
I am actually trying to connect to a .mdb Database with ODBC per PHP.
On my localhost it works great, but when transferred to my mapped server it isn't anymore.
I know, it is a problem of UNC and mapped drives. I already tried
\\Users\[...]\test.mdb
and
C:\[...]\test.mdb
First one throws S1009 as error, the second one S1000. What can I do? It is a System DNS on a Windows Server 2008, ODBC is running, no Access installed.
When you map drives or use UNC Paths, the files there will be requested in the security context of the webserver. With close to 100% probability the webserver user has no access to the fileshares in your LAN.
Keep it that way amd have the mdb reside on a drive that is local to the webserver, if ever possible.
First, make sure you're using a proper UNC path. For example: \\Computername\Share\test.mdb. StackOverflow might have eaten any double-backslashes you entered, so this may be a moot point.
Second, make sure the share's permissions are set up for whichever account runs the PHP script. This is the cause of most "scripts can't access a share" errors in my experience.