Używając YUM zainstalowałem apache. Zainstalowana wersja Apache to 2.2.3
Nasz ochroniarz chce, abyśmy używali apache 2.2.21
Kiedy próbuję yum aktualizacji „httpd” nic się nie dzieje - Brak pakietów oznaczonych do aktualizacji
Sprawdziłem stronę główną Apache ( http://www.apache.org/dist/httpd/patches/ ) pod kątem łatek. Na podstawie pisemnej instrukcji próbuję zainstalować łatkę 2.2.4 ( http://www.apache.org/dist/httpd/patches/apply_to_2.2.4/ )
patch -s < /usr/local/src/hack-msvc8-httpd-2.2.4.patch
I dostałem taką wiadomość:
The text leading up to this was:
|###
|### A trivial hack to copy the .manifest files along with the binaries
|### when building from the command line on Visual Studio 2005
|###
|### Courtesy of Gustavo Lopes
|### Posted to [email protected],
|### Message-ID: <006901c731ae$97bec180$0201a8c0@cataphract>
|###
|--- Makefile.win.orig 2006-12-07 11:09:37.000000000 -0600
|+++ Makefile.win 2007-01-08 23:55:56.000000000 -0600
File to patch:
Co robię źle? Dlaczego nie mogę zaktualizować Apatche do wersji 2.2.21?
apache-2.2
yum
użytkownik1124133
źródło
źródło
Odpowiedzi:
Aby uruchomić 2.2.x, musisz albo zdobyć inne RPM - albo zbudować je ze źródła.
Podejrzewam jednak, że ponieważ korzystasz z wersji 2.2.3, korzystasz z RedHat Enterprise Linux 5 lub jednego z jego pochodnych (CentOS 5 itp.). Przekonasz się, że znaczna liczba firm testujących penetrację lub funkcjonariuszy ds. Bezpieczeństwa nie bierze pod uwagę tego, że podczas pracy z wersją 2.2.3 faktycznie otrzymałeś poprawki bezpieczeństwa z późniejszych wersji Apache.
Jest to znane jako „backporting”. RedHat ma tutaj dobry opis . Sugeruję, aby poprosić twoich ochroniarzy o konkretne CVE, które są zainteresowani, aby upewnić się, że są załatane, a następnie użyj tego narzędzia redhat, aby ustalić, czy są one naprawione w uruchomionej wersji apache. Numer wersji można uzyskać, przygotowując wstępnie
rpm -qa httpd
.źródło
Zakładam, że masz RHEL5 (lub odpowiednik).
Możesz powiedzieć facetowi od bezpieczeństwa, że Red Hat stosuje odpowiednie aktualizacje zabezpieczeń z wersji 2.2.21 do pakietu 2.2.3, ale nie zmienia podstawowego numeru wersji. Będzie to wyglądało (jeśli używasz tylko numeru wersji pakietu), że używasz starszej wersji Apache, ale w rzeczywistości jesteś tak bezpieczny, jak 2.2.21. Jest to rodzaj długowiecznej dystrybucji korporacyjnej: zyskujesz spójność, a także poprawki.
Możesz to sprawdzić, uruchamiając coś takiego:
Na przykład ostatnia poprawka pojawi się w dzienniku zmian:
Jeśli naprawdę potrzebujesz zainstalować 2.2.21, możesz go skompilować samodzielnie. Będzie to miało swoje złe konsekwencje dla bezpieczeństwa: jeśli ktoś znajdzie i naprawi nowy problem z Apache w przyszłym tygodniu, Red Hat przeportuje tę poprawkę i udostępni ją przez yum, ale twoja własna samodzielnie zbudowana Apache nie będzie miała tej poprawki, a ty Będę musiał ponownie przejść przez cały proces, aby zbudować i zainstalować nowy Apache.
źródło
[root@ww013886 src]# rpm -qa httpd httpd-2.2.3-53.el5.centos.3 [root@ww013886 src]# rpm -q --changelog httpd * Fri Oct 21 2011 Johnny Hughes <[email protected]> - 2.2.3-53.3.el5.centos - Roll in CentOS Branding * Fri Oct 07 2011 Joe Orton <[email protected]> - 2.2.3-53.3 - add security fix for CVE-2011-3368 (#743903) - fix regressions in byterange handling (#736593)
Aby zbudować niestandardowy Apache na Red Hat (lub CentOS) bezpośrednio z góry, wykonaj następujące czynności:
Lub zaoszczędź sobie pracy i pozwól Red Hat obsługiwać aktualizacje. Nie polecam tego robić, chyba że istnieje szczególna potrzeba kompilacji wcześniejszej, której nie może całkowicie zaspokoić kompilacja dostawcy
* Uwaga: W Red Hat 6 distcache nie jest już obsługiwany, więc musisz usunąć „--enable-distcache” z pliku .spec.
źródło
Łatka, którą próbujesz zastosować, służy do budowania za pomocą Microsoft Visual Studio. Wskazówka znajduje się w nagłówku łatki:
To tak naprawdę nie łata drzewa źródeł Apache do 2.2.4. Ale czy rzeczywiście próbowałeś zastosować to do SRPM?
Jak wspomina cjc, poprawki bezpieczeństwa Red Hat do dowolnej wersji, którą wysyłają, ale numer wersji niekoniecznie ulega awarii. I znowu, zawsze możesz sam skompilować Apache.
źródło