Re: [users@httpd] Perl prg RewriteMap always returns blank
On 08/10/16 10:54, spggw...@posteo.eu wrote: However, running from within Apache it always returns a blank value. Running the same IPs through the script manually does return values. Any ideas what could be going on here? First, I totally agree with Julian about evilness of using user's IP for selecting user's locale or (worse) geo-blocking. As for the technical part of the question, I'd start with: 1. Testing the script with exact privileges it receives from Apache. It can be prevented from working by file modes, chroot (or other jail), apparmor/selinux etc. 2. Injecting some logging statements into the script (or use wrapper) to see if it actually tries to return something to Apache or not. -- With Best Regards, Marat Khalili - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
[users@httpd] mod_status: extended + auto (machine-readable) output
Hi, I've an Apache server handling various virtual hosts and I'd like to monitor the distinct activities of all of them without having to parse multiple accesslog files. Most monitoring softwares consume the output of "mod_status?auto" which is made easy to parse but does not provide the detailed the information available in the HTML mod_status+ExtendedStatus output As a consequence they can't the monitor the detailed states of the children and the virtual-host they serve. If it were to be done, would you consider merging a patch of mod_status in order to provide a machine-readable detailed output? If yes, then would you have a specific guidelines/advises about the implementation? Eg: * support of an "?extended" parameter in order to keep as-is the default and widely used output of "?auto". But ap_run_status_hook() allow appending anyway? * Specific format to render the "Server Details" section (separators) * whether or not adding the "SSL session cache" section (ssl_ext_status_hook) and "Proxy LoadBalancer Status" (proxy_status_hook) too? The alternative to patching mod_status would be doing a custom/out-of-tree module using the ap_run_status_hook() in order to append to the output. But IHMO having auto+extended fits mod_status better. best regards Note: I don't know what use-cases the "NoTable" output format was intended to, given that its HTML is neither nice to render in a browser, neither is it nice to parse. Note: from a quick look at the code, "auto" is bound to a "short_report" variable implying that machine-readable format was projected to stay short to begin with. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] Perl prg RewriteMap always returns blank
Hi, Reference: > From: spggw...@posteo.eu > Reply-to: users@httpd.apache.org > Date: Sat, 8 Oct 2016 11:34:46 +0200 spggw...@posteo.eu wrote: > Hello Julian, > > Thanks for your recommendation. However, my problem is not about how > this mapping should be used or how to detect what language my page > should be displayed in. It's rather about the map not returning any > value when referenced in my Apache configuration. Understood, but mis-use of IP number to country code seems to be growing, so more code that could later get copied & mis-used worries. But if you comment code & feed back to perl script source, more callers can learn IP# to country name should Not over ride HTTP_ACCEPT_LANGUAGE. > > Regards, > > K. > > Am 08.10.2016 um 11:28 schrieb Julian H. Stacey: > > Hi, Reference: > >> From: spggw...@posteo.eu > >> Reply-to: users@httpd.apache.org > >> Date: Sat, 8 Oct 2016 09:54:01 +0200 > > spggw...@posteo.eu wrote: > >> Hello experts! > >> > >> I'm working with a Perl script that should do geoIP mapping (IP to > >> two-letter country code). > > Then please ensure a comment in your code, so callers dont mis-use it: > > "Do Not Assume every inhabitant of a country wants to read the > >language etc of the country the IP# suggests. Environment > >variable HTTP_ACCEPT_LANGUAGE should over ride this IP, to allow for > >eg British in Germany, Poles in London, Spanish in USA etc." Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. http://berklix.eu/brexit/#stolen_votes - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] Unknown accepted traffic to my site
Thanks Spork for the detailed reply you got from Berkeley, I got a similar one,
though not quite as detailed. I think the problem with Apache is that it is
simply an index.html sending a 200 “OK” and not actually replying to say yes I
am infected with whatever it is they are looking for. At the time when I first
noticed this I looked into various ways of getting Apache to send a 400 or 403
but it involved messy rewrite rules which I just hate.
Seeing that I am now seeing this same string in various different formats
coming in daily now from IP’s all over the globe I would say whatever infected
servers out there who have been already been implanted with this malicious
software are now perhaps being called into action, possibly a big DDOS attack
planned or something else of a more sinister nature. Seeing that Berkeley are
working with and reporting this to law enforcement makes me believe there is
something quite sinister behind all of this.
Anyways, certainly a very interesting one to keep an eye on. I am now also
seeing similarly formatted strings now coming in over the past few days as per
the example below which now also seem to be targetting SQL servers. Luckily
none of mine are open to the public and only run as localhost but I am a sure a
lot of people which port 3306 exposed are in for something being planned.
This example below came in as a User-Agent string this morning in my logs, so
not only are they sending crazy formatted strings via normal http / https
requests but also now forging user agent string with similar stuff.
"}__test|O:21:\x22JDatabaseDriverMysqli\x22:3:{s:2:\x22fc\x22;O:17:\x22JSimplepieFactory\x22:0:{}s:21:\x22\x5C0\x5C0\x5C0disconnectHandlers\x22;a:1:{i:0;a:2:{i:0;O:9:\x22SimplePie\x22:5:{s:8:\x22sanitize\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}s:8:\x22feed_url\x22;s:46:\x22eval($_REQUEST[1]);JFactory::getConfig();exit;\x22;s:19:\x22cache_name_function\x22;s:6:\x22assert\x22;s:5:\x22cache\x22;b:1;s:11:\x22cache_class\x22;O:20:\x22JDatabaseDriverMysql\x22:0:{}}i:1;s:4:\x22init\x22;}}s:13:\x22\x5C0\x5C0\x5C0connection\x22;b:1;}\xFD\xFD\xFD\xFD
“
I must say every morning there is always something interesting to be found in
one’s logs, sadly a great deal of people running servers out there don’t seem
to monitor their logs as frequently as they should if at all.
Kind Regards
Mitchell
https://mitchellkrog.com
From: Spork Schivago
Reply: users@httpd.apache.org
Date: 07 October 2016 at 8:10:58 AM
To: users@httpd.apache.org
Subject: Re: [users@httpd] Unknown accepted traffic to my site
Oh! Tawasol, I forgot. If you're not already doing so, you should have your
server scanned for vulnerabilities. There's free websites out there that can
do this, like https://scanmyserver.com/
I believe nmap can also help you scan your server, although I don't think it
was really designed for vulnerability scanning. There's free for personal use
programs, like Nessus. The free version of Nessus only works on the local
area network though. However, websites like https://scanmyserver.com use the
paid version of Nessus. So, you can have your server scanned with Nessus by
using something like scanmyserver.com.
If there's any exploits installed, the vulnerability scanner(s) should detect
them. Just make sure to whitelist the IP address in LFD and CSF before
proceeding and double check the logs to make sure that CSF / LFD doesn't block
the scanning website.
On Fri, Oct 7, 2016 at 1:53 AM, Spork Schivago wrote:
Tawasol,
You might want to look into more than just mod_security. For example, there's
modules out there for PHP, for instance, that will make PHP run as a certain
user. If someone manages to take advantage of some poorly written PHP code,
for example, they would only have limited user access and only be able to
access the files in the directory where the html files are being stored.
I have crontab entries setup to scan for rootkits and do a bunch of other
things.
Another program you might want to look into is ClamAV. It's freeware.
Mod_security I like the best though. It really does catch a lot of bad stuff.
It can be a bit confusing setting it up though. Best of luck.
On Fri, Oct 7, 2016 at 1:31 AM, Tawasol Go wrote:
I use CentOS 7.x also CSF/LFD installed.
Till now they did not get into the server.
I'll look into mod_security.
Thanks,
On Fri, Oct 7, 2016 at 1:01 AM, Anthony Biacco wrote:
On Thu, Oct 6, 2016 at 3:42 PM, Spork Schivago wrote:
Are you sure they haven't successfully found away in? There are some free
programs that I use to help prevent this stuff. ConfigServer Firewall / LFD
is a good one. Rkhunter and chkrootkit scan for rootkits. The big one that
helps the most, I feel, is Mod Security. That's the one that
Re: [users@httpd] Perl prg RewriteMap always returns blank
Hello Julian, Thanks for your recommendation. However, my problem is not about how this mapping should be used or how to detect what language my page should be displayed in. It's rather about the map not returning any value when referenced in my Apache configuration. Regards, K. Am 08.10.2016 um 11:28 schrieb Julian H. Stacey: > Hi, Reference: >> From:spggw...@posteo.eu >> Reply-to:users@httpd.apache.org >> Date:Sat, 8 Oct 2016 09:54:01 +0200 > spggw...@posteo.eu wrote: >> Hello experts! >> >> I'm working with a Perl script that should do geoIP mapping (IP to >> two-letter country code). > Then please ensure a comment in your code, so callers dont mis-use it: > "Do Not Assume every inhabitant of a country wants to read the >language etc of the country the IP# suggests. Environment >variable HTTP_ACCEPT_LANGUAGE should over ride this IP, to allow for >eg British in Germany, Poles in London, Spanish in USA etc." > > Cheers, > Julian > -- > Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich > Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, > quoted-printable. > http://berklix.eu/brexit/#stolen_votes > > - > To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org > For additional commands, e-mail: users-h...@httpd.apache.org > - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
Re: [users@httpd] Perl prg RewriteMap always returns blank
Hi, Reference: > From: spggw...@posteo.eu > Reply-to: users@httpd.apache.org > Date: Sat, 8 Oct 2016 09:54:01 +0200 spggw...@posteo.eu wrote: > Hello experts! > > I'm working with a Perl script that should do geoIP mapping (IP to > two-letter country code). Then please ensure a comment in your code, so callers dont mis-use it: "Do Not Assume every inhabitant of a country wants to read the language etc of the country the IP# suggests. Environment variable HTTP_ACCEPT_LANGUAGE should over ride this IP, to allow for eg British in Germany, Poles in London, Spanish in USA etc." Cheers, Julian -- Julian Stacey, BSD Linux Unix Sys Eng Consultant Munich Reply below, Prefix '> '. Plain text, No .doc, base64, HTML, quoted-printable. http://berklix.eu/brexit/#stolen_votes - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
[users@httpd] Perl prg RewriteMap always returns blank
Hello experts! I'm working with a Perl script that should do geoIP mapping (IP to two-letter country code). The script works perfectly on the command line, and follows the rules highlighted in https://httpd.apache.org/docs/current/rewrite/rewritemap.html#prg However, running from within Apache it always returns a blank value. Only one line appears in the Apache error log even at LogLevel trace8 [Sat Oct 08 09:38:52.677116 2016] [rewrite:trace5] [pid 23318] mod_rewrite.c(476): [client 85.205.37.101:46280] 85.205.37.101 - - [/sid#10092bc18][rid#100d28ca0/initial] map lookup OK: map=geoip key=85.205.37.101 -> val= Running the same IPs through the script manually does return values. ~ $ tail -f /var/log/apache/errors/error.log_20161008-09 | grep geoip [Sat Oct 08 09:38:52.677116 2016] [rewrite:trace5] [pid 23318] mod_rewrite.c(476): [client 85.205.37.101:46280] 85.205.37.101 - - [/sid#10092bc18][rid#100d28ca0/initial] map lookup OK: map=geoip key=85.205.37.101 -> val= [Sat Oct 08 09:38:54.290646 2016] [rewrite:trace5] [pid 23286] mod_rewrite.c(476): [client 85.205.37.91:38384] 85.205.37.91 - - [/sid#10092bc18][rid#100cfb880/initial] map lookup OK: map=geoip key=85.205.37.91 -> val= [Sat Oct 08 09:38:57.889790 2016] [rewrite:trace5] [pid 23282] mod_rewrite.c(476): [client 213.30.118.102:49939] 213.30.118.102 - - [/sid#10092bc18][rid#100d13940/initial] map lookup OK: map=geoip key=213.30.118.102 -> val= ^C ~ $ /opt/apps/apache/conf/geoip_check.pl 85.205.37.101 DE 85.205.37.91 DE 213.30.118.102 PT ^C ~ $ I'm running Apache 2.4.18 on Solaris/SPARC and Perl 5.16.0. Compile-time settings: $ /opt/apache/current/bin/httpd -V Server version: Apache/2.4.18-dev (Unix) Server built: Nov 20 2015 19:38:51 Server's Module Magic Number: 20120211:51 Server loaded: APR 1.5.2, APR-UTIL 1.5.4 Compiled using: APR 1.5.2, APR-UTIL 1.5.4 Architecture: 64-bit Server MPM: prefork threaded: no forked: yes (variable process count) Server compiled with -D APR_HAS_SENDFILE -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_PROC_PTHREAD_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D DYNAMIC_MODULE_LIMIT=256 -D HTTPD_ROOT="/opt/apache/apache-2.4.17-sparc-t64" -D SUEXEC_BIN="/opt/apache/apache-2.4.17-sparc-t64/bin/suexec" -D DEFAULT_PIDLOG="logs/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="conf/mime.types" -D SERVER_CONFIG_FILE="conf/httpd.conf" $ Any ideas what could be going on here? Thanks! - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
