[항해99 취업 리부트 코스 학습일지] openresty 404

 

문제

내 tistory를 방문했을 때 openresty라는 문구와 함께 404에러가 발생함

시도

서비스 워커 삭제할 수 있는지 살펴보기 

로컬 스토리지 살펴보기

 

관련 자료 찾기

https://technoogies.com/404-not-found-openresty-wsidchk-imunify360-and-cloudflare-redirect-error/

 

When Imunify360 detects a malicious activity, it intercepts the request and sends an interstitial page with a 200 HTTP status code. That page has a JavaScript redirect that points to that path, which then gets a 404 as there’s no such page on your server. The problem is that with Edge Cache TTL, the no-store directive set by the Cache Control header on the interstitial page is overridden, and that page is cached. After that, every visitor will get redirected to the 404 for as long as that interstitial page is not purged from cache

 

Imunify360은 악의적인 활동을 감지하면 요청을 가로채고 200 HTTP 상태 코드가 포함된 삽입 페이지를 보냅니다. 해당 페이지에는 해당 경로를 가리키는 JavaScript 리디렉션이 있으며, 서버에 해당 페이지가 없으므로 404가 표시됩니다. 문제는 Edge Cache TTL을 사용하면 삽입 페이지의 캐시 제어 헤더에 의해 설정된 no-store 지시문이 재정의되고 해당 페이지가 캐시된다는 것입니다. 그 후에는 삽입 페이지가 캐시에서 삭제되지 않는 한 모든 방문자가 404로 리디렉션됩니다.

 

예상 가설

악의적인 요청을 감지하였을 때 200코드로 침입자에게 status를 은닉하고

javascript redirection을 404로 보냄으로서 사용자에게 페이지가 침해되었음을 알린다. 

사용자가 캐시를 비우는 것을 유도하여 Refresh Token(있다면) 등의 추가 유출을 막는다. 

> 정답 아님.

해결

항해 잡담방 홍박사님 : 토큰 만료의 문제일 수도 있으면 강력 새로고침 권장 - 해당 방법으로 해결

알게된 점

강준규 멘토님의 답변

 

cdn에 캐싱 : 미국까지 네트워크 요청이 갔다올 필요가 없음

자주 사용되는 페이지들을 네트워크 중간 경로에 캐싱

 

CDN캐시가 있는 서버와 원본 서버 사이 = Imunify360

 

디도스 등의 비정상적인 요청

이상한 redirect 페이지를 깔아 둠

 

방어 로직 중 하나임

 

원본 서버에 없음 / 클라우드 플레어 (캐싱 서버 ) 안 탐

원본 서버에 요청을 해서 원본 서버의 응답이 404

404를 캐싱 

> 리소스에 접근하지 않고 404만 무한 리턴

 

비정상적인 트래픽을 감지 > 방어로직 작동!

 

홍박사 님의 조사 결과 답변

원인: 웹 호스팅 서버의 Imunify360 방화벽과 Cloudflare의 캐시 설정 간 상호작용으로 인해 발생할 수 있습니다.
Imunify360이 악성 활동을 감지하고 중간 페이지를 제공할 때, 해당 페이지가 Cloudflare에 의해 캐시될 수 있습니다.
만약 이 페이지가 존재하지 않는 페이지로 리다이렉트되면,
사용자는 "404 Not Found" 오류에 직면하게 됩니다. 이러한 상황이 캐시되어 장기간 유지되면, 사용자는 오래된 오류 페이지를 계속 보게 될 수 있습니다.
Cloudflare의 "Cache Everything" 설정은 모든 컨텐츠를 정적으로 취급하여 기본 Cloudflare 캐시 규칙을 넘어 모든 파일 유형을 캐시합니다. 이는 웹 서버의 부하를 줄이고 페이지 로딩 속도를 높이는 데 도움이 됩니다.
이 설정은 원본 웹 서버에서 오는 캐시 헤더를 우선적으로 따릅니다.
"Edge Cache TTL" 설정은 페이지 규칙에 설정될 수 있으며, 이는 캐시된 데이터가 Cloudflare 엣지 서버에 얼마나 오래 유지될지를 결정합니다.
Edge Cache TTL이 설정되면 "Cache Everything"과 함께 사용될 때, 캐시 유지 기간 동안 원본 서버로부터의 쿠키를 제거하여 사용자의 프라이버시 보호와 성능 향상에 기여할 수 있습니다.


해결방법: 강력 새로고침을 통해 브라우저가 직접 서버에 최신 페이지 정보를 요청하도록 강제함으로써 캐시 문제를 우회합니다.


해결된 이유: 문제가 발생했던 이유는 웹 호스팅의 방화벽과 Cloudflare의 캐시 설정이 충돌하기 때문입니다.
방화벽이 악성 행위를 감지하면, 존재하지 않는 페이지로 리다이렉트되는데, 이 페이지가 Cloudflare에 의해 장기간 캐시됩니다.
강력 새로고침을 하면, 이 오래된 캐시 문제를 우회하여 문제가 해결됩니다.
강력 새로고침으로 최신 페이지 정보를 서버로부터 직접 요청하게 되어, 잘못된 리다이렉트와 캐시된 오류 페이지가 더 이상 보이지 않게 됩니다.

가설 : 
서버가 껏다켜지면서 서버의 메모리에 들어있던 정보들이 날아가서 그럴 수도 있고, 캐싱 기간이 변경되어서 그럴수도 있을 것 같아요

 

항해99 취업 리부트 코스를 수강하고 작성한 콘텐츠 입니다.

IT 커리어 성장 코스 항해99, 개발자 취업부터 현직자 코스까지