I am trying to access the Kibana interface remotely and locally. When I change server.host to the IP of the machine, it does not load locally nor remotely. When I set it to 0.0.0.0, I can only access locally. I made sure ufw is off. Selinux is not installed. I've also restarted the Kibana docker container. Is there anything else I can try?
bump
Can you try to curl the host from another one on that port? Did you restart Kibana after making the change? Did you even try to see if the port 5601 is open? Can you pls explain what is exact issue from IP address perspective? What does the logs say and if there a proxy in btw ?
Thanks
Rashmi
Like wget :5601?
Yes, I did restart via docker.
I can not access the Kibana in my web browser, yet I can ssh into it. Firefox says "unable to connect". I can access the web interface on SO itself.
I am running SO on ProxMox Hypervisor.
I confirmed that it is listening:
You'll want to set server.host in your kibana.yml . If you don't, Kibana will default to only binding to localhost . The important part to that is that the container is its own "localhost", so the default value will only allow Kibana to be seen from inside the container , which is clearly not what you want.That's why, in the default config, we set server.host to 0 (shortcut for 0.0.0.0 ). This might be the issue - plz check.
Also a similar thread: Reverse proxy behind nginx docker container not working Kibana 6.2.3 which might have some ideas which you can use.
Thanks
Rashmi
I did set it to "0", then restart the container, and I still can't access it from outside of the box.
@jarpy -whenever you get sometime, can u plz check what might be an issue here?
Thanks
Rashmi
The netstat output that you pasted shows that the docker-proxy process is bound to an address on the loopback interface (127.0.0.1). Thus, it will only respond to requests from the local machine.
With server.host set to 0, Kibana is correctly configured to accept connections from any hosts that are able to make it through Docker networking. You are now faced with the question of how you wish to configure the Docker network in order to expose the Kibana port.
It sounds like you are using some kind of management layer on top of Docker? I don't know what "SO" is but I understand that ProxMox is some kind of VM/container management system.
In pure Docker CLI terms, you could run the Kibana container with --publish=5601:5601 or even with --networking=host to make things really simple.
I did set server.host to 0, and that is still what I am seeing. I even did a reboot of the host.
Sorry, SO is Security Onion: https://securityonion.net/
Thanks. We can be fairly confident that your Kibana is configured correctly. However, you will need figure out a way to configure Docker networking to get the result you desire. If you paste exactly how you are configuring the Docker network and how you are running the container, I might see something I can help with.
The most common approach would be to use the default bridge network that that Docker sets up, and bind the Kibana port to it with --publish.
Like this:
docker run --network=bridge --publish=5601:5601 docker.elastic.co/kibana/kibana:7.6.1
I had to modify the command some, but here is what I got:
sudo docker run --network=bridge --publish=5601:5601 securityonionsolutions/so-kibana
docker: Error response from daemon: driver failed programming external connectivity on endpoint exciting_colden (b9ea74859e094c70348e2df461eb6a5424dac6a396bf9d356e4d4232fc444f94): Error starting userland proxy: listen tcp 0.0.0.0:5601: bind: address already in use.
ERRO[0006] error waiting for container: context canceled
So something is already listening on that port. It's probably another Kibana process.
I've stopped the service, then started it up again with this, and am now getting this error:
docker run --network=bridge --publish=5601:5601 eecb343cfe4b
docker: Error: error contacting notary server: dial tcp: lookup notary.docker.io ... read: connection refused.
Why is it trying to reach out onto the internet when I am only publishing the port locally?
That error message is from Docker, not Kibana. It's trying to contact Notary for image signing information. What image is eecb343cfe4b? Is it one of the Elastic official Kibana images?
https://www.docker.elastic.co/
Even if that message was from Kibana, the listening sockets that you choose to publish don't have any effect on whatever outbound connections a given process chooses to establish.
I'm not sure what your goals are in any of this, but if you want to generally learn about running the Elastic Stack in Docker, I'd recommend following our documentation and getting it running on a conventional distribution like Ubuntu or Fedora. I think that Security Onion is adding a lot of complexity and that means that you have to deal with many complex interactions at the same time.
If your goal is to have a standard Security Onion deployment (which seems to include Kibana out of the box?) then interacting with the Security Onion community might be the best bet. The real question might be "why is SO's implementation of Kibana not working", rather than "why is Kibana not working". It looks like Security Onion's Kibana is supposed to "just work", so if you find yourself running Docker containers manually, something has already gone wrong with the distribution.
It looks like quite a few Security Onion users have a problem like this, so maybe they can help. This comment is interesting:
And this one 
This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.