Re: [users@httpd] Apache with OpenSSL 3 compiled for FIPS - SSLFIPS invalid
That was it. Thanks Yann! Josh From: Yann Ylavic Date: Friday, October 21, 2022 at 5:26 AM To: users@httpd.apache.org Subject: Re: [users@httpd] Apache with OpenSSL 3 compiled for FIPS - SSLFIPS invalid On Fri, Oct 21, 2022 at 2:07 AM Joshua Smith wrote: > > With that in mind, I’m confused why Apache still complains about not being > compiled for FIPS. What am I missing? Possibly this change (which was overlooked for httpd-2.4.54 release): https://github.com/apache/httpd/commit/8b800c1457aee40d871e07470c1a962bf3e25de3 Patching 2.4.54 with https://github.com/apache/httpd/commit/8b800c1457aee40d871e07470c1a962bf3e25de3.patch should work. Regards; Yann. - To unsubscribe, e-mail: users-unsubscr...@httpd.apache.org For additional commands, e-mail: users-h...@httpd.apache.org
[users@httpd] Apache with OpenSSL 3 compiled for FIPS - SSLFIPS invalid
I’m trying to build httpd 2.4.54 against OpenSSL 3.0.5 compiled for FIPS. I’ve followed the OpenSSL and httpd build docs, but when I turn on the SSLFIPS directive in my config, I still get an error message saying “SSLFIPS invalid, rebuild httpd and openssl compiled for FIPS”. A Google search turns up plenty of results for compiling older OpenSSL versions for FIPS, but nothing for OpenSSL 3 and the new FIPS module. I’ve put together a Docker container with my attempt at a FIPS build: https://github.com/SmithJosh/httpd-openssl3-fips/blob/main/Dockerfile A couple notes: 1. I ran “./Configure enable-fips” before building OpenSSL and added the following to /usr/local/ssl/openssl.cnf after building to enable FIPS mode ``` config_diagnostics = 1 openssl_conf = openssl_init .include /usr/local/ssl/fipsmodule.cnf [openssl_init] providers = provider_sect [provider_sect] fips = fips_sect base = base_sect [base_sect] activate = 1 ``` 2. Running “openssl md5 <<< ‘12345’” returns the following error which I believe indicates I’ve enabled FIPS mode correctly ``` # openssl md5 <<< "12345" Error setting digest 80327F263C7F:error:0308010C:digital envelope routines:inner_evp_generic_fetch:unsupported:crypto/evp/evp_fetch.c:349:Global default library context, Algorithm (MD5 : 102), Properties () 80327F263C7F:error:0386:digital envelope routines:evp_md_init_internal:initialization error:crypto/evp/digest.c:252: ``` With that in mind, I’m confused why Apache still complains about not being compiled for FIPS. What am I missing? Thanks, Josh
RE: [users@httpd] Deny ip address didn't work
WOW! I'm definitely a novice at this, but this is quite surprising ... In my access log, I have several IP's that are requesting the same login page thousands of times. See examples below. Also, none of the requests have a referer or browser in the log record. I'm thinking that the lack of browser indicates that a program is submitting the request, not a person at a browser. (Let alone the fact that there are 186k requests in 2 hours would indicate that as well ) So now my question is expanding ... Now I think my site is getting a significant amount of hacking attempts. But as I said I'm a novice ... Does this look like I'm being hacked? Should I add these IP addresses to iptables? I have installed fail2ban, but I just left it at the default configuration. Do I need to start working with that? Thanks, Josh Examples of login requests 37.59.11.6 - - [08/Apr/2015:20:29:03 +] POST /wp-login.php HTTP/1.0 200 11141 - - time span - 21 hrs count - 76700 173.246.41.63 - - [28/Apr/2015:13:36:38 +] POST /wp-login.php HTTP/1.0 200 11072 - - time span - 7 hrs count - 17955 74.204.189.179 - - [28/Apr/2015:21:06:30 +] POST /wp-login.php HTTP/1.0 200 11178 - - time span - 20 hours count - 125685 5.196.241.194 - - [01/May/2015:22:37:25 +] POST /wp-login.php HTTP/1.0 200 11324 - - time span - 2 hrs count - 186157 84.19.174.28 - - [01/May/2015:22:12:49 +] POST /wp-login.php HTTP/1.0 200 10995 - - time span - 8 hrs count - 107285 -Original Message- From: Eric Covener [mailto:cove...@gmail.com] Sent: Tuesday, May 05, 2015 5:15 To: users@httpd.apache.org Subject: Re: [users@httpd] Deny ip address didn't work On Mon, May 4, 2015 at 7:33 PM, Joshua Smith joshuasm...@scbwi.org wrote: In both cases, when i monitored my site with the 'server-status' module, the ip address was still there, with sometimes more than 30 requests, and all for the same page, which was /login.php. And it continued to be there for the next 30 minutes until it just dropped off, but i was doing nothing to stop it at that point. Both of your rules just change the response for this IP, they don't block it from sending requests. What does the access log say? -- Eric Covener cove...@gmail.com - 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
[users@httpd] Deny ip address didn't work
Hi,
I tried both of the following methods to block an ip address, but neither
worked. In .htaccess, I put:
Order Deny,Allow
Deny from 123.123.123.123
and
RewriteCond %{REMOTE_ADDR} ^123.123.123.123
RewriteRule .* /maintenance.html [R=503,L]
(I do have the mod_rewrite module installed)
In both cases, I put the rules at the top of the file so that it would be
the first rules executed.
After each one, i did an apachectl stop, then apachectl start.
In both cases, when i monitored my site with the 'server-status' module,
the ip address was still there, with sometimes more than 30 requests, and
all for the same page, which was /login.php. And it continued to be
there for the next 30 minutes until it just dropped off, but i was doing
nothing to stop it at that point.
This method of blocking has worked for me in the past.
Is it possible for someone (ie a hacker…) to bypass my blocking method(s)?
Or is there something more I need to do?
Thank you,
Josh
RE: [users@httpd] Deny ip address didn't work
Thanks for your replies.
I'm using apache version 2.2.15 - so I guess I don't have to worry about the
2.4 changes.
I'll have to research AllowOverride
Very interesting - seems obvious now that you say it, but I didn't realize
my efforts were just blocking the response, not the request.
I tried an iptables rule and that seems to have worked.
Re the rewrite engine - also interesting ... I do have the RewriteEngine On
statement, but it's below the RewriteCond statement. Does that make a
difference? IE, does it process sequentially, and so the rewritecond
statements are just ignored unless they come after rewriteengine on ?
Thanks,
Josh
-Original Message-
From: Richard [mailto:lists-apa...@listmail.innovate.net]
Sent: Monday, May 04, 2015 20:27
To: users@httpd.apache.org
Subject: Re: [users@httpd] Deny ip address didn't work
Also allow/deny (or the 2.4 equiv) directives only control whether the
server delivers the content, not whether the client can request an item from
the server. I.e., the indication of successful blocking will be the response
code changing from 200 to 403, but you'll still likely see hits. If you want
to block the client from hitting the server you'd probably need to use
firewall settings.
With your rewrite attempt, did you include a statement turning the rewrite
engine on?
Original Message
Date: Monday, May 04, 2015 09:36:50 PM -0400
From: Yehuda Katz yeh...@ymkatz.net
What version of Apache are you using?
Apache 2.4 changed the access control directives unless you
specifically enable the old style:
http://httpd.apache.org/docs/2.4/upgrading.html#access
Also, make sure you have the correct AllowOverride statements.
- Y
On Mon, May 4, 2015 at 7:33 PM, Joshua Smith joshuasm...@scbwi.org
wrote:
Hi,
I tried both of the following methods to block an ip address, but
neither worked. In .htaccess, I put:
Order Deny,Allow
Deny from 123.123.123.123
and
RewriteCond %{REMOTE_ADDR} ^123.123.123.123 RewriteRule .*
/maintenance.html [R=503,L]
(I do have the mod_rewrite module installed)
In both cases, I put the rules at the top of the file so that it
would be the first rules executed.
After each one, i did an apachectl stop, then apachectl start.
In both cases, when i monitored my site with the 'server-status'
module, the ip address was still there, with sometimes more than
30 requests, and all for the same page, which was /login.php.
And it continued to be there for the next 30 minutes until it just
dropped off, but i was doing nothing to stop it at that point.
This method of blocking has worked for me in the past.
Is it possible for someone (ie a hacker…) to bypass my blocking
method(s)? Or is there something more I need to do?
Thank you,
Josh
End Original Message
-
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
