No access to kibana from external host even after so-allow - 14.04.5.3 Alpha

[a.bi...@unico.ch]

Hi all

First things first: Thank you Doug and all people involved for making SO!


I just installed the new Alpha release with experimental/production/server/best-practice and configured remote access via sudo so-allow/analyst/IP-of-remote-host

I cannot access kibana via https://ip-of-SO-server/app/kibana
And I get a timeout with telnet IP-of-SO-server 443 from remote (it works locally)
However I do see the packets coming in via tcpdump on the SO server and thus exclude any network related problems outside SO. There is no response visible within tcpdump.

I checked the following as well
- local access to kibana is fine
- sudo ufw status shows access via 22,443,7734 for the remote host
- a tail -f /var/log/syslog |grep "UFW BLOCK" shows no entries for the remote host (sort of redundant I know)
- a tail -f /var/log/apache2/access.log resp. error.log shows no entries either (fits the telnet)
- netstat shows 443 listening
- I checked docker ps for so-kibana and /eth/apache2/sites-enabled/securityonion.conf for the proxy to kibana, but I think the problem occurs before


The sostat-redacted is attached. Thanks for your help

[Doug Burks]

Hi a.bichsel,

Are you able to access the main Security Onion web page at
https://ip-of-SO-server?

> --
> Follow Security Onion on Twitter!
> https://twitter.com/securityonion
> ---
> You received this message because you are subscribed to the Google Groups "security-onion" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to security-onio...@googlegroups.com.
> To post to this group, send email to securit...@googlegroups.com.
> Visit this group at https://groups.google.com/group/security-onion.
> For more options, visit https://groups.google.com/d/optout.



--
Doug Burks

[a.bi...@unico.ch]

Hi Doug
Nope. I tried IP only and Squert as well.
Thanks
Andreas

[Doug Burks]

Looking back at your first email, you say that tcpdump shows the
packets coming in, but you don't see a response. Sounds like perhaps
a routing issue? Is it possible that your main network subnet
overlaps the internal docker subnet(s)?

[a.bi...@unico.ch]

That's it, thanks!

[Hüseyin Fatih Akar]

How did you solve this?

[a.bi...@unico.ch]

Hi Hüseyin Fatih Akar,

My answer probably comes too late. But maybe somebody else wants to know...

I solved the problem by placing the sensor in it's own network (which is good practice anyway) and accessing it over a firewall where I can apply address translation to all accessing hosts.

Cheers
Andreas


On Wednesday, October 3, 2018 at 1:54:57 PM UTC+2, Hüseyin Fatih Akar wrote:
> How did you solve this?