diff options
| -rw-r--r-- | writeups/console.aws-ec2-binary-userdata/console.aws-ec2-binary-userdata.md | 61 | ||||
| -rw-r--r-- | writeups/console.aws-ec2-binary-userdata/network-capture.png | bin | 0 -> 25033 bytes | |||
| -rw-r--r-- | writeups/console.aws-ec2-binary-userdata/userdata-form.png | bin | 0 -> 38498 bytes | |||
| -rw-r--r-- | writeups/ec2-ipv6-prep/ec2-ipv6-prep.md | 100 | ||||
| -rw-r--r-- | writeups/ktcloud-review/ktcloud-review.kr.md | 85 |
5 files changed, 246 insertions, 0 deletions
diff --git a/writeups/console.aws-ec2-binary-userdata/console.aws-ec2-binary-userdata.md b/writeups/console.aws-ec2-binary-userdata/console.aws-ec2-binary-userdata.md new file mode 100644 index 0000000..db11233 --- /dev/null +++ b/writeups/console.aws-ec2-binary-userdata/console.aws-ec2-binary-userdata.md @@ -0,0 +1,61 @@ +# AWS Management Console cannot handle binary EC2 user data +If "Input is already base64-encoded" option is checked, the browser does not +handle the data as binary and try to convert the input from ISO-8859-1 to utf-8 +if it "thinks" it's text data. + +## Steps to reproduce +Generate the arbitrary binary. Any binary data should work as long as the JS's +algorithm determines it as text. + +```sh +echo -ne '\xab\xba\xba\xbe' | base64 +# q7q6vg== +``` + +Pick a stopped instance to play with. Put the base64 encoded text to the +textbox. + + + +Inspect the actual data uploaded. + +``` +aws --region=AA-BBBB-N ec2 describe-instance-attribute --instance-id i-NNNNNNNNNNNNNNNNN --attribute userData | jq -r '.UserData.Value' | base64 -d | hexdump -C +``` + +You'll see that the data is not what you put in. + +``` +00000000 c2 ab c2 ba c2 ba c2 ba |........| +00000008 +``` + +This is a bug in in the web client. It's confirmed by inspecting the actual +request sent to the API endpoint from the browser. + + + +## This can complicate things +According to [the user +guide](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-add-user-data.html), + +> User data is treated as opaque data: what you give is what you get back. It is +> up to the instance to interpret it. + +User data can be set to binary data using **awscli**. It has no problem handling +binary data and sending it to the API endpoint. The endpoints does not seem to +care about the data. IMDS even returns user data to the instance as +"application/octet-stream" So in essence, you can put anything in your user +data. The AWS Management Console is built upon the assumption that the user data +is always plain text. It always try to decode and show the data as plain text. + +> User data must be base64-encoded. The Amazon EC2 console can perform the +> base64-encoding for you or accept base64-encoded input. + +This is just because user data has to be put in the request JSON object. Again, +nothing at EC2 end should care about the contents of the user data because it's +an attack vector if anything does. + +This complicate things for users who wants to put binary data in user data using +Management Console. Using **awscli** to make launch template is not an easy task +for some people. diff --git a/writeups/console.aws-ec2-binary-userdata/network-capture.png b/writeups/console.aws-ec2-binary-userdata/network-capture.png Binary files differnew file mode 100644 index 0000000..890f627 --- /dev/null +++ b/writeups/console.aws-ec2-binary-userdata/network-capture.png diff --git a/writeups/console.aws-ec2-binary-userdata/userdata-form.png b/writeups/console.aws-ec2-binary-userdata/userdata-form.png Binary files differnew file mode 100644 index 0000000..e81b2ee --- /dev/null +++ b/writeups/console.aws-ec2-binary-userdata/userdata-form.png diff --git a/writeups/ec2-ipv6-prep/ec2-ipv6-prep.md b/writeups/ec2-ipv6-prep/ec2-ipv6-prep.md new file mode 100644 index 0000000..53f9ada --- /dev/null +++ b/writeups/ec2-ipv6-prep/ec2-ipv6-prep.md @@ -0,0 +1,100 @@ +# AWS EC2 IPv6 Preparedness +Here I ramble about making IPv6 only instances. AWS announced[^1] that they'll +charge all use of IPv4 address. So I ventured out to see how prepared they are. + +... Not so much. + +https://github.com/DuckbillGroup/aws-ipv6-gaps +https://awsipv6.neveragain.de/ + +AWS will start charging customers without providing necessary facilities to +transition. Some find this absurd. + +## Most importantly: IMDS +Without the IMDS, the cloud agent(`cloud-init`) won't be able to get all the +information needed to set up the instance. If you just change your existing +instances to IPv6 only they will simply stop working on the next boot. Because +no matter the set up, the IPv6 IMDS endpoint is not enabled by default. It's the +same if you launch instances in an IPv6 only subnet without the option enabled. +The option is called ... + +- "Metadata Transport" on the web Management Console [^2] +- "http-protocol-ipv6"[^3] and "HttpProtocolIpv6"[^4] in awscli and boto3 + respectively + +## Dual-stack subnet, dual-stack public IP addresses +This is what we know and love in an ideal world. The API endpoints are accessed +by whichever one available, no issues with the IMDS and reachability checker as +the IPv4 is available as it used to be. Everything hunky dory. + +## One subnet for each +The one-for-each approach could be the easiest drop-in solution. Make the VPC +and the IPv6 only subnets first. Launch instances into them, add network +interfaces for instances that need IPv4. + +But there's a bit of snag. EC2 has these things called "primary network +interface" and "primary IP address". The primary network interface thing makes +it less flexible for us users to set up instances when the IPv6 comes in to +play. + +- In this set up, IPv4 addresses on the second interface(eth1) won't appear as + "primary public ipv4 addresses". In other words, the "public-ipv4" meta data + is not available. You have to query deep into the instance details or rely on + external services to get it. The only way to get both "public-ipv4" and "ipv6" + is to have the primary network interface in a dual-stacked subnet +- The "primary network instance" is tied to the instance forever. There's no way + of detaching it from the instance. It means you can't simply change it back to + IPv4 without terminating the instance and launching it again +- Two network interfaces are needed for each instance. It gets more interesting + if you were setting security groups to network interfaces, not the instance + +The other way around(eth0 for IPv4 and eth1 for IPv6) works the same. The +problem here is deciding which one to base your instance on. + +## Dual-stacked subnet with no public IPv4 addresses +Having both dual-stack and IPv6 only instances in the same subnet is challenging +because you can't configure instances to have either IPv4 or IPv6 address when +they're in the dual-stack subnet. But in most cases, adding IPv6 CIDRs in the +existing subnets is the most hassle free way to transition to IPv6. The problem +is that you have to change network config if you wish to have no public IPv4 +address whilst having IPv4 CIDRs because you can't remove the primary IPv4 +address from the existing instances. + +If the network interface is dual-stacked with no public IPv4 address associated +with it, the instance will become unstable because the instance won't be able to +connect to IPv4 only hosts. If you disable IPv4 entirely the instance +reachability check will fail because the instance would not respond to the +hypervisor's ARP packets[^5]. + +In this case, set the OS so that it does not to add the IPv4 gateway from the +DHCP offer to the routing table. + +NetworkManager: + +```bash +nmcli c s +nmcli c m CONN_ID ipv4.ignore-auto-routes yes +``` + +netsh: + +```powershell +netsh interface ipv4 show addresses +netsh interface ipv4 set interface interface="NAME" ignoredefaultroutes=disabled +``` + +Be careful with the `netsh` command! The `ignoredefaultroutes` setting does not +appear in the GUI adapter settings. The only sign that will show is that both of +IPv4 and IPv6 connectivity will be "No network access" whilst everything looks +normal. + +This way, the instance still can connect to the IPv4 IMDS endpoint and reply to +ARP probes from the hypervisor whilst the IPv4 connectivity won't be used the +IPv4 for internet. + + +[^1]: https://aws.amazon.com/blogs/aws/new-aws-public-ipv4-address-charge-public-ip-insights/ +[^2]: https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/ec2-launch-instance-wizard.html +[^3]: https://docs.aws.amazon.com/cli/latest/reference/ec2/modify-instance-metadata-options.html +[^4]: https://boto3.amazonaws.com/v1/documentation/api/1.26.86/reference/services/ec2/instance/metadata_options.html +[^5]: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/monitoring-system-instance-status-check.html diff --git a/writeups/ktcloud-review/ktcloud-review.kr.md b/writeups/ktcloud-review/ktcloud-review.kr.md new file mode 100644 index 0000000..c4251df --- /dev/null +++ b/writeups/ktcloud-review/ktcloud-review.kr.md @@ -0,0 +1,85 @@ +# 케이티 클라우드 사용 후기 +한국에 Fedora 미러가 다 사라져서 내가 직접 클라우드를 돌려 미러링 서비스를 해보려고 시도하였음. +결국 카이스트 미러 운영자와 연락이 닿았고, 운영자의 기지로 페도라 미러가 다시 살아나서 나의 계획은 +무산되었음. + +하지만 미러를 돌리려고 클라우드 서비스를 찾아보던 중, 케이티 클라우드가 트래픽을 기본 **2TB**나 +기본 제공한다는 것을 보고 한번 미러를 구축해보려고 시도를 하였음. 직접 사용해본 후기는 좋지 않음. +후기는 아파치 클라우드스택 기반 제품을 사용한 후기이며, 오픈스택은 기본료가 있으므로 사용해보지 +않았음. 기존 클라우드스택 기반 제품군들의 품질이 너무 낮음. + +기술팀의 실력도 문제가 있음. 무슨 문제가 있다고 문의를 넣으면 무슨 이유에서인지 질문의 요지 자체도 +이해를 못함. 꼭 전화를 해서 답을 얻은 경우가 대부분. + +- 무료체험 + - 다른 대형사의 free-tier를 겨냥한 것으로 보임 ... + - 무슨 홈피에 100만원 무료 체험이라고 회원가입해서 결제정보 다 넣고, 무료쿠폰 발급 버튼을 누르면 + 메뉴얼에 나온대로 쿠폰은 안나오고 무슨 변명만 되면서 쿠폰 안나옴. + - 쿠폰 적용하지 않은 상태에서 제품 사용해서 과금 시작되면 쿠폰 적용 대상이 아니라는 것은 뭐지 + - 무료 체험도 결국 지원팀이랑 전화 통화해서 받아야 하나? +- 해외카드 사용 불가 + - 청구지 주소 해외 주소로 사용 불가 + - 그냥 해외카드 처리를 못함 +- 영어 인터페이스 + - 그래서 영어 번역을 하다 만 것인가 + - 브라우저 표시 언어가 영어로 되있으면 UI 영어로 뜨는데, 곳곳에 한글이 섞여있음 +- 디스크 제한 + - SSD 머신 타입이 따로 있음. 더 비쌈. 왜? + - HDD 용량 300GB와 500GB로 제한되어 있음. 심지어 한 계정에(?) 볼륨 15개로 제한되어 있음 + - lvm으로 좀 붙혀쓰면 되긴 하지만... 여전히 충분하지 않은 스토리지 +- 트래픽 종류별 과금 없음 + - 트래픽이 좀 싸다? + - 하지만 트래픽 구분이 인터넷, 비인터넷 구분밖에 없음 + - NAS 등으로 가는 트래픽도 다 인터넷으로 구분된다 그랬음 + - 그래서 서버 스토리지 부족하다고 NAS 쓰면 요금 폭탄 맞는거 +- 구역간 이미지 복사 안됨 + - 요청을 넣으면 일단 실패로 뜨면서 이미지가 새 구역에 나타나지 않음 + - 근데 나중에 회원탈퇴 하려고 자원 다 지울 때 이미지 남아있다고 뜨는 건 함정 + - 그 유령 이미지가 계속 과금이 되고 있는 사실은 덤 +- 완전 심각함: 생성해주는 SSH 키가 RSA 1024bit 임 + - 그래서 리눅스에서 정책 때문에 쓰지 못함 + - 따라서 커스텀 이미지 생성이 가능하다 하더라도 제대로된 ssh 키를 못 넣으니 그냥 사용 불가 +- 콘솔 브라우저 문제 + - 크롬만 됨 + - 그럼 다른 브라우저로 쓸 때 경고를 주던가 +- 네트워크 기능 부실 + - 명색에 ISP라는 사람들이 IPv6를 나서서 지원해주지를 않음 + - 네트워크 인터페이스가 L2 기반이 아니고 L3 NAT으로만 루팅된다 + - 다시 말하면, 머신의 상태를 확인하기 위해 ping을 때리면 실제로 머신이 응답하는 것이 아니라 + 하이퍼바이저가 응답해서 ping이 무의미함 + - 근대 이상하게도 방화벽 설정에 icmp echo 설정을 할 수 있도록 해놨음. 의미 있나? + - TCP, UDP, ICMP 등 제외한 다른 IP 프로토콜은 설정으로 안 빠져있음(가장 크게 6in4) +- VM 상태 확인, 진단 기능 부제 + - cloud-init같은 agent 기반 상태 확인, L3 기반 상태 확인 등 기능 부실 + - 시리얼 포트 연결같은 기능도 없음(근데 rc.d 서비스는 열심히 콘솔 데이터를 하이퍼바이저로 + 전송한다) +- 로그인/세션 + - AI 칩만 있으면 뚫기 쉬워 유물인 captcha는 왜 아직도 쓰고 있나 + - OTP는 이메일하고 SMS 만 지원해서 불편함 + - OTP 쓴다고 부정사용 방지가 없어지는 것도 아님 + - 일반적으로 부정사용 패턴이 인지되면 captcha 등을 시작하는 대부분의 IDS와는 비교됨 + - 루트 콘솔 로그인 세션 타임아웃이 너무 짧음. captcha 때문에 더 짜증 +- sdk/api, IAM 지원은 잘 되려나? +- 고객센터 건성 답변 + - 업무 처리량이 많은지 질문의 요점도 이해 못하고 매크로성 답변만 낸다 + - 그래서 항상 전화를 하게 만듦 +- Rocky-9 이미지를 만드려고 내부를 뜯어봤는데... + - 세상에 cloud-init로 할 수 있는 passwd, hostname, ssh key 를 다 직접 구현해서 쓰고 + 있네? 심지어 systemd 서비스도 아니고 rc.d 에다가 구현함 + - 스트립트 날짜를 보니 2012년 정도라는데, 그 뒤로 모든 배포판이 systemd, NM를 적용할 때 + kt 클라우드는 아무것도 안했다는 답이 나옴 +- 기타 + - Server 창 Connection Setting의 항목 제거 불가 + - 변경/삭제 버튼은 Networking에서 가능. 뭐임. + - Server의 Connection Setting은 뭐고 Network의 Firewall은 뭐지? + - 사소한 공지사항을 동의없이 휴대전화 문자로 보냄. 끌 수 없음. + - 모든 메일을 한 곳으로부터 (cloudmaster@ktcloud.com) 보냄. BIG5 sender guideline에 + 어긋나서 IP reputation 떨구기 쉬울탠데 +- 현지 법률 + - 한국은 미성년자보호법 때문에 대부분 이런 서비스는 미성년자가 회원가입하기 힘들게 하는 것이 + compliance 일 탠데, 한국 법인인 케이티의 서비스로써 본인인증을 하지 않음? + +그래서 그냥 자동이체 끊어버리고 연락처 공백으로 지워버리고 프로젝트 종료... + +## 쓰려고 한 뻘짓들 +https://github.com/si-magic/ktcloud-init |
