'Daily/Prog'에 해당하는 글 116건

Received-SPF: none

Daily/Prog 2021. 12. 28. 21:24

장애


메일 이상 작동 접수,

 

  • Google Workspace Email 에서 @example.com 끼리는 메일이 주고 받아짐.
  • 다른 도메인에서 @example.com 으로의 메일도 잘 받아짐.
  • @example.com 에서 다른 도메인으로 메일을 발송하면 누구는 받아지고, 누구는 안받아지고, 누구는 스팸함에... 복불복임.ㅋ

 

테스트로 받아진 메일 원문을 보니, 첫줄부터 힌트를...

 

Received-SPF: none (kakao.com: domain of gabriel@example.com does not designate permitted sender hosts)

 

SPF: none - 발신 도메인이 SPF(Sender Policy Framework) 레코드를 설치하지 않았거나 제공된 발신자 정보에서 해당 도메인 정보를 구할 수 없음. SPF 확인 장치가 메일의 위조여부를 판정할 수 없음.

 

결국 DNS 서버에 SPF 세팅이 잘못됐을 것이라 추측하고 설정 확인.

 

SPF "v=spf1 include:_spf.google.com ~all"

 

구글에서 하라는 대로 잘되어 있는 것 같아서, 도메인이나 ip 를 추가해 줘야하나... 했는데,

 

https://aws.amazon.com/ko/premiumsupport/knowledge-center/route53-spf-record/

 

Route 53의 SPF 레코드 문제 해결

Internet Explorer에 대한 AWS 지원이 07/31/2022에 종료됩니다. 지원되는 브라우저는 Chrome, Firefox, Edge 및 Safari입니다. 자세히 알아보기

aws.amazon.com

 

* 요점
대부분의 메일 공급자에서는 SPF 레코드가 2014년 4월에 더 이상 사용되지 않으므로 SPF 구성이 적용되지 않습니다. 자세한 내용은 Internet Engineering Task Force(IETF) 웹 사이트에서 RFC 7208을 참조하십시오. SPF 레코드 대신 적용 가능한 값이 포함된 TXT 레코드를 만드는 것이 좋습니다.

 

 

해결


 

TXT "v=spf1 include:_spf.google.com ~all"

 

레코드 유형을 TXT 로 추가하여 해결...

 

Received-SPF: pass (kakao.com: domain of gabriel@example.com designates 123.123.123.123 as permitted sender)

 

하는 김에 DMARC 설정 추가하고, DKIM 은 관리자 권한 있으면 추가, 그리고 테스트 ㄱㄱ

 

 

Check MX: MX 및 SPF 레코드 확인

 

toolbox.googleapps.com

 

checkmx

 

 

또 하나,,, 테스트 한답시고 test1, test2, test3 이 따위로 메일 반복해서 보내면,

 

Delivery failed: gabriel@kakao.com
10.61.236.127 failed after I sent the message.
Remote host said[Response Message]: 554 5.7.1 DAS41 209.85.210.193: Your mail is blocked automatically by anti-spam system. (E04)
STEP: DATA SEND

 

이렇게 반송 메일 수신 가능...ㅋㅋ

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Exclude log4j2

Daily/Prog 2021. 12. 17. 20:59

log4j

 

ECR 에서 log4j2 사용중인 이미지들 깜빡하고 있었는데 AWS 에서 친절히 메일이 왔다.

 

You are receiving this communication because your account has container images stored in Amazon Elastic Container Registry (ECR). While not all container images are impacted by this CVE, your images may be affected if they are using Java with Apache Log4j in certain configurations. Amazon Inspector scans container images stored in Amazon ECR for software vulnerabilities to generate Package Vulnerability findings and is able to detect this issue in container images. You can turn on enhanced scanning from ECR [2] or enable Inspector from Inspector console to discover this issue in your images[3].

 

