When a service/app is started it is looking for the assigned network interface to.listen to, having it 0.0.0.0 it means it accepts data and can talk to everyone no matter from where the query comes, so if you have 3-4 network cards on that server with different IPs it means you can insert data from different networks, internal or external, even from localhost ( 127.0.0.1 ),. So let's say you have 2 network cards with IPs 192.168.0.2, 10.10.0.2 and 127.0.0.1. If you set 0.0.0.0 as the ip to listen to, everyone can i sert data or query your db, from 10.10.x.x and 192.168.0.x and 127.0.0.1. If you want it to be accesible from the internet ( which is not really recomended ) you need to know very well your usecase.
If you are behind a personal gateway ( router provided by your ISP ) i would make the ip in the config to be the internal ip of the server that provides internet access ( 192.168.x.x and i recomend port forwarding in the gateway from the public IP to your local on specific ports that you need. DO NOT set the gateway in DMZ towards your elasticsearch internal IP as all the ports of that machine will be exposed to the internet and you open the door for more vulnerabilities not only the database. You can then create rules in the machine's firewall to allow access on those ports only from specific machines using mac address filtering or ip filtering or any other trust mechanism you see fit ( tls and ssl auth might add another layer of security that you need )
If you are behind a corporate firewall make sure your IT dept makes comprehensive rules from the public ip to your elasticsearch server.
If it would be me wanting to provide a customer or some friend access to my data using kibana, grafana or any other custom tool that does not have access to my private network i would vpn the kibana in my network, mKe it talk with the elasticsearch and expose that kibana/grafana/whatever.tool machine only on port 5601 or the proxy port you use but i would stillenforce authentication between the 2 with tls, also activate user authentication and well defined user rights per group, that way not everyone can write or delete from your db.
This is if you want to play and se how things work.
As best practices, i would use one of the main rules in database security : NEVER EXPOSE YOUR DB TO THE INTERNET unless it'sa honeypot
Hope this helps