Security

Athenzを完全理解したい願望 はい、書いてある通りです。athenz、理解したいです。 正直、個人開発レベルでは全然理解しなくていいやつです。しかし、大きな企業で、多くのサービスが動いていてサービス間でAPIを使い合いたいとかってなると必須の技術になると思います。いくら内部ネットワークとはいえね、認証された人だったりサービスのみにサービスの利用を限定しないと、もし仮に内部ネットワークに攻撃者が入ってしまった時に好き放題やられてしまうからね。 ということで、athenz完全理解を目指してやっていきたいと思う。 流れ athenzの各コンポーネントを紹介します。 athenzで使われているRBACについて説明します athenzを自宅のクラスターにインストールします インストールしたathenzを使って色々と試してみたいと思います。（プロバイダとテナントの通信、擬似攻撃者になってみるなど） そもそもathenzとは アプリケーション間のアクセスを制御するためのプラットフォーム、ですね。 アクセス制御ってのは、REST APIなどのリソースに対して、権限を与えることだよね。 アクセス制御を実現するための構成要素としては、３つあって、識別、認証、認可、の３つだね。 で、athenzの認証だけど、RBACってのが使われているんだよね。 rbacとは アクセス対象を役割ごとにグループ化する。んで、グループに対して権限を与える感じ。このグループのことをroleっていうんだよね。 大事なのは、人ではなく、roleに権限を与えるってこと。で、人をroleに追加する。 ちなみに、roleには色々あって、例えばcrudが全部できるroleも作れるし、閲覧しかできないroleを作ることもできる。 ちなみに、各roleに与える権限のことをポリシーという。これも大事。 roleにpolicyを付与する、という感じ。 リソースの提供者をプロバイダ、リソースの利用者をテナントという。そして、中央にathenzがいる。 で、識別情報のことをAthenz serviceとかっていう。ここがちょっと難しいね。あとでドメインって名前も出てくるけどさ。 athenzのアクセス制御の流れ テナントがプロバイダにアクセスするとき、まずテナントは中央のathenzにトークンを（ロールトークン）発行してももらう。このとき、テナント自身の存在を証明するためにx509証明書を提示する。（ここで一つ目の疑問。誰がx509証明書を発行してくれるのか？）で、発行してもらったトークンをhttpヘッダーにつけて、プロバイダにアクセスする。 プロバイダではathenz-proxyがapiの前で動いている。んで、中央にいるathenzから取得しておいた情報とアクセスを照らし合わせて、apiにプロキシするかしないかを決定する感じです。 アーキテクチャとコンポーネント 1. Management Server (ZMS) The ZMS is the central authority for managing and provisioning domain-based roles, policies, and resource permissions. It acts as the control plane where administrators define access control rules and service configurations. Key Features: Domain Management: Organizes services and resources into "domains" (like a namespace) with associated roles and policies. Role and Policy Definitions: Allows creation of roles (e.g., admin, reader) and policies specifying which roles can access specific resources. Audit Trails: Keeps a record of all configuration changes for security and compliance purposes. REST API: Provides APIs for managing domains, roles, and policies programmatically. Storage: Persistently stores configuration data in databases like MySQL. Athenz is a robust system for managing service-to-service authentication and fine-grained access control through its primary components: ZMS (Management Server), ZTS (Token Server), and its User Interface. 1. Management Server (ZMS) The ZMS is the central authority for managing and provisioning domain-based roles, policies, and resource permissions. It acts as the control plane where administrators define access control rules and service configurations. Key Features: Domain Management: Organizes services and resources into "domains" (like a namespace) with associated roles and policies. Role and Policy Definitions: Allows creation of roles (e.g., admin, reader) and policies specifying which roles can access specific resources. Audit Trails: Keeps a record of all configuration changes for security and compliance purposes. REST API: Provides APIs for managing domains, roles, and policies programmatically. Storage: Persistently stores configuration data in databases like MySQL. 2. Token Server (ZTS) The ZTS is the runtime component responsible for generating and validating short-lived tokens and certificates that services use to authenticate with one another. Key Features: Token Issuance: Issues Access Tokens (JWTs) and Role Tokens for authorization. Tokens are short-lived, improving security by reducing exposure to stolen credentials. Certificate Issuance: Provides short-lived X.509 certificates for mutual TLS authentication between services. Decentralized Authorization: Services can independently validate tokens or certificates using the ZTS public keys, reducing reliance on the ZTS during runtime. Dynamic Trust: Works seamlessly in dynamic environments like Kubernetes, issuing tokens based on pod identities. Integration: Compatible with OAuth 2.0 and OIDC for standardized authentication. 3. User Interface Athenz includes a user-friendly web-based UI that enables administrators and users to interact with the system without directly accessing APIs or configuration files. Key Features: Role and Policy Management: Intuitive interfaces for creating and managing roles, policies, and resource permissions. Domain Browsing: Easily navigate through domains and view their configurations. Audit and Reporting: Visualize audit logs and track changes to roles, policies, and resource access. Ease of Use: Simplifies complex RBAC configurations into a graphical and interactive platform, making it easier to onboard new administrators. コンポーネントのまとめ Summary of Workflow: Setup Phase: Use the ZMS or UI to define domains, roles, and policies. Runtime Phase: Services request tokens or certificates from ZTS to authenticate with other services. Decentralized Validation: Tokens are validated locally by consuming services using ZTS-provided public keys. 一旦用語説明 atehnz service ；アクセス元を識別するためのInfo role : 同じ権限を持つAthenz serviceをグループとしてまとめたもの。Athenz serviceを追加する感じ。 Policy : Roleでどのようなことが行えるのかを記したもの Domain : Athenz Service, Role, Policyを管理する名前空間 x509証明書：athenz serviceであることを証明するもの。 トークンの種類 設定 テナント側： まず、アクセス元を識別するためのathenz serviceを作成する必要がある。 そして、x509証明書を取得する必要がある。（これは秘密鍵を生成して、どこかにcsrを送って、証明書を配布してもらう、という流れだった気がするのだが） ちな、環境によってはこれらが自動化されていることもある。 ...