계정에 Amazon Elastic Container Registry(ECR)에 저장된 컨테이너 이미지가 있기 때문에 이 통신을 수신하게 되었습니다. 모든 컨테이너 이미지가 이 CVE의 영향을 받는 것은 아니지만 특정 구성에서 Apache Log4j와 함께 Java를 사용하는 경우 이미지가 영향을 받을 수 있습니다. Amazon Inspector는 Amazon ECR에 저장된 컨테이너 이미지에서 소프트웨어 취약성을 스캔하여 패키지 취약성 결과를 생성하고 컨테이너 이미지에서 이 문제를 감지할 수 있습니다. ECR[2]에서 향상된 스캔을 켜거나 Inspector 콘솔에서 Inspector를 활성화하여 이미지에서 이 문제를 발견할 수 있습니다[3].

 

log4j2 취약점이 추가로 계속 발생하고 있다. 2.15 에서 2.16 버전으로 업데이트...

확인하기도 귀찮다. 자꾸 신경쓰이게 하지 말고, logback 쓰고 log4j2 는 그냥 꼬죠.

 

// build.gradle
configurations {
    implementation.exclude group: "org.apache.logging.log4j"
}

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

finalizers

Daily/Prog 2021. 12. 12. 03:17

EKS 에서 ingress 와 loadbalancer 를 생성했는데 pending 상태라 살펴보니 자격증명 실패 에러가 발생했다.

 

$ kubectl describe ingress my-ingress
Warning FailedBuildModel  32m (x9 over 47m)  ingress  (combined from similar events): Failed build model due to WebIdentityErr: failed to retrieve credentials
caused by: InvalidIdentityToken: Incorrect token audience
status code: 400, request id: 4599a6da-7a29-4d82-baf7-d546e7811234

 

확인하고 삭제하려는데 삭제가 안된다.ㅋ 강제 삭제(--force --grace-period=0)도 안된다; 시간이 한참 지나도 프롬프트가 멈춰버림.

 

$ kubectl describe svc my-nlb
...
Normal   DeletedLoadBalancer  40m  service-controller  Deleted load balancer
Warning  FailedDeployModel    38m  service             Failed deploy model due to WebIdentityErr: failed to retrieve credentials
Warning  ClusterIPNotAllocated  75s (x5 over 37m)  ipallocator-repair-controller    Cluster IP [IPv4]:172.20.23.140 is not allocated; repairing
Warning  PortNotAllocated       75s (x5 over 37m)  portallocator-repair-controller  Port 32083 is not allocated; repairing

 

권한은 없는데 복구 의지가 강해서 그런건지, 안죽고 계속 살아나려고 발버둥 치는 느낌. 다른 서비스들과 결합이 되어 있는건지... 클러스터를 거의 초기화 수준으로 다른 모든 리소스를 다 지웠는데도 삭제가 안되는 생명줄 긴 로드 밸런서들. 구글님 덕에 겨우 찾아 삭제했다.

 

$ kubectl patch service/<your_service> --type json --patch='[ { "op": "remove", "path": "/metadata/finalizers" } ]'
$ kubectl patch ingress <your_ingress> -n <your_ns> -p '{"metadata":{"finalizers":[]}}' --type=merge

 

finalizers 는 리소스를 완전히 삭제하기 전에 특정 조건이 충족될 때까지 대기하게 한다. 삭제가 완료되면 대상에서 관련 finalizers 를 삭제하는데, 위처럼 metadata.finalizers 필드를 비워주면 Kubernetes 는 삭제가 완료된 것으로 인식하게 된다.

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

EKS Fargate limit

Daily/Prog 2021. 12. 7. 21:23

3년만인가. 드디어 ECS 에서 EKS 로 넘어왔다. 그 때도 ECS 보다는 조금 더 핫했던 쿠버네티스를 써보고 싶었지만 아마 아시아 리전에는 없었던 것으로 기억한다. 그리하여 이래저래 문서들 보고 헤딩하며 클러스터를 만들었는데 무언가 deployment 가 이상 작동을 하는 듯 했다. 안그래도 헤딩 중인데 되는 것 같기도 하고 안되는거 같기도 하고, 한참 삽질 끝에 Fargate 노드가 2개 까지만 만들어지는 현상을 발견했다. 이벤트 로그 메시지:

 

