Java의 keytool.exe 있는 위치 찾아서 (일반적으로 Java/jdk/bin/keytool.exe) cmd> keytool -genkey -v -keystore yr.keystore -alias yr -keyalg RSA -keysize 2048 -validity 3650 개인 인증서 생성 후 Sign 진행 (암호는 입력해야 제대로 앱이 리패키징 됨)
+) "안드로이드 기기 버전 확인" cmd> adb shell getprop | find "cpu" 결과예시> [ro.product.cpu.abi]: [arm64-v8a] .... 여기서 확인해야할 것은 cpu.abi >> "arm64"를 기억하자
- 다운로드(xz 파일) 받은 후 압축해제
- 안드로이드 기기에 파일 넣어주기 cmd> adb push [압축해제파일명] /data/local/tmp cmd> adb shell $ su (root 계정으로 권한상승) # cd /data/local/tmp (넣은 파일 있는 곳으로 이동) # ls (넣은 파일 있는지 확인) # chmod 755 [압축해제파일명] (실행권한 부여) # ./frida-server-16.1.3-android-arm64 & (백그라운드&에서 frida-server 구동)
※ 만약, 'Unable to start : Error binding to address 127.0.0.1:27042: Address already in use' 에러가 떴다면, frida-server가 이미 돌아가고 있다는 뜻이기 때문에 프로세스 종료 후 다시 구동시켜줘야 한다
# ps -ef | grep frida (frida라는 텍스트 들어간 프로세스id 확인) # kill -9 [pid] (프로세스 강제 종료) # ./frida-server-16.1.3-android-arm64 & (백그라운드&에서 frida-server 다시 구동)
4. 설치된 APK의 [패키지명] 확인 cmd> frida-ps -Uai (결과에서 Identifier를 보면 된다) 결과예시 > PID Name Identifier ----- --------------- --------------------------------------- 23384 Gmail com.google.android.gm 15319 Google com.google.android.googlequicksearchbox 21709 Google Play 스토어 com.android.vending ...
티켓(ticket) 기반의 컴퓨터 네트워크 인증 프로토콜. 클라이언트 서버 모델을 목적으로 개발되었으며 사용자와 서버가 서로 식별할 수 있는 상호 인증(양방향 인증)을 제공한다.
보안이 보장되지 않은 네트워크 환경에서 요청을 보내는 유저와 요청을 받는 서버가 서로의 신뢰성을 확보하기위해 사용된다.
* 티켓(ticket) : 유저 아이디를 안전하게 전달하는 데 사용되는 정보 패킷으로, [유저 아이디, 유저 호스트의 IP 주소, 타임 스탬프(time stamp, 시간 기록), 티켓 수명을 정의하는 값, 세션 키] 등을 포함한다
□ 커버로스의 구성요소
- KDC(Key Distribution Center)
: 키 분배 서버(Kerberos에서 가장 중요한 시스템)
: 모든 사용자와 서비스들의 암호화키(비밀키, secret key)를 보유
: 신뢰할 수 있는 제3의 기관으로서 티켓을 생성, 인증서비스를 제공
: 클라이언트와 서비스는 KDC의 무결성을 신뢰하며, 이러한 신뢰는 커버로스 보안의 근간
: 사용자의 패스워드는 비밀키로 변환됨. 이 비밀키는 주체와 KDC 사이에서 "민감한 데이터를 전송"하기 위해 사용되며, "사용자 인증 목적"을 위해서도 사용됨
: TGS와 AS로 구성
- AS(Authentication Service)
: 실질적으로 인증을 수행
: 사용자에 대한 인증을 수행하는 KDC의 부분 서비스
- TGS(Ticket Granting Service)
: 티켓 부여 서비스
: 티켓을 부여하고 티켓을 분배하는 KDC의 부분 서비스
- SS(Service Server, Resource Server)
: 유저가 최종적으로 통신하고자 하는 목적지 서버
- Ticket
: 사용자에 대해 신원과 인증을 확인하는 토큰
: 사용자가 다른 주체들과 통신이 필요할 때마다 패스워드를 입력하지 않도록 도와 줌
- Principals
: 인증을 위하여 커버로스 프로토콜을 사용하는 모든 실체
□ 커버로스의 동작절차
이미지 출처 https://kim-dragon.tistory.com/187
1,2(Request TGT) : 사용자는 워크스테이션에 로그인하고 호스트의 서비스를 요청한다
3(TGT+Session Key) : AS는 사용자가 DB에 접근권한이 있는지 확인한다. 그리고 TGT(Ticket Granting Ticket, 티켓을 받기 위한 티켓) 와 세션키를 생성한다. 그 결과물을 사용자의 패스워드로부터 유도한 키를 사용하여 암호화한다.
4(Request Ticket + Auth) : 워크스테이션은 사용자에게 프롬프트를 통해 패스워드를 묻고, 그것으로 수신되는 메시지를 복호화한 다음(유저는 당연히 자신의 패스워드를 알고 있으므로, AS로부터 받은 정보를 복호화하여 TGS 세션 키를 얻을 수 있다.) 사용자 이름, 네트워크 주소, TGS의 시간이 기록된 티켓과 인증자를 보낸다.
5(Ticket + Session Key) : TGS는 티켓과 인증자를 복호화하고, 요청을 확인하고 요청된 서버에 사용할 티켓을 생성한다. 6(Request Service + Auth) : 워크스테이션은 티켓과 인증자를 서버에 보낸다.
7(Server Authentication) : 서버는 티켓과 인증자가 일치되는지를 확인하고, 서비스에 대한 접근을 허락한다. 만약 쌍방 인증이 필요한 경우라면 서버는 인증자를 반환한다.
□ 특징
세션 키는 비밀 키와 다른 개념이다.
세션 키는 유저와 서비스 간의 통신에 필요한 키이다.
커버로스에서 유저는 TGS, SS와 통신을 하게 되므로, 두 개의 세션 키를 필요로 한다.
비밀 키는 서비스가 유저에게 만들어서 보내줄 티켓을암호화하거나, 서비스가 유저로부터 전달받은 티켓의복호화를 위해 가지고 있는 키이다.
티켓의 복호화를 위해 TGS는 TGS 비밀 키를 가지고 있고, SS는 SS 비밀 키를 가지고 있다.
티켓의 암호화를 위해 AS는 TGS 비밀 키를 가지고 있고, TGS는 SS 비밀 키를 가지고 있다.
또한 세션 키는티켓 안에 들어갈 데이터중 하나이기 때문에 AS는 TGS 세션 키를 가지고 있고, TGS는 SS 세션 키를 가지고 있다.
□ 커버로스의 장단점
장점
단점
- 데이터의 기밀성과 무결성 보장 - 재생공격 예방 - 개방된 이기종 간의 컴퓨터에서 자유로운 서비스 인증이 가능(SSO) - 대칭키를 사용하여 도청으로부터 보호
- 패스워드 사전공격에 약함 - 비밀키, 세션키가 임시로 단말기에 저장되어 침입자에 의해 탈취당할 수 있음 - TimeStamp로 인해 시간동기화 프로토콜이 필요 (요청 시간에 대한 요구가 엄격함(통상적으로 5분). 만약 요청을 주고받는 호스트들 간에 시간 동기화가 되어있지 않을 경우 통신이 불가능) - 비밀키 변경 필요 - KDC가 단일실패지점(SPoF, Single Point of Failure)이 될 수 있음 - KDC는 많은 수의 요청을 처리 가능해야 함(즉, 확장 가능성이 있어야 함) - TGS & AS는 물리적 공격 및 악성코드의 공격에 취약
- subnet과 NIC 둘 다에 NSG 설정 시, 두 수준 모두에 allow 규칙이 있어야 트래픽이 허용됨(subnet 및 NIC에 대해 독립적으로 평가됨)
Load Balancing
ASG(Application Security Groups)
- 가상 머신(웹 서버, 애플리케이션 서버)을 논리적으로 그룹화
- 트래픽 흐름을 제어하는 규칙 정의
- 보안을 강화하기 위해 ASG를 NSG로 포장
Service Endpoint
- VNet(가상 네트워크) Service Endpoint는 Azure 백본 네트워크에서 최적화된 경로를 통해 Azure 서비스에 대한 안전한 직접 연결을 제공한다.
- Service Endpoint를 사용하면 가상 네트워크에 대해 중요한 Azure 서비스 리소스를 보호할 수 있다.
- VNet에 public IP 주소가 없어도 private IP 주소를 통해Azure Service Endpoint에 연결할 수 있다.
service endpoint
실습) NSG, ASG 조직에는 두 개의 서버 그룹이 있다. 웹 서버 및 관리 서버. 각 서버 그룹은 자체 ASG에 있어야 한다. 관리 서버로 RDP를 전송할 수 있어야 하고, 웹 서버는 인터넷에서 액세스할 때 IIS 웹 페이지를 표시해야 한다. 또한 트래픽이 올바르게 라우팅되도록 하려면 NSG를 만들어야 한다.
실습 구성도NSG
가상 네트워크 myVirtualNetwork를 만들고, mySubnet이라는 서브넷을 만든 후
myNSG라는 네트워크 보안 그룹을 생성하여 이 서브넷에 연결시킨다.
Inbound 규칙 추가
myNSG에 Inbound 규칙을 추가한다.
myAsgWebServers ASG에는 80,443 포트로 들어오는 것을 허용하고 (웹)
myAsgMgmtServers ASG에는 3389 포트로 들어오는 것을 허용한다. (원격 접속)
myVmMgmt
myVmMgmt 로 원격 접속을 한 후, 여기서 myVmWeb에 원격 접속을 한다.
myVmMgmt는 원격 접속 포트를 허용해줬기 때문에 외부에서 들어올 수 있지만, myVmWeb은 허용하지 않았기 때문에 외부에서 곧바로 접속이 불가능하기 때문이다.
public IP를 확인한 후, 접속해본다. 80,443번 포트로 들어오는 것을 허용해놨기 때문에 접속에 성공할 수 있다.
Host Security(Server)
Endpoint Protection
- Endpoint System : 사용자와 직접 상호 작용하는 컴퓨터 시스템
- 엔드포인트를 보호하기 위해서 맬웨어 방지 솔루션 설치. Cloud와 통합하여 상태를 모니터링할 수도 있다.
Virtual Machine Templates - Resource Manager Templates를 사용하여 VM을 정의한다. 이를 사용하면 VM을 쉽게 배포 그리고 다시 배포할 수 있다. 새로 업데이트되어 보안이 강화된 OS를 강제로 배포하려는 경우 VM을 주기적으로 다시 배포하는 것이 좋은데, 템플릿을 사용하면 쉽게 배포가 가능하다.
Remote Access Management - Windows 기반 가상 시스템을 위한 RDP(원격 데스크톱 프로토콜) - Linux 기반 가상 시스템을 위한 SSH(Secure Shell Protocol) - SSL을 통한 포털을 통한 RDP/SSH의 기반 서브넷
Update Management - 전반적으로 업데이트 상태를 평가하고 on-premise 및 Azure 환경에 대해 Windows 서버 및 Linux 서버 업데이트를 관리할 수 있다.
Disk Encryption - 운영 체제 및 데이터 디스크를 암호화하여 제공할 수 있다. - Windows는 BitLocker, Linux는 DM-Crypt 이용 - Azure Key Vault와 통합되어 디스크 암호화 키 및 비밀을 제어 및 관리할 수 있다.
Container Security
ACI(Azure Container Instance) : 간단한 애플리케이션, 작업 자동화 및 빌드 작업 등 컨테이너에서 작동하는 시나리오용 PaaS 서비스 - 빠른 시작 시간(Azure에서 몇 초만에 컨테이너를 시작할 수 있음) / Public IP 와 DNS로 컨테이너 액세스 가능 / 애플리케이션이 VM에 있는 것처럼 컨테이너에서 격리되도록 보장
※ 1. 도커 호스트가 vm 인 경우 docker를 설치하고 로그인을 한 후에 image를 Azure Container Registry에 있는 걸 다운 ※ 2. 도커 호스트가 Azure Container Instance인 경우에 docker를 설치하지 않고 Azure Conatainer Registry 에 있는 걸 바로 다운받아 서비스 할 수 있음 (ACI가 좋은 이유는 Public IP가 컨테이너마다 부여되고, docker를 따로 안깔아도 된다는 점)
ACR(Azure Container Registry) : 컨테이너 이미지를 저장하고 배포하는 서비스 - Azure CLI 또는 표준 docker login 명령을 사용하여 레지스트리에 로그인 > Azure Container Registry는 HTTPS를 통해 컨테이너 이미지를 전송하고 TLS를 지원하여 클라이언트 연결을 보호 - RBAC(역할기반 액세스 컨트롤) 을 사용하여 사용자 또는 시스템에 세분화된 권한을 레지스트리에 할당할 수 있음
AKS(Azure Kubuernetes Service) 컨테이너 기반 애플리케이션 배포 및 관리를 간소화하는 서비스
실습) ACR과 AKS 구성하기 & 보안 활동 1. Dockerfile을 사용하여 이미지를 빌드 2. Azure Container Registry를 사용하여 이미지 저장 3. Azure Kubernetes 서비스를 구성 4. 내부 및 외부 모두에서 컨테이너 애플리케이션을 보호하고 액세스
az group list --query "[?name=='AZ500LAB09']" -o table
az acr create --resource-group AZ500LAB09 --name az500$RANDOM$RANDOM --sku Basic
az acr list --resource-group AZ500LAB09
Azure Cloudshell (bash)를 이용해
image를 저장할 Azure Container Regisrty를 생성한다.
Task 2: Create a Dockerfile, build a container and push it to Azure Container Registry
echo FROM nginx > Dockerfile
ACRNAME=$(az acr list --resource-group AZ500LAB09 --query '[].{Name:name}' --output tsv)
az acr build --image sample/nginx:v1 --registry $ACRNAME --file Dockerfile .
nginx 이미지를 담고있는 Dockerfile을 이용해 컨테이너를 생성하고, Task1에서 만들었던 ACR에 넣어준다.
Task 3: Create an Azure Kubernetes Service
Kubernetes Service를 하나 생성하고 배포된 것을 확인한다.
Task 4: Give AKS permission to access the ACR
이전에 생성한 Azure Container Registry 인스턴스를 사용하도록 AKS 클러스터를 구성한다.
Task 5: Deploy an external facing container from ACR to AKS
처음에 받아뒀던 파일을 cloudshell 업로드/다운로드 기능을 활용하여 업로드한다.yaml 파일 24번째 줄에서 내가 만든 ACR 이름으로 바꿔줘야 한다.
Task 6: Verify you can access the container externally
Task 7: Deploy an internal facing container from ACR to AKS
external yaml 파일과 똑같이 24번째 줄에서 수정을 하고
Task 8: Verify you can access the container internally
external pod에서 internal pod가 동작중인지 확인해본다.
실습 2) Azure Kubernetes Service 이용 이 때 image는 Azure Container Registry에 저장된 것을 사용
① Resouce Group 생성 ② ACR를 GUI로 생성하세요 ACR 서버 : yerimcr.azurecr.io ACR Username : yerimcr Password : Kv1=A1A60MDBp5kSRI7m6GLP/qu5JMaY
③ CentOS VM을 하나 생성하여 docker를 설치합니다. yum install epel-release -y yum update -y vi /etc/sysconfig/selinux --> selinux=disabled로 수정 reboot curl -sSL http://get.docker.com | bash systemctl start docker
④ nginx, jesuswithme/verify-pod를 다운로드하여 nginx는 내용을 수정하세요 docker pull nginx docker pull jesuswithme/verify-pod docker run -d --name testing -p 80:80 nginx docker exec -it testing /bin/bash /# find -name "index.html" >> index.html 수정하기 위해 위치를 찾고 /# echo "Hello" > ./usr/share/nginx/html/index.html /# exit (VM으로 만든 컨테이너는 http://VM의publicIP:컨테이너포트번호로 확인한다)
⑤ ACR에 맞는 tag를 넣어서 이미지를 생성합니다. docker tag 이미지 ACR서버/ACR에저장할이미지이름:태그명 docker commit 컨테이너ID ACR서버/ACR에저장할이미지이름:태그명 (docker images 하면 확인가능)
⑥ VM에서 ACR에 Image를 업로드합니다 docker login ACR서버 -u ACRusername docker push ACR서버/이미지이름:태그명 (이제 ACR에서 올라간 이미지 확인 가능!!)
⑦ ACI에서 Container를 실행합니다 생성 중간에 Azure Container Registry 선택 후 여기에 업로드 한 이미지로 생성 생긴 Container의 Public IP로 접속
⑧ AKS를 구성합니다.
⑨ AKS에서 Deployment와 Service를 생성하여 Pod에 접속하게 합니다. yaml파일을 이용하려면 VM에서 다운로드하여 사용하세요 (vm) curl -sSL http://down.cloudshell.kr/down/k8slab.sh | bash (vm) ls -l (vm) cd k8s (vm) cat 명령어로 deployment 대한 yaml 파일 확인하고 복사
AKS에서 deployment를 생성(복사한 yaml파일 활용)
(Cloudshell-Bash) az aks get-credentials -g yerimRG -n yrkube (Cloudshell-Bash) kubectl get deployment -o wide (Cloudshell-Bash) kubectl expose deployment app-deploy --port=80 --type=LoadBalancer (Cloudshell-Bash) kubectl get svc -o wide >>서비스 Public IP로 접속