ECDH完全理解した。 参考 ECDHを紹介するyoutube 楕円曲線暗号をビリヤードに例えている例 ECDHの説明 かなり面白いね。ECDH。 まず、楕円曲線上で足し算というものを定義する。 これは、ビリヤードである。二点を決めて、その直線を引くと新たに楕円曲線と交わる点が生じる。それをx軸に対象に折り曲げた点、これを足し算の結果とする。 a + b = c ここで、p + p = 2pというものを定義可能である。pというのは、接線となる。 で、ここで不思議なのが、以下の結合法則が成り立つこと。 p + 2p = 3p 3p + p = 4p 2p + 2p = 4p 先に p + 2p = 3p 3p + p = 4p を計算して出した4pも 2p + 2p = 4p で出した４pも同じ点になる。これは面白い。 でだ、 こんな感じで最初の点Gを決めて、k倍した点Q Q = kP を求めることは簡単である。（例えば、k = 128の時は、2p+2p, 4P+4p,,,, 64p+64pで計算関数は少なく済む。） しかし、QとPからkを求めることは困難である。前から順番にやっていくしかないのである。 ということで、Qという値をサーバとクライアントで生成するんだよね。それぞれ、Q1,Q2. Q1 = K1P Q2 = k2P そして、Q1とQ2を交換します。opensslではRSAなどで署名が施されて交換されるので、真正性も担保される。 で、プリマスターシークレットを、 Q = K1K2P として、鍵交換が完了。これを元に共通鍵を生成して暗号通信がスタートする、という感じだ。 素晴らしい。 楕円曲線暗号のイメージは、以下のように説明されています。 ...