"Your AWS account has reached the limit on the number of Fargate pods it can run concurrently"
당신의 AWS 계정이 동시에 실행할 수 있는 Fargate 포드 수 제한에 도달했습니다.

 

 

내 계정은 이제 막 새로 판지 얼마 안된 새삥인데, 계정에도 뭔 종류가 있나. 뭔 업그레이드를 해야 하나 싶었다. 일단 구글에서는 저 메시지로 검색된 결과가 거의 없었다. 그나마 증상이 유사한 글에서, 몇몇 제한이 있는 리전이 있어서 리전을 바꾸던지 EC2 를 써야 한다는 글을 보았다. 우선 리전에서 fargate 할당량 체크를 했다.

 

[Service Quotas] - [Fargate On-Demand resource count]
사용률 4% / 적용된 할당량 값 50 / AWS 기본 할당량 값 1,000

 

 

개널널. 아직 48개 더 만들 수 있는데 나한테 왜그러는지... 혹시나 해서 도쿄 리전에도 만들어 봤으니 똑같은 메시지. 어쩔 수 없이 [지원센터] 찬스를 이용했다. 간결하게 물었다.

 

Q. eks 를 사용중이다. Fargate Pod 수가 2가 되면 더 이상 Pod 를 추가할 수 없다.

 

그랬더니 답변이 정말 개허접스럽게 왔다.

 

A. Fargate 동시 작업 제한 문제가 발생하지 않도록 EC2 인스턴스를 시작하시겠습니까?

 

 

ㅋㅋㅋ Basic 이라고 답변을 이딴 식으로 하면 돼, 안돼? Fargate 써볼라고 하는 사람한테 할 소리? 장사 안하겠다는건데 진짜 수준 개실망. Basic 은 기술문의도 막혀있네. 우와~ 처음 알았음. 답변도 거의 반나절 걸리고 내가 진짜 웬만하면 저기 글 안올리는데 이거 너무 이상해서 올렸더니만 역시나네. 사실 내 질문은 저기서 끝나지 않았음. '이것도 안된다. 저것도 안된다.' 그랬더니 그 때부터는 모든 질문을 기술팀에 넘겼다며 답변이 오는대로 바로 전달하겠다는 말을 남겼고, 난 며칠동안 답변이 오기전 그 모든 현상들을 해결했다.

 

사실 위 문제의 해결은 그들이 할당량을 100 으로 늘리자마자 해결됐다. 이걸로 해결된게 더 어이가 없다. 이 할당량은 리전에서 생성할 수 있는 Farget 의 최대치인데 기존에도 널널했는데 이제서 됐다는게 이상하다. 위에 나타난 에러는 내 AWS 계정의 제한을 얘기했다. 그들이 내 계정의 제한을 풀어준 것이라면 이해가 가겠지만... 또, 신규 계정의 fargate 제한이 2라면 그것도 말이 안된다. 이에 대해 구체적으로도 문의를 했지만, 과다 청구를 막기 위한 제한이니 안될 경우  할당량 증가 요청을 하라는 ㄱ소리... 불이익을 받지 않기 위해 별 다섯개를 투척하긴 했다만... 

 

내 결론은 Fargate 적용된 할당량 기본값은 2임. 화면에 보여진 50은 아마도 버그일 것임. 아니면 x < 50 ? 50 이던가. 그래서 할당량 값을 새로 업데이트만 시켜줘도 50 이상의 값이 설정되는 것임. 아마 나 역시 51로만 업데이트 했어도 됐을 것임. 이것이 바로 내 소설이다. 만약 이런 문제가 발생하면 바로 할당량 요청 ㄱㄱ

 

 

service-quotas

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret

Spring Boot 프로젝트의 jar 배포 테스트를 위해 구동 테스트를 했다.

  1. bootRun (O)
  2. cmd - bootJar 실행 (X)
  3. docker - bootJar 실행 (O)

 

