Unable to determine host for current URL [SYS0107]

tbaatar · 2014-02-23 13:16:01 UTC

Hi,

I just got this error on 3 live running website, all running different versions and were installed at different date to one another.

Any ideas why this would happen?

Thanks.

Here is the error message.

*MySource Error*File : [SYSTEM_ROOT]/core/include/general.inc
Line : 806
Version : 4.18.2
DB Type : pgsql

Unable to determine host for current URL [SYS0107]

*User Details*
IP Address: 95.174.38.205
User-Agent: Mozil95.85.28.9, Mozilla/5.0 (Windows NT 6.1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.107 Safari/537.36

*Back Trace*
0 => array (
"function" => "sq_error_handler",
"args" => array (
0 => 256,
1 => "Unable to determine host for current URL [SYS0107]",
2 => "[SYSTEM_ROOT]/core/include/locale_manager.inc",
3 => 547,
4 => array (
[Max Depth Reached]
)
)
),
1 => array (
"file" => "[SYSTEM_ROOT]/core/include/locale_manager.inc",
"line" => 547,
"function" => "trigger_error",
"args" => array (
0 => "Unable to determine host for current URL [SYS0107]",
1 => 256
)
),
2 => array (
"file" => "[SYSTEM_ROOT]/core/include/general.inc",
"line" => 1472,
"function" => "raiseError",
"class" => "Locale_Manager",
"object" => new Locale_Manager Object (
"locale_stack" => array (
[Max Depth Reached]
),
"_strings" => array (
[Max Depth Reached]
),
"_errors" => array (
[Max Depth Reached]
),
"_internal_messages" => array (
[Max Depth Reached]
),
"\0Locale_Manager\0_assets_included" => array (
[Max Depth Reached]
),
"\0Locale_Manager\0_packages_included" => array (
[Max Depth Reached]
),
"\0Locale_Manager\0_core_included" => array (
[Max Depth Reached]
),
"_tmp" => array (
[Max Depth Reached]
)
),
"type" => "->",
"args" => array (
0 => "SYS0107",
1 => 256,
2 => array (
[Max Depth Reached]
)
)
),
3 => array (
"file" => "[SYSTEM_ROOT]/core/include/general.inc",
"line" => 806,
"function" => "trigger_localised_error",
"args" => array (
0 => "SYS0107",
1 => 256
)
),
4 => array (
"file" => "[SYSTEM_ROOT]/core/include/general.inc",
"line" => 640,
"function" => "current_url",
"args" => array (
0 => ,
1 => 1
)
),
5 => array (
"file" => "[SYSTEM_ROOT]/core/assets/system/session_handling/session_handler_types/session_handler_default/session_handler_default.inc",
"line" => 63,
"function" => "sq_web_path",
"args" => array (
0 => "root_url"
)
),
6 => array (
"function" => "init",
"class" => "Session_Handler_Default",
"type" => "::",
"args" => array (
[Empty]
)
),
7 => array (
"file" => "[SYSTEM_ROOT]/core/include/mysource.inc",
"line" => 308,
"function" => "call_user_func",
"args" => array (
0 => array (
[Max Depth Reached]
)
)
),
8 => array (
"file" => "[SYSTEM_ROOT]/core/include/init.inc",
"line" => 283,
"function" => "init",
"class" => "MySource",
"object" => new MySource Object (
"db" => ,
"\0*\0_db_conns" => array (
[Max Depth Reached]
),
"\0*\0_db_stack" => array (
[Max Depth Reached]
),
"\0*\0_run_level_stack" => array (
[Max Depth Reached]
),
"\0*\0_context_stack" => array (
[Max Depth Reached]
),
"backend" => ,
"am" => new Asset_Manager Object (
[Max Depth Reached]
),
"tm" => ,
"pm" => new Performance_Manager Object (
[Max Depth Reached]
),
"\0*\0ms" => ,
"\0*\0mm" => ,
"\0*\0hh" => ,
"\0*\0wm" => ,
"\0*\0fv" => ,
"\0*\0em" => ,
"\0*\0tag_manager" => ,
"lm" => new Locale_Manager Object (
[Max Depth Reached]
),
"\0*\0trigger_manager" => ,
"log_manager" => ,
"user" => ,
"frontend_asset" => ,
"\0*\0_user_is_root" => ,
"\0*\0_user_is_sys_admin" => ,
"\0*\0_user_is_public" => 1,
"\0*\0_msgs" => ,
"\0*\0_global_defines" => ,
"\0*\0_deja_vu" => new Deja_Vu Object (
[Max Depth Reached]
),
"_tmp" =>
),
"type" => "->",
"args" => array (
[Empty]
)
),
9 => array (
"file" => "[SYSTEM_ROOT]/core/web/index.php",
"line" => 28,
"args" => array (
0 => "[SYSTEM_ROOT]/core/include/init.inc"
),
"function" => "require_once"
)

nnhubbard · 2014-02-23 18:48:59 UTC

We are getting this on all our sites too, but it is saying:

*Current URL*
http:///HNAP1/

I read that the reference to HNAP1 is for some routers that had a bug in them, so someone is trying to exploit them. So, basically an automated machine is trying to see if our Matrix server has the issue.

My worry is that our errors talk about eval():

6 => array (
"file" => "[SYSTEM_ROOT]/core/include/mysource.inc(253) : eval()\'d code",
"line" => 1,
"function" => "init",
"class" => "Session_Handler_Default",
"type" => "::",
"args" => array (
[Empty]
) 
),
7 => array (
"file" => "[SYSTEM_ROOT]/core/include/mysource.inc",
"line" => 253,
"function" => "eval"

Edison_Wang · 2014-02-23 23:20:39 UTC

@tbaartar

I agree with what Nic said. This error suggests there is invalid web requests coming to your Matrix instance which might be sent from some automated machine.

Those web requests don't have a host name, so it's invalid and bad.

I will suggest you check your Apache log to identify those requests and investigate further.

@Nic

The eval call has already been removed in 4.18.x Matrix.

However, on production instance, you should always turn off "error display to frontend user" so no one can figure out how Matrix works in error message.

SQ_CONF_ERRORS_HIDE_FRONTEND => true.

nnhubbard · 2014-02-23 23:25:24 UTC

@Nic

The eval call has already been removed in 4.18.x Matrix.

However, on production instance, you should always turn off "error display to frontend user" so no one can figure out how Matrix works in error message.
SQ_CONF_ERRORS_HIDE_FRONTEND => true.

Thanks. Yeah, I always have that option set to true.

tbaatar · 2014-02-24 09:25:23 UTC

@tbaartar

I agree with what Nic said. This error suggests there is invalid web requests coming to your Matrix instance which might be sent from some automated machine.

Those web requests don't have a host name, so it's invalid and bad.

I will suggest you check your Apache log to identify those requests and investigate further.

@Nic

The eval call has already been removed in 4.18.x Matrix.

However, on production instance, you should always turn off "error display to frontend user" so no one can figure out how Matrix works in error message.
SQ_CONF_ERRORS_HIDE_FRONTEND => true.

Thanks for the feedback Edison.

Is there any reason why we would get this message exactly the same date/time? it seems bit strange for a bot to crawl only Matrix sites? If it did, does this mean all Squiz CMS users got the same error message last week Friday?

Can you change SQ_CONF_ERRORS_HIDE_FRONTEND from Matrix or is this through SSH?

Thanks.

nnhubbard · 2014-02-24 16:38:27 UTC

Thanks for the feedback Edison.

Is there any reason why we would get this message exactly the same date/time? it seems bit strange for a bot to crawl only Matrix sites? If it did, does this mean all Squiz CMS users got the same error message last week Friday?

Can you change SQ_CONF_ERRORS_HIDE_FRONTEND from Matrix or is this through SSH?

Yes, SQ_CONF_ERRORS_HIDE_FRONTEND is just the general "Hide Errors on Frontend" system config option in Matrix, it should be set.

I am thinking that they bots just looked for servers with __data directories. You can easily do a Google search for this and find all the servers that use Matrix.

nnhubbard · 2014-02-24 16:45:51 UTC

@tbaartar

I agree with what Nic said. This error suggests there is invalid web requests coming to your Matrix instance which might be sent from some automated machine.

Those web requests don't have a host name, so it's invalid and bad.

I will suggest you check your Apache log to identify those requests and investigate further.

@Nic

The eval call has already been removed in 4.18.x Matrix.

However, on production instance, you should always turn off "error display to frontend user" so no one can figure out how Matrix works in error message.
SQ_CONF_ERRORS_HIDE_FRONTEND => true.

But what causes an error like this? How does someone try to access a host that our server does not have? Can you explain how this error would be triggered?

mfong · 2014-02-25 10:03:31 UTC

But what causes an error like this? How does someone try to access a host that our server does not have? Can you explain how this error would be triggered?

All you have to do is connect to the Matrix webserver and send an HTTP request which contains a deliberately empty “Host” header:

date

Tue Feb 25 21:02:05 EST 2014

echo -e “GET / HTTP/1.1\nHost:\n\n” | nc localhost 80 > /dev/null

grep SYS0107 /var/www/matrix/data/private/logs/error.log

[2014-02-25 21:02:08][0:MySource System][256:mysource error][R] (/core/include/locale_manager.inc:547) - Unable to determine host for current URL [SYS0107]

tbaatar · 2014-02-25 10:56:22 UTC

Is there a way to prevent this from happening?

nnhubbard · 2014-02-25 16:19:48 UTC

  All you have to do is connect to the Matrix webserver and send an HTTP request which contains a deliberately empty "Host" header:

# date
Tue Feb 25 21:02:05 EST 2014
# echo -e "GET / HTTP/1.1\nHost:\n\n" | nc localhost 80 > /dev/null
# grep SYS0107 /var/www/matrix/data/private/logs/error.log
[2014-02-25 21:02:08][0:MySource System][256:mysource error][R] (/core/include/locale_manager.inc:547) - Unable to determine host for current URL [SYS0107]

So, they are just sending an HTTP request to our Matrix server with no Host header?

mfong · 2014-02-26 02:18:53 UTC

Is there a way to prevent this from happening?

The only way I could see would be to block or filter the offending HTTP request before it reached Matrix.

I suppose you could try using a RewriteCond matching Apache's HTTP_HOST header and the "F" (forbidden) RewriteRule flag to deny access, but that sort of thing strikes me as a half-measure at best. If you're really serious about filtering from a security standpoint then I think you'd probably want to look into more specialised options, which would be well out of this discussion's scope.

So, they are just sending an HTTP request to our Matrix server with no Host header?

I'd suspect so, although I can't be sure exactly what the requests arriving at your server look like. You could try using Apache's "%V" logging option in a custom log format to log what the client sent in its Host header, assuming you haven't enabled UseCanonicalName (it's off by default).

To be completely certain what the client sent, you'd probably need to do some network packet captures with tcpdump or similar (be careful if you try, though, since if you don't filter tcpdump you could easily end up with a very large capture file on a busy server).

Also, sending a request with no Host header actually doesn't result in a SYS0107, as Apache will reject the request with 400 Bad Request and not even pass it on to Matrix. It's sending a blank Host header that does it (although it may be possible to send a Host header with nonblank contents that Matrix will also reject as invalid; I haven't done any testing of that).

tbaatar · 2014-02-26 10:28:07 UTC

Thanks for the feedback Marcus.

Out of interest why it is only affecting 3-4 server+cms and not all our services? Is Squiz having the same issue? also I'm surprised there hasn't been much mention/talk about this issue on here by other members.

mfong · 2014-02-26 20:56:36 UTC

I really couldn't say why only some of your servers are logging those errors; whoever's out there scanning the Internet at large would be making their own decisions about what to target.

It's worth noting that Matrix systems behind a reverse proxy (e.g. Squid) probably won't see this error, as proxies generally seem to convert the invalid HTTP/1.1 request into a HTTP/1.0 request which won't generate the SYS0107.

It also looks like there's been a worm affecting Linksys routers spreading itself this month, which might explain the /HNAP1 requests which caused Nic's SYS0107 errors:

https://isc.sans.edu/diary/Linksys+Worm+TheMoon+Captured/17630

nnhubbard · 2014-02-26 22:01:51 UTC

It's worth noting that Matrix systems behind a reverse proxy (e.g. Squid) probably won't see this error, as proxies generally seem to convert the invalid HTTP/1.1 request into a HTTP/1.0 request which won't generate the SYS0107.

We have a server behind Squid that is also seeing this issue. :(

mfong · 2014-02-26 23:26:59 UTC

We have a server behind Squid that is also seeing this issue. :(

That's interesting; perhaps there's something different about those particular invalid requests. Are they also for "HNAP1" URLs?

nnhubbard · 2014-02-26 23:35:18 UTC

That's interesting; perhaps there's something different about those particular invalid requests. Are they also for "HNAP1" URLs?

Hmm, after I said that, I checked and apparently our IT Department has removed Squid. :(