公開鍵暗号の体系を完全に理解した はい、鍵交換アルゴリズム、署名アルゴリズム、暗号アルゴリズム、暗号モード、ハッシュ の５つのセット（暗号スイート）を指定して通信を暗号化する。それが、俺が知っている暗号体系の全てです。 でですね、openVPNでクライアントとサーバの通信を暗号化しますよね。 その時に色々と証明書を発行すると思うんですよ。ただ、俺はどの証明書がどのように用いられるのかが全くわかっていなかった。 だから、今回、改めてopenVPNでクライアントとサーバを構築する際の証明書の役割などを確認したいと思う。 過去の僕の記事 basic client site to site routeing いつも参考にしている記事 qiita では追っていきましょう 認証局 (CA) の設立 ここから始まっているっぽいんだよね。 $ ./easyrsa init-pki init-pki complete; you may now create a CA or requests. Your newly created PKI dir is: path/to/easy-rsa/easyrsa3/pki CA証明書の生成 $ ./easyrsa build-ca パスフレーズが聞かれる。 ここで、秘密鍵と公開鍵がすでに生成されている。認証局のね サーバ証明書の生成 $ ./easyrsa build-server-full server nopass ここで、CA証明書を生成したときのパスフレーズを再び入力する。 これでおそらく、サーバの公開鍵に署名がされる。(CSRも済んでいる) DH鍵の生成 ここでDH鍵が生成されるのか。なぜだ？？TLSでのDH鍵は毎回違うものが使われるのではないのか！？ なるほど、chatGPTに聞いたのであっているかはわからんが、この段階で生成されるものは、DHパラメータ（素数と生成元）だね。 これは納得だね。 つまり、 y = g ^ (x) mod p の、pとgが生成される。で、サーバとクライアントはお互い適当にxを選ぶわけですわ。はい完全理解。 ちなみに、ecdhを使って鍵交換をすることもできます。 証明書失効リストの生成（こちら、参照しているページでは間違っているので注意が必要） $ ./easyrsa gen-crl こちらも、CAの秘密鍵で署名するわけですね。 クライアント用秘密鍵の生成 $ cd easy-rsa/easyrsa3 $ ./easyrsa build-client-full username はい、ここでクライアントの証明書と秘密鍵を生成するわけですね。 で、証明書はCAが認証する必要があるので、再びパスフレーズを入れる感じになります。 ...

前提知識 TLSでは、 鍵交換アルゴリズムを使って共通鍵の材料となる値を交換し、共通鍵を生成し、その鍵を用いて通信が暗号化されるわけですね。 鍵共有に使われる暗号を、公開鍵暗号と言いますね。共通鍵は、共通鍵暗号です。 公開鍵暗号 RSA DH ECDH DEH = DH ephemeral ECDHE = ECDH epemeral DHとECDHは離散対数問題を使っています g^x mod p = y で、y,p,gが与えられたとき、xが求められないってことね 共通鍵暗号 RC4 (危殆化) DES = (危殆化) 3DES きたいか ChaCha20 AES = 最も使われていて安全 RC4 = ストリーム暗号 AES = ブロック暗号 ハッシュ関数 MD5 SHA-1 SHA-2 SHA-3 TLSの暗号スイートについて はい、これすごく大事なこと言います。TLSを使って通信が暗号化されるまでの流れですね。 TLSハンドシェイク 実際にTLSの通信が始まる でですよ。TLSハンドシェイクで何を決めているか？なんですが、以下を決めているわけですね。 鍵交換アルゴリズム 署名アルゴリズム 暗号アルゴリズム 暗号利用モード ハッシュ関数 鍵交換アルゴリズムは上に書いた、RSA,ECDHE,DHEです。 署名アルゴリズムは、RSA/ECDHEを指定できますが、ここは、発行したサーバ証明書の鍵の種類に依存します。ここすごく大事。 実は、鍵交換アルゴリズムで生成されたあたいは、さらにサーバ証明書の秘密鍵で暗号化され、公開鍵で復号されるんですね。で、真正性を確かめるんですよね。 ここ、知らんかった。すごく大事。 ただ覚えておきたいのが、RSAを用いた鍵交換では、署名がなされないということ。証明書の公開鍵は、クライアントが生成したプリマスターシークレットを暗号化するために使われる。そして、秘密鍵で復号するんだよね。 ECDHEでは、毎回公開鍵が生成されるんだよね。で、その公開鍵の正当性を証明するために秘密鍵で署名し、公開鍵で検証するんだよね。 RSAを用いた鍵交換では毎回同じ公開鍵と秘密鍵のペアで通信がなされるんだよね。プリマスターシクレットも含めてね。 だから、スノーデン事件の時みたいに、暗号化されたものをずっと溜めておいて、後でどうにか秘密鍵を入手して、プリマスターシクレットを特定、 からの通信内容を特定、といったことができてしまうんだよね。これ、前方特秘性がないって言いますね。 これに対して、ECDHE、DHEは、一回一回秘密鍵と公開鍵を生成するんだよね。はいそうだね。 でも、公開鍵から秘密鍵は、頑張れば何年かかければ、推測可能だよね？だから前方特秘性は、ないと思うんだけど。 これをchatGPTに聞いてみたらこう帰ってきました。 Q. 離散対数問題は時間をかければ解読可能です。各セッションで使われる公開鍵から秘密鍵を割り出すことも、原理上は可能です。 そこで、各セッションの公開鍵と、暗号化された通信全てを保存している人がいたとしましょう。そうすると、時間さえかければ、暗号文を解読できると思うのですがいかがでしょう。 ...

