I'm having some trouble with Cassandra's C++ connector. It is set to connect to a cluster (e.g. 10.0.0.10 and 10.0.0.11). One of the hosts has changed address (it's now 10.1.1.10). I've already updated cassandra's configuration, removed 10.0.0.11 from the peers table. Nodetool is already showing the correct cluster configuration.
Yet, the C++ connector keeps complaining about connecting to 10.0.0.11. I have no idea where to find that. Since no production data has been involved (yet), I've destroyed all the data directories and recreated keyspace. Still, this appears to be cached somewhere.
The parameter broadcast_rpc_address in the file cassandra.yaml was set to the old IP address.
This was enough to make the client search for the old IP address. This happens only when the host 10.0.0.10 was the contact point.
Related
I have a Google Cloud compute instance running with Ubuntu 18. We had wireshark running tracking another problem and we noticed that every minute something is accessing the meta data server. Three requests every minute:
GET /computeMetadata/v1/instance/virtual-clock/drift-token?alt=json&last_etag=XXXXXXXXXXXXXXXX&recursive=False&timeout_sec=60&wait_for_change=True
GET /computeMetadata/v1/instance/network-interfaces/?alt=json&last_etag=XXXXXXXXXXXXXXXX&recursive=True&timeout_sec=60&wait_for_change=True
GET /computeMetadata/v1/?alt=json&last_etag=XXXXXXXXXXXXXXXX&recursive=True&timeout_sec=77&wait_for_change=True
In call cases, the wireshark says the source is the IP of my instance, and the destination is the 169.254.169.254 which is the Google metadata server.
I don't have any code we have written that is accessing the server. The first one makes me think that this is some Google specific software that is accessing the meta data? But I haven't been able to prove that. What is worrisome is that the response for the third one contains ssh keys. Also, every minute seem excessive.
I see another post talking about scripts in /usr/share/google, but I don't have that directory. I do see that google-fluent is installed. I also see a installed snap for google-cloud-sdk. Could one of those be it? I don't recall installing them, AFAIK, I am not using it, so if that is it, what is the harm in uninstalling it?
You do not have a problem to worry about. The metadata server is private to your instance. The Google VM guest environment software and Stackdriver (fluentd) are making requests to the metadata server to get credentials, detect changes (new SSH keys), set the clock, etc.
The IP address 169.254.169.254 is an IPv4 Link Local Address. Only your VM has a route to that network.
Compute Engine Guest Environment
Do not attempt to uninstall the Guest Environment. You can remove Stackdriver, but I do not recommend that. Stackdriver provides logging and monitoring features that are very useful.
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...
I have two instances. They are going to run the same app, but one is set up with a slightly different configuration. Right now I can go to their assigned elasticip and see that my site works on both. Th eonly other difference is that one is a micro instance and one is a small instance. Also, I have a bunch of DNS records pointing my domain name to the ip of the micro instance.
But what I want to do is swap them so that the small instance is now my main instance that has my domain pointing to it. I was hoping I could just disassociate the ip's and then reassociate the ip's only flipped around. But when I do that and then try to go to my domain.com I just get an error page. When I swap them back they both seem to work again. Is there something a more complicated I have to do?
edit:
When I try to SSH I also get all this stuff:
###########################################################
# WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! #
###########################################################
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
d6:ed:23:65:9c:da:0c:1b:2d:94:34:18:4d:68:8f:a5.
Please contact your system administrator.
Add correct host key in /Users/croberts/.ssh/known_hosts to get rid of this message.
Offending RSA key in /Users/croberts/.ssh/known_hosts:17
RSA host key for 54.183.212.154 has changed and you have requested strict checking.
Host key verification failed.
Something nasty! haha.
The error message is indicating that the remote computer does not match the computer previously recorded in the known_hosts file.
When using ssh, each computer generates a fingerprint and this is recorded against the computer identifier (eg IP Address) that you are using to connect to the remote machine.
If you are switching an Elastic IP address between instances and also using the Elastic IP address to ssh into the instance, then the error quite correctly is warning you that the computer is not the same computer to which you last connected on that address.
You can remove the offending entry from the known_hosts file, or even delete the whole known_hosts file (which admittedly will remove such warnings even if they are legitimate).
You should have no problem swapping the elastic IP from one instance to another. It can take a few minutes to take effect, so make sure that you can reach the correct instance before testing.
You don't describe the error, but if you are using name-based virtual hosts, and are using a different name, that could be one cause. If you restart apache after swapping EIPs, does the problem go away?
Finally, to fix the ssh error, remove the entry from the known_hosts file - if you read the error message, it's on line 17.
I want to retrieve IP address of my computer (same as I get on http://www.whatsmyip.org/)
I have a win32 project.
This is the code that I am using, as I didnt find any tutorial on this, I could get following info, but not the IP address which I saw for my computer on the whatsmyip.org :(
The IP I got on whatsmyip.org starts with 116.x.x.x
Your code gets adapter addresses, which are local. If you want your Internet address, you need to use the Internet, not your local network. You need to replicate the functionality of asking an external site what IP it sees you connecting from. See here for some suggestions for how to do that.
Retrieving http://icanhazip.com will do it. You can use whatever HTTP library you like.
The IP which assigned to your machine is not necessarily the IP that you see outside of your local network (e.g. in whatsmyip.org).
Your machine is not directly connected to the Internet with a valid and static IP. Maybe you are behind a NAT. So you can not determine your valid IP over Internet by listing your local assigned IPs in many situations.
To findout what IP address you have in Internet, you can do two ways. Ask from someone over Internet (for example, using whatsmyip.org). Or, query your local network recursivly (which is not easy task)
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