Seeing proxy requests from the Server to localhost API/info

Roy

unread,

Aug 19, 2016, 7:12:17 AM8/19/16

to security-onion

I noticed that whatever process is initiating http://127.0.0.1:50006/API/info is directing that request to the proxy which is failing as it should. What can be done to stop these requests from being directed to the proxy?

Wes

unread,

Aug 19, 2016, 8:42:05 PM8/19/16

to security-onion

On Friday, August 19, 2016 at 7:12:17 AM UTC-4, Roy wrote:
> I noticed that whatever process is initiating http://127.0.0.1:50006/API/info is directing that request to the proxy which is failing as it should. What can be done to stop these requests from being directed to the proxy?

Roy,

I would assume this is ELSA reaching out to a node/sensor.

You could identify the node/sensor associated with this port in /etc/elsa_web.conf and remove the configuration for it to see if it helps.

Thanks,
Wes

Roy

unread,

Aug 22, 2016, 7:50:57 AM8/22/16

to security-onion

Wes, all the sensors ports are doing this on the server and the /nsm/elsa/data/elsa/log/web.log shows the following process making these attempts.

* ERROR [2016/08/22 08:36:09] /opt/elsa/web/lib/Controller.pm (883) Controller::__ANON__ 107773 [undef]
malformed JSON string, neither tag, array, object, number, string or atom, at character offset 0 (before "<HTML><HEAD>\r\n<TIT...") at /opt/elsa/web/lib/Controller.pm line 877.

I'm not sure what changed recently but I believe this is causing the high number of Perl processes.

I'm also seeing issues with recent updates to pulledpork...

Wes

unread,

Aug 22, 2016, 6:39:44 PM8/22/16

to security-onion

Roy,

I have not experienced an abnormal amount of Perl processes, and I am running the latest updates.

Please include the output of sostat-redacted, attaching as a text file, or using a service like Pastebin.com.

Have you seen the following?

https://github.com/Security-Onion-Solutions/security-onion/wiki/FAQ#why-does-sostat-show-high-loadcpu-usage-and-large-number-of-perl-processes

What is the output of the following?

sudo mysql --defaults-file=/etc/mysql/debian.cnf -Delsa_web -e "select * from saved_results";

Thanks,
Wes

Roy

unread,

Aug 24, 2016, 1:00:41 PM8/24/16

to security-onion

I fixed the issue with the saved results by doing the previously provided steps. I still see the local host from the server hitting the proxy. I do have the no_proxy variable set to not use the proxy for local host but it doesn't look like that process is either using it or it isn't set for the user running the process...

Roy

unread,

Aug 24, 2016, 1:03:41 PM8/24/16

to security-onion

John Henkins

unread,

Jan 24, 2017, 6:24:35 PM1/24/17

to security-onion

On Friday, August 19, 2016 at 6:12:17 AM UTC-5, Roy wrote:
> I noticed that whatever process is initiating http://127.0.0.1:50006/API/info is directing that request to the proxy which is failing as it should. What can be done to stop these requests from being directed to the proxy?

Roy,

I was having the same issue. In /opt/elsa/web/lib/Controller.pm, there are multiple references were the file will unset the proxy value if the $peer is defined as 127.0.0.1 or localhost.

if ($peer eq '127.0.0.1' or $peer eq 'localhost'){
push @no_proxy, proxy => undef;
}

The $peer variable contains the name of the sensor that has been setup from /etc/elsa_web.conf. Security onion is using tunneling to encrypt the communication on the request.

I solved the problem by unsetting the http_proxy environment variable in:
/opt/elsa/contrib/securityonion/contrib/securityonion-elsa-cron.sh

#!/bin/sh

eval $(perl -Mlocal::lib=/opt/elsa/perl5)
unset http_proxy
perl /opt/elsa/web/cron.pl -c /etc/elsa_web.conf

The longer term solution, might be to add code in elsa to look at the URL to see if it is also being sent to 127.0.0.1/localhost. On a side note, if you modify the file on the next update you may have to check it again.

Hope this helps.

Reply all

Reply to author

Forward