フリーWi-Fiを使ったら秘密情報を抜かれる経路にはどのようなものがあるか - Qiita
ゴールデンウィークのはじめ（4月29日）に投稿された以下のツイートですが、5月7日20時において、1,938.8万件の表示ということで、非常に注目されていることが分かります。 我が名はアシタカ！スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた。どうすればよい！ pic.twitter.com/e26L1Bj32Z — スタバでMacを開くエンジニア (@MacopeninSUTABA) April 29, 2023 これに対して、私は以下のようにツイートしましたが、 これ入社試験の問題にしようかな。『スタバのFreeWi-Fiを使いながら会社の機密情報を扱う仕事をしてたら全部抜かれた』と言う事象に至る現実的にありえる脅威を説明せよ。結構難しいと思いますよ。 https://t.co/LH21zphCTV — 徳丸 浩 (@ockeghem) April
パスワードの1文字目に「~(チルダ)」を使って痛い目にあった - Qiita
何を言っているんだと思われるかもしれないですが、気軽にパスワードの1文字目に「~」を使わないほうがいいというお話です。 起こった問題 踏み台サーバー経由でサーバーAに接続して作業をしていた時の話です。 いわゆる多段 ssh 接続というもので、リモートワークになってからは結構使われる方も多いかと思います。 サーバーA上で root 権限になろうと sudo su - してパスワードを入力したら Connection to xxx.xxx.yyy.zzz closed. の文字とともにサーバーAから追い出されてしまいました。 なにかの間違いだろうと何度か挑戦していたのですが、結果はサーバーAから切断され踏み台サーバーに戻る羽目に。。。 そのときに入力していたパスワードが ~.xxxxxxxxxx のような ~ から始まるものでした。 調査 ~ って何か意味があったよなーと思ってどう調べようかと
Bashの邪悪なコマンド9選 - Qiita
rm -rf /やったことある人。 私はないです。 以下はAndreas Müller( Twitter / GitHub / LinkedIn / Medium )による記事、9 Evil Bash Commands Explainedの日本語訳です。 9 Evil Bash Commands Explained 初めてターミナルを使って、そしてそれを理解したときのことを覚えています。 あらゆるファイルにアクセスし、全てのプログラムを実行し、黒い画面に何かを入力するだけでシステムの全てを完全に掌握できることに気がついた、あの感覚。 そしてもちろん、致命的ミスを犯して全てを失った、あのときの恐怖も。 私は本当はシステム管理者ではありませんが、長年にわたってLinux/UNIXベースのシステムで作業してきたので、コマンドを実行しようとしてEnterキーを打つことを躊躇う状況に何度も遭遇しまし
ほんとうに怖い。さくらのレンタルサーバー - Qiita
Help us understand the problem. What is going on with this article? さくらで専用サーバーを１０年ほど利用しています。 単体のハードを利用するもので、外部からの操作はsshでログインすることしかできないものです。 作業時間を必死に捻出して、こつこつと長期間システムを開発して何とか動作するものを作り上げていました。 さくらのレンタルサーバーを利用することは、ほんとうに危険で怖いことだとおもいます。 自分が体験したトラブルをレンタルサーバーの利用を検討している方々に共有させていただきたく初めて記事を書いてみました。 二年ほど前、さくらさんが専有サーバーの場所を移動したいという申し出があり快く許可しました。その時のご説明では、場所を移動するだけでハードの変更は一切行いませんというもので、今まで通りの動作が保証される作業内容というこ
DDD くらいできるようになりたいよねって話 - Qiita
はじめに 私自身は今年の 7 月にドメイン駆動設計（DDD）を実践する企業に転職したばかりで DDD 実践歴は浅いのだが、最近は開発業務の他にも中途採用者の DDD 教育や 現場で DDD！2nd のドライバー役をする機会を頂くなど、DDD の布教活動にも少し関わっている。 その中で「DDD ムズイ」という言葉をよく聞いたので、DDD の実践に悩んでいる人向けにサンプル問題の解説を通して、実は DDD 自体は難しくないんだよってことを教える目的で本記事を書いた。 TL;DR（最初に結論） DDD 自体はドメインを中心にモデリングと実装をイテレーティブに繰り返す設計プロセスであり、モデリングと OOP の理解があれば誰でもできる。 難しいのは DDD 自体ではなくて、モデリングまたは OOP である。特に「良いモデル」を得ることは非常に難しい。 なので「DDD ムズイ」と感じる人はモデリング
心理的安全性ガイドライン（あるいは権威勾配に関する一考察） - Qiita
はじめに 「心理的安全性」とは、「対人リスクを取っても問題ないという信念がチームで共有されている状態」であるとか、「自分のキャリアやステータス、セルフイメージにネガティブな影響を与える恐れのなく、自分を表現し働くことができること」というような定義がなされています。 心理的安全性という言葉はともすれば、ただ快適で居心地のよい職場という意味にも聞こえます。そのため、ぬるま湯で緊張感のない関係性のことを「心理的安全性が高い」と言うのではないかと考えても不思議はありません。 そのため、友人関係のようにプライベートの時間を長く共有する関係になることが、心理的安全性が高いのだろうと考え、飲み会やバーベキュー、慰安旅行などを企画してみたりとプライベートでも遊ぶ機会を増やそうと考える人もいるでしょう。 いわゆる「アットホームな会社です」とアルバイトの求人記事に書かれているような状態です。こういった求人内容
bashの初見殺しっぷりがハンパない件 - Qiita
「これ知らなきゃ分からないだろ！」 「エラーの原因はわかったけど、なんか腑に落ちない」 いま悩んだ２時間返せ！ bashというか、UNIXのコマンドに慣れてない 僕みたいな新人エンジニアが 気をつけた方がいいポイントまとめました。 あいことばをわすれない 微妙にエラーが出ないため、気づかないまま進んでしまい、 のちのち絶妙に致命的なことになってしまうので注意。 一行目忘れて２時間悩みました 二行目のオプションつけなかったため２時間悩みました setのオプションはお好みで あいことばの解説： http://qiita.com/magicant/items/f3554274ee500bddaca8 半角スペースをつけるな！半角スペースをつけろ！ shellさんはスペースに非常に神経質です。 よくある変数代入では=の前後にスペースいれてはダメです。
SELinux を使おう．使ってくれ． - Qiita
この記事の目的 SELinux って邪魔者ですか？ 「トラブルシュートの時に邪魔だから」「トラブルの元だから」とか言う理由で /etc/selinux/config で SELINUX=disable したり setenforce 0 したりしていませんか？ SELinux は理解さえすればとても簡単です． 本番環境でファイアウォールと WAF の設定をして満足していないで SELinux を使いましょう． 対象 SELinux を初めて触る人向けです． 玄人の方は他へ．．． 本稿の範囲 本稿では SELinux を導入しておしまいです．あくまで「みんな，簡単だからね，使おうね！」と言いたいのです． 本当は SELinux の効果を示すために Exploit を仕込んだアプリケーションから root を取って不正にファイルに触るところまでやりたいのですが，これまた別の記事にします． 僕の願
質問は恥ではないし役に立つ - Qiita
一年半SEとして働いてきた中で、私自身が苦手だと思っており、他人からもそのように評価されていたのが「質問の仕方」でした。 それが先日、他人から「質問の仕方がうまいね」と褒められることがあり、ようやく一人前の質問の仕方ができるようになってきたので、どのようにして克服できたのか紹介したいと思います。 質問の基本形 私が入社したばかりの頃は、わからないことがあればすぐに先輩に質問していました。 そのときにしていた質問の内容はだいたいこんな感じです。 「環境構築を手順書通りにやったんですけど、○○のコマンドでエラーがでてしまいます！なんとかなりませんか？」 このような質問を受け取ったら、先輩は暇ならばエラーメッセージを見てくれ、エラーメッセージに書かれていることに対して調査してくれるかもしれませんが、忙しいときにはそんなことはしてもらえません。 こんな質問を繰り返しているうちに先輩からは「技術系メ
プログラマーの君！ 騙されるな！ シェルスクリプトはそう書いちゃ駄目だ！！ という話 - Qiita
本記事が切っ掛けとなってお声がけを頂き、本記事の増補リファイン版となる記事をSoftwareDesign 2018年1月号のシェルスクリプト特集第2章として執筆しました。リファイン版には、この記事で触れていない文法面での分かりにくさについての解説が含まれています。その文法面での分かりにくさの解説の一部に相当する記事もありますので、ぜひそちらも併せてご覧下さい。 Shell Script Advent Calendarをご覧の皆様、図々しくも5日目に続く2度目のエントリーのPiroです。 前回は自作のBashスクリプト製Twitterクライアントをネタに実装を解説しましたが、今日は他の言語で多少のプログラミング経験はあるんだけど、どうにもシェルスクリプトは苦手だ……という人のための、シェルスクリプトによるプログラミングの勘所を解説してみようと思います。多分、プログラミング入門レベルの人や上級
【統計学】初めての「標準偏差」（統計学に挫折しないために） - Qiita
統計をこれから学ぼうという方にとって、非常に重要な概念ですが理解が難しいものに「標準偏差」があると思います。「平均」くらいまでは馴染みもあるし、「わかるわかるー」という感じと思いますが、突如現れる「標準偏差」 の壁。結構、この辺りで、「数学無理だー」って打ちのめされた方もいるのではないでしょうか。 先にグラフのイメージを掲載すると、下記の赤い線の長さが「標準偏差」です。なぜこの長さが標準偏差なのか、ということも解き明かしていきます。 (code is here) 本記事では数学が得意でない方にもわかるように１から標準偏差とはなにか、を説明してみようという記事です。 数式はわかるけど、イマイチ「標準偏差」の意味わからんという方にも直感的な理解がしてもらえるような説明もしていきますので、ぜひご覧ください。 （※ この記事では標準偏差の分母に $n$を使用しています。$n-1$を使用するケースも
IT業界で横行する恥ずかしい英語発音 - Qiita
プログラマやデザイナと話してるとしょっちゅう変な英語発音に出くわします。 例えばheightを「ヘイト」と発音したり。 そういう時、私は心では「ヘイトじゃないよハイトだよ！」と呟きつつ、口では「そうですね、ではヘイトは80pxにしましょう！」なんて言ってるのであります。 まあ、所詮我々が話しているのは英語ではなく、日本語の中に出てきた英単語をカタカナで発音しているに過ぎないですし、テレビのテロップでmainをメーンと表記する時代ですので正解などは無いと思っています。 ですから、何でもかんでも正しい英語っぽく発音するべきなどとは思っていませんが、やはり「こいつ適当にスペルを日本語読みしてるだけだろ！」ってのが明らかな場合は、聞いているこっちが恥ずかしくなってしまうものです。 というわけで、この業界で横行してる妙な発音をまとめてみました。 間違って発音すると恥ずかしい英語 これらは間違って発音
社内プロキシに虐げられてる人たちはVPSとか借りて社外にプロキシ立ててsshトンネルで繋ぐとウハウハですよってお話 - Qiita
概要 社内プロキシに様々なサイトへのアクセスをブロックされたり、社外サーバにsshできなかったりする人向けに社外プロキシを立ててあらゆるサイトにアクセスする方法のまとめです。(後述しますが半分くらいネタポストです。) 他にも以下のような効果がありますので、プロキシフリーな会社にお勤めもし良かったら参考にして頂ければと思います。 なぜか2015年になっても存在するカフェとかホテルとかでの保護されていなかったりする無線wifiを使っても盗聴されない。 日本からアクセスできないサイトにアクセスできる。(海外のデータセンタ上のVMを使った場合) なお、非認証プロキシを例にしてます。認証プロキシでもあまり変わらないとは思いますが、環境が無いため未確認です。また、プロキシの挙動や設定方法はプロキシサーバの種類や設定によって多岐に渡るため、全てのプロキシで同じ方法が使えるとは限らないとは思います。 最後
そこそこセキュアなlinuxサーバーを作る - Qiita
先日「サーバーのセキュリティ設定がなにすればいいかわからない」と相談をうけまして。 自分も初心者の時どこまでやればいいかわからず手当たりしだいにやって沼に入っていたのを思い出しながら自鯖構築したときのメモを元にまとめてみました。 注意 セキュリティ対策は用途や場合などによって違います。 自分で理解したうえで自己責任でおねがいします。 対象読者 Linuxのサーバーを建て慣れていない人 Linuxはある程度さわれる人(自分でパッケージを入れたり、サービスを止めたりできる) ラインナップ ☆は導入の重要度と導入の容易さから個人的偏見からつけた値です。 4つ以上が"最低限やること"だと思ってください。 sshd
モデルやメソッドに名前を付けるときは英語の品詞に気をつけよう - Qiita
はじめに 他の人が書いたコードを読んでいるときに時々気になるのが、英語の間違いです。 特に動詞、名詞、形容詞の使い分けが間違っていたりすると、かなり違和感を感じます。 そこで今回はモデル（＝クラス）やメソッドに名前を付けるときの基本的な原則をまとめてみます。 また、英文法的に正しい品詞が選べるようになるための習慣についても最後に説明します。 想定する言語/フレームワーク この記事の説明ではRuby/Ruby on Railsを想定しています。 ただし、基本的な考え方は他の言語でも同じように使えるはずです。 モデルの名前は名詞にする 例: 「支払い情報」を表すモデルを作りたい場合 × Pay ○ Payment 「支払う = payか。よし。」でモデルを作ってはいけません！ payは動詞で、payの名詞形がpaymentです。 Payモデルではなく、Paymentモデルを作りましょう。 例:
俺史上最強のiptablesをさらす - Qiita
#!/bin/bash ########################################################### # このスクリプトの特徴 # # 受信・通過については基本的に破棄し、ホワイトリストで許可するものを指定する。 # 送信については基本的に許可する。ただし、サーバが踏み台になり外部のサーバに迷惑をかける可能性があるので、 # 心配な場合は、送信も受信同様に基本破棄・ホワイトリストで許可するように書き換えると良い。 ########################################################### ########################################################### # 用語の統一 # わかりやすさのためルールとコメントの用語を以下に統一する # ACCEPT :
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