この記事の流れ opensslで秘密鍵を発行してみる 秘密鍵の中身を見る RSA暗号の解説。証明。 rsa暗号でサーバ証明書を発行するまで SAN付きのサーバ証明書の作り方 lets encryptでsan付きのサーバ証明書が作れるか そもそもsslサーバ証明書とは？ 「サーバー証明書」とは、「通信の暗号化」「Webサイトの運営者・運営組織の実在証明」の2つの役割をもつ電子証明書です。 です。つまり、証明書には、暗号化用の鍵＋証明書が入っている、ということになる。いいですね。 秘密鍵の中身をのぞいてみる。 秘密鍵の作成 $ sudo mkdir /etc/nginx/ssl $ sudo openssl genrsa -out /etc/nginx/ssl/server.key 512 秘密鍵を作っているけど、公開鍵はどこにあるのか？？というのが非常に気になります。ていうか秘密鍵が因数分解されたものなんだっけ？ だからいいのか。掛け算したら一瞬でわかるって話か。おけ。ってことでさ、適当に鍵を一つ作ってみたんだよ。 ちなみに、512bitより短い鍵は作れません。これすごいよね。 -----BEGIN PRIVATE KEY----- MIIBVAIBADANBgkqhkiG9w0BAQEFAASCAT4wggE6AgEAAkEA4dNuxX/SzX3wEhde FmNFXLWlNkbGq4xaU6CfKy2nI9K+SWSKueJWSjoanmEG1eb6cXozmAk4eiuKm7zv +FdQowIDAQABAkB+1CdnRoXXIT7eej8+ZZyEGARkulVD7XyhcRlTv70aMWjC29cG 1LIeSScmy5ChqoGwH9Ow/BRzZXax3yeqMQFJAiEA9m+ardfTOK/xVoSn3I5pkzoR prW2xLQi0IDsv5lEu3UCIQDqlxAo6aDT0KpBBe5HbxBgw7uf34G+m7LJs/JnoMYQ twIgALXvr0KpFEfFnWdCiKtMeKU5Oc7aWRTf6NQGWsMZZKUCIFxk6wRyH9nNEYFS qKqR3818yeUJzrwX7q7qpMqT0+65AiEAqWRxDU6t8ZjPmJd6B7w481FuwrFmF9cq mq+QXX8gjRw= -----END PRIVATE KEY----- echo "MIIBVAIBADANBgkqhkiG9w0BAQEFAASCAT4wggE6AgEAAkEA4dNuxX/SzX3wEhde FmNFXLWlNkbGq4xaU6CfKy2nI9K+SWSKueJWSjoanmEG1eb6cXozmAk4eiuKm7zv +FdQowIDAQABAkB+1CdnRoXXIT7eej8+ZZyEGARkulVD7XyhcRlTv70aMWjC29cG 1LIeSScmy5ChqoGwH9Ow/BRzZXax3yeqMQFJAiEA9m+ardfTOK/xVoSn3I5pkzoR prW2xLQi0IDsv5lEu3UCIQDqlxAo6aDT0KpBBe5HbxBgw7uf34G+m7LJs/JnoMYQ twIgALXvr0KpFEfFnWdCiKtMeKU5Oc7aWRTf6NQGWsMZZKUCIFxk6wRyH9nNEYFS qKqR3818yeUJzrwX7q7qpMqT0+65AiEAqWRxDU6t8ZjPmJd6B7w481FuwrFmF9cq mq+QXX8gjRw=" | base64 --decode これでデコードしてもバイナリだからなんもわからんわ。 いかのスクリプトでデコードできるみたい。 from Crypto.PublicKey import RSA # Load the private key with open("private_key.pem", "r") as file: private_key = file.read() # Parse the private key key = RSA.import_key(private_key) # Extract the components n = key.n # Modulus e = key.e # Public exponent d = key.d # Private exponent p = key.p # Prime 1 q = key.q # Prime 2 print(f"Modulus (n): {n}") print(f"Public exponent (e): {e}") print(f"Private exponent (d): {d}") print(f"Prime 1 (p): {p}") print(f"Prime 2 (q): {q}") Modulus (n): 11827462552050103756019456673259686146276364164688350469602565108471900615793415256864500417710852720839063036792768824435280979352135219586691204539437219 Public exponent (e): 65537 Private exponent (d): 6642559381010851411383007183311248119169234719466623674178885422700539328402280041863549141435055457596044186231508711647457747564061370576607226853654857 Prime 1 (p): 111466148331411145531384799415569793304697439187343498431136600736302912289653 Prime 2 (q): 106108112006209210762976910352826494821357000184205525073929931397132009738423 ということですね。はい。 はい、でさ、RSA暗号の仕組みも今勉強してしまいましょうか。 ...

