So today I was in my MongoDB and I type in show dbs. Other than my usual dbs there is an additional hacked_by_unistellar. Anyone might know what I can do here? It sounds like I have been hacked unless this is some terrible easter egg I have come across. Please advise. Thank you.
you should close your default mongoDB Port 27017. Got the same problem
I had the same on an old backup server as well.
All I can say is that it is not related to an open, public mongodb port. The mongo server is running on localhost only, but has no access password (under FreeBSD 12).
Obviously, running with a public default port and no password is just what it is, but that's not the answer.
The only ports open on the server is SSH, 80/443 (running Apache 2.4.x) and a node service at port 3xxx, along with Mongo Express (also password protected).
There is also a MySQL server installed with no password, bound to localhost only, but that remained untouched.
It seems more likely that this is a vulnerability somewhere else, that is exploiting a non-protected local connection to mongodb.
Password protecting mongo might protect the database, but does not identify the point of access, which is worrisome.
All of my data is gone!
Well, my only action now is to close any more open connections to my DB instance. My database required a password to access (so, being passwordless was not the issue).
However, I just added a Basic Firewall to bump up the security a bit, at least, now I can assume no remote access can connect directly to my DB instance.
I followed this thread
Jump to Step Seven — Set Up a Basic Firewall part of the post.
https://www.digitalocean.com/community/tutorials/initial-server-setup-with-ubuntu-16-04
Also, you can allow only some IP addresses to your DB instances. By following the instructions at https://www.linode.com/docs/security/firewalls/configure-firewall-with-ufw/#advanced-rules
I use this personally on my main instance where I trust connections would come only from one IP.
Hope this helps someone temporarily till a better fix emerges.
Are your MongoDB password protected? if so, you can access the Database with only an IP address and the port.
If your MongoDB isn`t password protected, please do it asap! your info is exposed to everyone...
Even big companies do this mistake from time to time as well...
Related
I'm unfamiliar with this terrain, so if any one can guide me in a step by step manner- it would really help. My MySQL database sits on a AWS host X- "ec2-xxx-xxx-xxx-xx.compute-1.amazonaws.com". It is blocked to access from individual local machines and is usually accessed from another working server Y- "ec2-yy-yyy-yyy-yy.compute-1.amazonaws.com" through port '3306'. Now it is especially inconvenient to access this via terminal SSH every time and scripts while they run, its hard to prototype or build an elaborate app. I'd like to set up a SSH tunnel from my local to server Y to be able to access MySQL host X from my local machine, to run queries from my locally deployed Jupyter notebook as well as local working-in-progress Django web app.
The reason why I ask for something more step-by-step is that I have to port forward to another server hosting a redis database which again is accessible through a specific server only. So, I'll be able to carry the solution from here to there too. I'm willing to go into chat as well if needed, but I need to resolve this rather quickly. Thanks!
PS: I've tried many guides off of the internet, but nothing has worked, it's become clear to me that I'm missing some foundational understanding or pathway. That's why I'm here, trying to start from the ground.
I am migrating my vCenter Server 5.5 to a new server (databases have already been moved to a new SQL server and all is OK on existing vCenter Server 5.5 implementation). When I begin the simple install process on the new vCenter Server host the Single Sign-On component presents me with an IP address of 10.10.10.117 as the ip address of the FQDN file01.xxxxxxxxx.com. This is the iSCSI interface address. I need it to use the 10.1.1.17 ip address that is the address of the production NIC that the ESXi 5.5 hosts will be communicating with. I have already changed the binding order of the NIC cards and flushed the DNS cache. I also added file01.xxxxxxxx.com with the proper IP address to the hosts file and also file01 to the hosts file. Still, during the install, 10.10.10.117 is discovered. Thanks in advance! Babak C.
Just to get a quick clarification...are you freshly installing vCenter 5.5? Or are you migrating an existing vCenter server to a new host and using the update utility to upgrade? I am assuming you are doing a fresh install based on your details about the SQL server and SSO. Here is my suggestion, in case it is a fresh install.
We had a similar problem with 5.5 on a new install where the IP address that was discovered during the actual vCenter Server install was that of the public facing NIC which we never use for management traffic (it's for internet access on the vC server, for update manager, etc.)
The strange thing is that there had NEVER been an entry in ANY of our DNS servers for that interface. So, after looking into it a little bit, I started thinking the IP that was returned during install was not a DNS result at all. Rather, it was (most likely) simply gathered from the interfaces on the Server based on binding order (e.g. which NIC has the default gateway.)
In order to save having to uninstall and clean up a major mess if the install completed wrong, we stopped and got in touch with VMware support. They suggested we clear all of the temporary files both in the standard "temporary" folder on windows as well as under /ApplicationData/vmware/xxx, where 'xxx' would be whatever product is giving you trouble and HAS NOT been FULLY INSTALLED* (e.g. you started the install and noticed the incorrect IP, so you terminated the installer and there is metadata and cached files remaining from the partially run install).
Basically, what we had to do, was clear the temporary files and then make sure the NIC Binding Priority was correct (so you should check in Network Adapters|(press-alt)|Advanced Settings. Make sure the correct binding is checked (e.g. if you don't use IPv6 on the private network, clear it) and make sure that the Windows Network is at the top of the priority list on the second pane of the advanced settings. This helps tremendously with SSO by making sure the Windows Network stack is the first queried when you are signing in and SSO must submit a kerberos ticket to the AD DC for validation.
It is possible, that once you delete the partial install files and temporary files and fix the network settings (probably be a good idea to reboot as well), the next time you run the installer you might have success.
I will try to check this post later to see if it helped you at all... or it I just succeeded in making your life even more difficult (which I certainly hope not!) :)
One more thing...prior to initializing the installer, open up a PS session, perform ipconfig /flushdns and then ping the hostname of your vCenter server in order to get it in the DNS cache. You should also perform the following:
nslookup
NS>{your vcenter server IP address}
/* make sure the resulting hostname is correct..this ensures your PTRs and rDNS is working correctly. vCenter HEAVILY relies on accurate reverse DNS configuration...then do the following lookup for forward DNS */
NS>{your vcenter server FQDN}
Hope it helps. Best of luck my friend!
SIETEC
We have a product we are deploying to some small businesses. It is basically a RESTful API over SSL using Tomcat. This is installed on the server in the small business and is accessed via an iPhone or other device portable device. So, the devices connecting to the server could come from any number of IP addresses.
The problem comes with the installation. When we install this service, it seems to always become a problem when doing port forwarding so the outside world can gain access to tomcat. It seems most time the owner doesn't know router password, etc, etc.
I am trying to research other ways we can accomplish this. I've come up with the following and would like to hear other thoughts on the topic.
Setup a SSH tunnel from each client office to a central server. Basically the remote devices would connect to that central server on a port and that traffic would be tunneled back to Tomcat in the office. Seems kind of redundant to have SSH and then SSL, but really no other way to accomplish it since end-to-end I need SSL (from device to office). Not sure of performance implications here, but I know it would work. Would need to monitor the tunnel and bring it back up if it goes done, would need to handle SSH key exchanges, etc.
Setup uPNP to try and configure the hole for me. Would likely work most of the time, but uPNP isn't guaranteed to be turned on. May be a good next step.
Come up with some type of NAT transversal scheme. I'm just not familiar with these and uncertain of how they exactly work. We have access to a centralized server which is required for the authentication if that makes it any easier.
What else should I be looking at to get this accomplished?
Is there no way this service can by hosted publicly by you or a hosting provider rather than with the customer?
I had a similar situation when I was developing kiosks. I never knew what type of network environment I'd have to deal with on the next installation.
I ended up creating a PPTP VPN to allow all the kiosks to connect to one server I hosted publicly. We then created a controller web service to expose access to the kiosks that were all connected via the VPN. I'm not sure how familiar you are with VPN's but with the VPN connection I was able to completely circumvent the firewall in front of each kiosk by accessing the kiosk via the VPN assigned IP.
Each kiosk node was incredibly easy to setup once I had a VPN server setup. It also brought management benefits and licensing revenue I originally didn't think about. with this infrastructure I was easily able to roll out services accessible via mobile phones.
Best of luck!
Solutions exist to "dynamically" access a software on a computer behind a NAT, but usually mostly for UDP communication.
The UDP hole punching technique is one of them. However, this isn't guranteed to work in every possible situation. If both sides of the communication are behind a "Symmetric Cone NAT" it won't.
You obivously can reduce the probability a client can't communicate using UPnP as a backup (or even primary) alternative.
I don't know Web Services enough and don't even know if using UDP for your webservice is an option (or if it is even possible).
Using the same technique for directly TCP is likely to fail (TCP connections aren't stateless - that causes a lot of problems here).
An alternative using the same technique, would be to set up some VPN based on UDP (just like OpenVPN), but as you stated, you'll have to manage keys, certificates, and so on. This can be automated (I did it) but still, it's not really trivial.
===EDIT===
If you really want to use TCP, you could create a simple "proxy" software on the client boxes which would serve as a relay.
You would have the following schema:
Web Service on client boxes, behind a NAT
The "proxy" software on the same boxes, establishing an outgoing (thus non-blocked) TCP connection to your company servers
Your company servers host a WebService as well, which requires a something like a "Client Identifier" to redirect the request to the adequate established TCP connection.
The proxy program interrogates the local WebService and send back the response to the company servers, which relay the response to the originate requester as well.
An alternative: you might ask the proxy software to directly connect to the requester to enhance performance, but then you might encounter the same NAT problems you're trying to avoid.
It's things like this that are the reason people are tunneling everything over http now, and why certain hardware vendors charge a small fortune for Layer 7 packet filtering.
This is a tremendous amount of work to fix one problem when the customer has at least three problems. Besides the one you've identified, if they don't know their own password, then who does? An administrator who doesn't work there anymore? That's a problem.
Second, if they don't know the password, that means they're almost certainly far behind on firmware updates to their firewall.
I think they should seriously consider doing a PROM reset on their firewall and reconfiguring from scratch (and upgrading the firmware while they're at it).
3 birds, one stone.
I had to do something similar in the past and I believe
the best option is the first one you proposed.
You can do in the easy way, using ssh with its -R option, using
publick key auth and a couple of scripts to check for
connectivity. Don't forget the various keep alive and timeout
features of ssh.
Don't worry about the performances. Use unprivileged users and ports
if you can. Don't bother to setup a CA, the public key of each remote
server is easier to maintain unless you are in the thousands.
Monitoring is quite simple. Each server should test the service on the
central server. If it fails either the tunnel is down or there's no connectivity.
Restarting the tunnel will not harm in any case.
Or you can do it at the network level, using IPsec (strongswan).
This can be trickier to setup and it's the option I used but I will
use SSH the next time, it would have saved me a lot of time.
+1 for going with a SSH tunnel. It's well known, widely available and not too hard to configure.
However, as you point out, you are running SSL already, so the SSH encryption is redundant. Instead of SSH you could just use a regular tunneling proxy, that provides the tunnelling without the encryption. I've used this one in the past, and it has worked well, although I didn't load test it - it was used with just a handful of users.
Here's a blog from someone who used the tunnelling proxy to access his webcam from outside his firewall.
Set up an Apache in front of your Tomcat. This Apache should be visible from the internet, where the Tomcat should not.
Configure Apache to forward all traffic to the Tomcat. This can easily be accomplished using mod_proxy (check out the ProxyPass and ProxyPassReverse directives).
Have your SSL certificate located in the Apache, so that all clients can talk HTTPS with the Apache server, which in turn talks plain HTTP with Tomcat.
No tunneling or other nastyness + you will be surprised how easy it is to configure Apache to do this.
If you want to have a RESTful integration to the client server, a tunnel to the central server that works as a proxy, seems the best approach.
But if this is not a hard requirement, you can let the central server handle the RESTfull stuff and integrate the central server and client server with other middleware. Good candidates would be RMI or JMS. For example, a RMI connection initiated by the client allows the server to do RMI calls to the client.
You could try to connect to an pc/ server and tunnel all the data via hamachi (Free VPN Software) because this tool you can install and it will create a reverse connection (from inside your nat to outside) so you can connect to it
site: http://hamachi.cc/
I created a web app with Django and I have it running on localhost (http://127.0.0.1:8000/), my question is, how can I make it available to the world, using Mac OS X's web sharing or something?
Thanks!
While you start the server specify the public ip or for any ip use 0.0.0.0
Example:
sudo python manage.py runserver 0.0.0.0:80
If you start your application without ip and port its bind only for loopback which is 127.0.0.1 and will not accessible in your network.
First off, I would strongly suggest you not to serve a website from your Mac. It's a really bad idea™. Both Mac OS X web sharing and Django's included http server (which I assume you're using) are intended for testing purposes only, for a number of reasons concerning speed, security et al. which is frankly too long to post here (but I hope that someone will :)
Second, it's already open to the world: anyone can connect to your computer using your IP address instead of the loopback 127.0.0.1 (unless you're NATted). This, again, is quite useful to test it (and have your friends/colleagues/boss) test it temporarily, but again is not fit for production use. Really.
It depends what your real purpose is, what you mean by "available to the world...or something". If you do want it to be permanently accessible from the web, you need to host it on a server (be it shared or dedicated), you won't keep your Mac turned on forever, will you? :)
For hosting Django on shared hosting - I'd recommend webfaction, step-by-step tutorials on setting up Django project can be found in their screencasts and forums (9.50$ per month for basic plan, with two months money-back guarantee, which actually works, tried myself:). More options in Djangofriendly.com
For dedicated server, ask yourself if you favor managing whole server(OS, web server, database server, memcache, firewall, backups...)yourself. If the answer is "yes", check out Linode, Rackspace, or Slicehost or even amazon web services, but bear in mind it's more expensive, it's way more complicated, but that's what gives you the ultimated flexibility. Once you are ready to try - this is one of the best tutorials i've found in net for a given subject.
If all you need is a proof of concept, that "whatever i can access from my web browser, should be accessible from anywhere in the world", ask your ISP if you are given the private IPaddress. If not, hm, better go for options mentioned above :) If you do, then find out what IP it is by visiting whatismyipaddress.com. Then start the web server as Prashanth suggested, and enter the IP address from whatismyip.org in your browser. Get nothing? a)turn off firewall of MacOSx. still nothing? b)connect your Mac directly to ethernet cable your ISP provides, without router in between. Retry entering your ouside IP in the browser. Works? great, go google "Port forwarding ", this will tell you have to configure your router to have the same effect when router is being used. Doesn't? Ask separate question in stackoverflow and provide as much details about what you are doing as you can.
Mac os Web sharing is uselless if the packets aren't routed correctly to reach your computer on a network. I guess all it can do is start apache, and open some ports in a firewall. But if your personal router or ISP wont forward external packets to your computer - you won't get what you want.
Good luck!
I'm pretty perplexed... I've got 5 different test computers, all relatively blank Windows XP machines running similar hardware specs. I run a silent install of the FireBird (Classic) database and my application. Some computers require "localhost:" (or 127.0.0.1) before the database location to make a connection, and some simply don't work at all! This is running the exact same software across the board. Does anybody have any suggestions as to what needs to happen to make the connection string universal, or what I could be doing wrong??
It's firebird version 2.1.1.17910 Classic
By the way, i tried connecting to the same database using FlameRobin (a small db management tool) and it worked just fine on the computers that don't connect.
Any more information necessary just let me know! Thanks a lot in advance
For anybody's future reference, the answer is in the services. Apparently it's not being registered as a service for some reason, and on the working computers, was at some point registered, probably through some sort of far earlier tests of Interbase is my best guess.
C:\Windows\System32\drivers\etc and opening up the file 'services' and adding the following line allows the server to run properly.
gds_db 3050/tcp
I'm not sure whether you are aware of that, but a connection string without "localhost:" or "127.0.0.1:" in front of the database name or alias will use the local protocol, which can't be used when connecting to Firebird Classic Server (see this link for more information). If a host name or IP address is given, then TCP port 3050 will be used for the connection.
If you have registered a server in FlameRobin, and did not leave the hostname field in the registration dialog blank, then the host name will be part of the connection string. That would explain why you can connect using FlameRobin.
As for the differences between the machines: You should first go to the Firebird Server Manager applet and make sure that the server is indeed running on all machines, and that the version is the same.
Does it have something to do with the hosts file on some of the computers? Or is that what you're referring to with your
Some computers require "localhost:" (or 127.0.0.1) before the database location...
comment?