bootRun 을 통과하고 bootJar 를 만들어 cmd 에서 실행을 했는데 db connection 타이밍에 에러가 발생했다.

 

> java -jar example-0.0.1-SNAPSHOT.jar
...
com.zaxxer.hikari.HikariDataSource       : HikariPool-1 - Starting...
com.zaxxer.hikari.pool.HikariPool        : HikariPool-1 - Exception during pool initialization.

java.sql.SQLNonTransientConnectionException: Could not create connection to database server. Attempted reconnect 3 times. Giving up.
Caused by: com.mysql.cj.exceptions.CJCommunicationsException: Communications link failure.
...
The last packet sent successfully to the server was 0 milliseconds ago. The driver has not received any packets from the server.
Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

 

mysql-ssl

 

ㅋㅋ 아니 뭐 요점만 간단히 알려주든가, '왜' 에러 났는지를 알려줘야지 거참...

 

bootRun 은 되는데, jar 실행에서 db 연결이 안된다? ... ㅡㅡ;; 우선 구글을 겁나 뒤졌다. 하... 그 많은 게시물들 중 DB 연결해 놓고 jar 실행한 사람이 하나 없냐... 다들 톰캣 띄운 Hello World... 나도 헬로월드 좋아하긴 하지만... 개발군 헬창들... 저 에러메시지는 너무 광범위하고, 내 상황을 검색어로 표현하기는 더 어려웠다. 구글 검색 페이지를 넘기다넘기다 중국말까지 나오기 시작했다. 아니... 이 아이러니한 상황이 납득이가 안갔다. 이렇게 시간을 낭비할 수는 없어 docker 를 일단 돌려봤다. 엥... 도커는 또 잘됨; 최종 목적이 도커라 로컬은 그냥 넘겨도 되지만 또또... 오늘한 삽질이 아까워 그 끝을 보기로 했다.

 

spring-boot-starter-web
spring-boot-starter-data-jdbc
mysql-connector-java:8.0.25

 

우선 톰캣만 띄웠더니 문제없다. 바로 dataSource 연결했더니 똑같은 오류...! 아니 원래 로컬에서 DB 연결이 안됐었나; 더 해볼게 없었지만 마지막으로, 혹시나 하는 마음에 connector 버전을 바꿔보았다.

 

mysql-connector-java:5.1.49

 

당연히 같은 자리에서 오류가 발생하기는 했는데, 해결책이 나왔다!

 

Establishing SSL connection without server's identity verification is not recommended. According to MySQL 5.5.45+, 5.6.26+ and 5.7.6+ requirements SSL connection must be established by default if explicit option isn't set. For compliance with existing applications not using SSL the verifyServerCertificate property is set to 'false'. You need either to explicitly disable SSL by setting useSSL=false, or set useSSL=true and provide truststore for server certificate verification.

 

Mysql 5.5.45+, 5.6.26+, 5.7.6+ 부터는 ssl 접속이 default 라서, useSSL=false 를 명시하지 않으면 자동으로 ssl 접속을 시도한다는 것이다.

 

jdbc:mysql://example.ap-northeast-2.rds.amazonaws.com:3306/example?...&useSSL=false

 

설마 이거 때문일 줄은 몰랐다. 이렇게 해결되니, 그래도 편히 눈을 감을 수 있게 됐다. 친절한 mysql connector 구버전에게 감사를 표한다.하지만 여전히 황당하기는 하다. ssl 이유라면 bootRun 으로도 되지 말았어야지. 도커에서도 되지 말았어야지...ㅜ

 

지금 보니 처음 발생했던 에러의 저 마지막 줄이 힌트긴 했네...

 

Caused by: javax.net.ssl.SSLHandshakeException: No appropriate protocol (protocol is disabled or cipher suites are inappropriate)

 

 


WRITTEN BY
손가락귀신
정신 못차리면, 벌 받는다.

트랙백  0 , 댓글  0개가 달렸습니다.
secret