oauthの大枠について、いい感じに理解したので、覚えているうちにアウトプットしておく まあ、経験的にもわかると思うけど、新しくemailを登録してそこに確認メールを送って、認証する、っていうやつ、あれやっぱり面倒くさくて、CVR下げるのよね。ってことで、やっぱりgoogleとかLINEとかを使った認証のほうが圧倒的に楽なわけですわ。ポチってしまうわけですわ。これ、自分のアプリに組み込むことで圧倒的にユーザを確保できると思うんですよね。ってことで、 仕組み 大事なのは、どのフェーズにおいても、URLそのものに重要な情報を乗っけてやり取りしてるってこと。 まず、ユーザがログインページでgoogleによる認証をクリックしたとするよね。これはゲットリクエストなわけですわ。このgetリクエストに対して、サーバはユーザをgoogleの認証サーバにリダイレクトするわけです。 で、リダイレクトのurlの中にこのサイトの情報が乗ってるんですよね、サイトのIDってやつです。 このIDは事前にgoogleのdeveloperサイトでもらえます。google側はこのIDでどのサイトかを判別しているんですね。更にこのサイトでコールバックのURL (ユーザがgoogle側にこのアプリに情報を送ることを承認するボタンを押したあとにリダイレクトされるURL) も登録しておきます。 で、ユーザが承認すると、コールバックのURLにユーザの情報にアクセスするためのトークンを乗っけてこっちにリダイレクトされるわけですわ。 で、そのトークンを使って、ユーザの情報にアクセスできるようになるわけです。 ただ、自分でメール認証の仕組みを作るのも重要だとは思っている。 これの作り方、そんなにむずくないよね。 まず、ユーザにメールアドレスを入力してください。ってお願いするわけです。 で、入力されたメールアドレスに、このサイトのurlと/auth/mail/{random} みたいなのを入れておくわけですわ。randomっていうのが、そのメールアドレスと一時的に紐付けられているランダムな値です。で、ユーザが/auth/mail/{random}にアクセスしてきたら、まあ、実際にそのメールアドレスがあったんやなってわかるわけですわ。まあなんでもいいよ、mail2uuid := map[string]stringとかで管理しているやつと for k,v := range m { if v == uuid { // そのイーメールアドレスを認証する、って感じです。 // このときにcookieを入れておくといいですね。ええ。 // cookieとemailを紐付けるのを忘れないように。 // useridとパスワードを入力するページにリダイレクトします。 // って感じです。はい。 } } これ、有効期間決めておいたほうがいいですね。数分とかそんな感じで。 ちなみに、golangからemailを送信する一番いい方法なんだけど、 やっぱり、リレーするのがいいみたいです。ええ。 chatGPTに出してもらったコードがこちらですね。 package main import ( "net/smtp" "log" ) func main() { // Sender and recipient email addresses. from := "your_email@gmail.com" to := "recipient@example.com" // SMTP server configuration. smtpServer := "smtp.gmail.com" smtpPort := "587" smtpUsername := "your_email@gmail.com" smtpPassword := "your_email_password" // Compose the email message. subject := "Hello, Golang Email!" body := "This is a test email sent from a Golang application." // Define the SMTP server's authentication information. auth := smtp.PlainAuth("", smtpUsername, smtpPassword, smtpServer) // Create the email message. msg := "Subject: " + subject + "\r\n" + "To: " + to + "\r\n" + "From: " + from + "\r\n\r\n" + body // Send the email. err := smtp.SendMail(smtpServer+":"+smtpPort, auth, from, []string{to}, []byte(msg)) if err != nil { log.Fatal(err) } log.Println("Email sent successfully!") } 決済の方法についてもいくつかあると思うので、まとめておきたい。 まずは、どの決済を組み込むかなんだけど、まあ普通に paypayとpaypalとまああとはクレジットカードでいいかね。 そうね、ユーザにポイントを付与する感じにするか。 1シミュレーション100ポイントとかにしてとかにして、って感じかね。 実際に購入画面に進むためには500ポイントとかにして。1000ポイント買うと、200ポイントおまけでついてくる、とかにしてね。 ...

Squidについて Squidはプロキシやリバースプロキシの機能を提供するソフトウェアです。 プロキシを置く理由 主に、サービスの利用者向けのソフトウェアですね。 リバースプロキシを置く理由 リバースプロキシサーバーをバックエンドサーバーの前段に置く理由は、主に以下の５つです。 キャッシュサーバーとして利用 レスポンスを圧縮 (レスポンスの転送を高速化) SSL ターミネーション (暗号化や復号化の処理をリバースプロキシにオフロード) セキュリティの向上 (リバースプロキシでフィルタリング、バックエンドサーバーを隠蔽) 拡張性 (クライアントはリバースプロキシと通信するので、バックエンドサーバーを変更可能) こっちは主に、サービスの提供者側向けのソフトですね。 僕がやりたいこと 全部の通信が、Torみたいに、複数のサーバを介して行われる感じにしたいんですよね。んで、最終目的地はデータベースです。ユーてこれって、openvpnとかでじっそうできるのかな？いやできないか。 ネットワークの通信、頑張って自分で作れたりするのかな。いけそうな気もするな。

注意： この記事はハッカーが主人公の物語から抜粋した一部である。 これだからWebは最高だ はい、なんていうんでしょうかね、Webアプリケーションのペネトレーションテストができるめっちゃ便利なツールを見つけてしまったんです。まあ、これを見つけたきっかけは、あるサイトのAPIフォーマットを特定したかったっていうことなんですけど、いかんせん最近のサイトはSSLで暗号化されているからWireshark等のNICでパケットをキャプチャするツールじゃあ中身は解析できないんですよね。そこで見つけたのが、ZAP、通称man-in-the-middle-proxyってい神ツールです。クライアントとサーバの間に立って動作するこのツールは、まあプロキシとして働いてくれて、SSLの内容を見放題。その他にも便利な機能がたくさんついている。まじで神！！ zapのインストール zapはjava上で動く。Ghidraといい、すごいツールはなんかJavaで書かれているんだけど、その理由は何だろう。まあいいや。まずはJavaをインストールする。11+がいい。 sudo apt install default-jre sudo apt install default-jdk その次、 ZAPの公式からinstallerを持ってきてあとは、シェルスクリプトを走らせるだけ。 ZAPの使い方 基本的にはWebブラウザでアクセス可能なページの診断だったり脆弱性のチェックに使う。で、完全に自動化された脆弱性診断のAutomated scanっていうのと、ブラウザを普通にいじっているみたいに自分で脆弱性を見つけるManual scanっていうのがある。 気をつけてほしいのが、scanをするともう攻撃とみなされても仕方がない、ということ。 しかし、モードを選べて、safe modeっていうのを選択すると、攻撃とみなされないかも。わからん。 Automated Scan これは、ターゲットとなるサイトのディレクトリ構造をクローリングして各ページに対して、脆弱性チェックのリポートを出してくれるツールになっている。うん、結構便利だと思う。 manual scan これがこのツールの真骨頂だと思う。HUDっていう、新しい機能なんだけど。HUDの説明簡単に下に書いておくか。 The HUD is a completely new way to interact with ZAP. It overlays security information on top of the application you are testing and allows you to access key ZAP features. It is easier for people new to security to understand but it also allows experienced penetration testers to focus on the application they are testing. By default, the HUD is injected into all of the HTML pages proxied through the ZAP desktop. You can turn it on and off easily using the [green radar] button on the ZAP toolbar. It is not injected by default into pages proxied through ZAP when it is running in headless/daemon mode as that could break unit tests. This behaviour can be changed via the HUD options. まずは、各ページ、さらに今まで訪れたページ (そのサイトの)に対して、脆弱性のレポートを出してくれるってところは前と同じ。だが、ここからがすごい。まじで。httpとwebsocketのリクエストの内容が全部見られるってところ。これはやばくないか？？？やばいね。 さらに、変更が許されていないフォームを変更したり、リクエストを送るときにリクエストの内容を書き換えたり、リクエストをpendingしたりできる。これはやばい。見放題だね。ちょっと怖いね。今日の夜が楽しみすぎるって話なんだわ。ちょっとできることまとめるわ。 ...

ことはじめ 世界中に自分が入れるサーバがあったほうがいろいろと便利かなと思い、ブルガリアのサーバを借りた。はいいのだが、早速ハッカーがお出ましなさった。ってことでやっつけたいと思う。 ハッカーのIPの特定 sudo lastbでログインを試みて失敗したIPアドレスの一覧が表示可能である。 ハッカーに人権はないのでsudo lastbで侵入を試みようとしたIPの一覧をアップしておく。このサイトをご覧の皆さんにもぜひ攻撃していただきたい。正当防衛である。 45.136.15.210 157.245.49.188 196.179.231.103 175.126.176.21 118.98.121.241 213.202.223.97 192.241.169.184 187.235.65.53 195.133.40.249 194.110.134.13 まずは守りを固める sshポートを変更 /etc/ssh/sshd_config で Port xxxxx に変更。ufwでxxxxをallowにしてreload。これを忘れると入れなくなる。で、22をdenyしておくとさらにいいかもね。 もちろん、奴らは素人なので、sshdが待ちうけるポート番号が22以外になるなんて知っている奴はいないわけで、不正アクセスが一気に減ったという話だ。ははは。ざこめ！いや、普通にポートを変えてもやってくるわ。しぶとい奴ら。 nmapでポートの状況を調べる 実際に調べたわけではありませんが。 Starting Nmap 7.80 ( https://nmap.org ) at 2023-01-25 14:48 UTC Nmap scan report for 45.136.15.210 Host is up (0.24s latency). Not shown: 995 closed ports PORT STATE SERVICE 21/tcp open ftp 22/tcp open ssh 111/tcp open rpcbind 646/tcp filtered ldp 3306/tcp open mysql ftpコマンドで以下のテキストを送る Dear My friend!! Hello! my name is kim jong un! We've detected cyber attacks from your computers. Because of that, we are considering to take legal action!! Oyoyoyoyyoooooi!!!!!!!!!!!!!! Unfortunately we know all about you including your name, age and address. If you don't wanna that to happen please pay 0.1 btc to the address below, within a week! HaHaHa!!! bc1q9xezwy9z6xde3960p8fs3uxmhd3tqs6hdcc4mx Thanks you mate!! ⠀⠀⠀⠀⠀⣀⣠⠤⠶⠶⣖⡛⠛⠿⠿⠯⠭⠍⠉⣉⠛⠚⠛⠲⣄⠀⠀⠀⠀⠀ ⠀⠀⢀⡴⠋⠁⠀⡉⠁⢐⣒⠒⠈⠁⠀⠀⠀⠈⠁⢂⢅⡂⠀⠀⠘⣧⠀⠀⠀⠀ ⠀⠀⣼⠀⠀⠀⠁⠀⠀⠀⠂⠀⠀⠀⠀⢀⣀⣤⣤⣄⡈⠈⠀⠀⠀⠘⣇⠀⠀⠀ ⢠⡾⠡⠄⠀⠀⠾⠿⠿⣷⣦⣤⠀⠀⣾⣋⡤⠿⠿⠿⠿⠆⠠⢀⣀⡒⠼⢷⣄⠀ ⣿⠊⠊⠶⠶⢦⣄⡄⠀⢀⣿⠀⠀⠀⠈⠁⠀⠀⠙⠳⠦⠶⠞⢋⣍⠉⢳⡄⠈⣧ ⢹⣆⡂⢀⣿⠀⠀⡀⢴⣟⠁⠀⢀⣠⣘⢳⡖⠀⠀⣀⣠⡴⠞⠋⣽⠷⢠⠇⠀⣼ ⠀⢻⡀⢸⣿⣷⢦⣄⣀⣈⣳⣆⣀⣀⣤⣭⣴⠚⠛⠉⣹⣧⡴⣾⠋⠀⠀⣘⡼⠃ ⠀⢸⡇⢸⣷⣿⣤⣏⣉⣙⣏⣉⣹⣁⣀⣠⣼⣶⡾⠟⢻⣇⡼⠁⠀⠀⣰⠋⠀⠀ ⠀⢸⡇⠸⣿⡿⣿⢿⡿⢿⣿⠿⠿⣿⠛⠉⠉⢧⠀⣠⡴⠋⠀⠀⠀⣠⠇⠀⠀⠀ ⠀⢸⠀⠀⠹⢯⣽⣆⣷⣀⣻⣀⣀⣿⣄⣤⣴⠾⢛⡉⢄⡢⢔⣠⠞⠁⠀⠀⠀⠀ ⠀⢸⠀⠀⠀⠢⣀⠀⠈⠉⠉⠉⠉⣉⣀⠠⣐⠦⠑⣊⡥⠞⠋⠀⠀⠀⠀⠀⠀⠀ ⠀⢸⡀⠀⠁⠂⠀⠀⠀⠀⠀⠀⠒⠈⠁⣀⡤⠞⠋⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ ⠀⠀⠙⠶⢤⣤⣤⣤⣤⡤⠴⠖⠚⠛⠉⠁⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀⠀ あらららら。FTPコマンドはどうやらログインパスワードが必要みたいだね。これじゃあハックするのは難しいな。 ...