t_wの輪郭

Feedlyでフォローするボタン
RDBSQLRDBMS
あれpgvectorあれAlloyDB『t_wの輪郭』に攻撃が来た 2022年11月6日Grafanaのデータソースpgpool-II『pgpool-IIによるオンメモリクエリキャッシュの実装』『t_wの輪郭』のバックアップ『PostgreSQLで日本語全文検索 - LIKEとpg_bigmとPGroonga』PGroongapg_bigm『PostgreSQL 13.1 文書パートII. SQL言語 第12章 全文検索』『PostgreSQLでorder byとlimitが含まれたクエリのチューニングを行う』『CREATE INDEX』あれPGliteあれPG-Storm『ここだけはデフォルトから変更すべきPostgreSQLの設定（パフォーマンスチューニング）』PostgreSQLのデータ型MySQL、PostgreSQL、SQLiteで遊べるドン『PostgreSQL 9.0 High Performance』postgres_fdwFDWpg-gatewaypostgres.newpgAudit『Postgres: The Graph Database You Didn't Know You Had』『Guide to PostgreSQL Performance | Timescale』『PostgreSQL ++ for time series and events | Timescale』Timescale「If we want to get the cost information for a query by actually executing the query, we can use EXPLAIN ANALYZE」pg_stat_statements『PostgreSQL: Documentation: 16: 7.8. WITH Queries (Common Table Expressions)』「Seq Scan says that PostgreSQL is looping over every row in the database」pgx⁠Heap Only Tuple『第7回　UberエンジニアがブログでPostgreSQLにダメ出し、PostgreSQLコミッター石井達夫氏に反論を聞く | gihyo.jp』HOThot_standby_feedback『PostgreSQL Row Level Security (RLS) を使って顧客データ保護の安全性を高めている件 - Techouse Developers Blog』『When to Consider Postgres Partitioning | Timescale』psql『Postgres: CLIからのSQL実行はpsql -cを使う』『Sort Performance in PostgreSQL | CYBERTEC』pg_trgm『PostgreSQL でのネスト解除 | Delft スタック』Postgres Language ServerPostgreSQL 17GENERATE_SERIESpg_analytics『PostgreSQL: DynamoDB fdw 1.0.0 released』pg_duckdb『PostgreSQL Extension – DuckDB』

FDW

2024/11/10 1:39:00

HOT

2024/8/27 20:16:00

pgx

2024/8/24 20:29:00

あれ

2024/2/11 23:43:00

ブログのリプレイスできたああああああああ！！！！！

AWS Amplifyで動かしたら月額１万円かかって爆死したので、Vultrに戻した。

ついでにPostgreSQLからDuckDBに変えてみた。
PostgreSQLで300msかかってた処理が100msになった。やったぜ。

あれ

2023/9/25 2:01:00

Next.jsとGraphQLという現代兵器を使うから高速化出来るかな〜〜と思ったけど、むしろ遅くなってて残念。

むしろなんのチューニングもしてないPostgreSQLとExpress.jsでコレだけ速い現行版が謎。

現行版と比べてみると、無駄なクエリを投げてるな。コレを現行版に似せてやればよろしい。

現行版はキャッシュがなければ170msぐらいで飛んでくるので、そこまで行ければ嬉しい。

は？やべぇ。攻撃来てるかも。攻撃戦だ。

nginxのログみたら、SQLっぽいクエリで検索めっちゃされてる。
nginxでIPをはじくようにした。
IPをBANしたら、一旦攻撃は止んだ。

攻撃の対策どうしよう、fail2banのnginx-403-404は設定してるけど、サイト内検索を連打されるとこれ効かないんだよな。
WAF入れるのが手っ取り早いんだろうけど、勉強にならないし、お金かかるしで、もうちょっとほかの手段を検討したい。

①fail2banでSQLインジェクションを検知してBANする
②nginxで高頻度の検索を検知してBANする
あたりかしら

設定するのめんどくせー
ちゃんと設定できてるか検証するのもめんどくせー

①検証用の被攻撃サーバーと攻撃用サーバーを立ててそこで対策が有効かを検証
②本番環境に反映したら攻撃用サーバーから攻撃してみて、ちゃんと対策されているか検証

って感じで進めるとお行儀が良さそう。
めんどくせー
本番環境でペペぺって設定して、自宅のPCから実際攻撃して検証したい。そして自宅のPCから本番環境にアクセスできなくなるワナ。

こういうのって制定された手順とかあるんかな。ありそう。先に調べよう。

そもそもサイト内検索が大変重たいという問題も解決したい。
自作の検索機能がDBにインデックス張ってないわ、title LIKE %hogehoge% OR body_text LIKE %hogehoge%とかやって全文検索走るわでイケてない。
DBにちゃんとインデックス張ればいいんだろうけど、PostgreSQLの日本語のインデックスって、PGroonga入れたり、pg_bigm入れたりで、これまた検証サーバー立てないと怖いのよね。
めんどくせー。

  • Vultrでスナップショットを取る
    • 復旧できるか確認すること
      • 2022年5月5日復旧できた
  • Vultrのバックアップ機能を使う
    • バックアップ頻度を週次から日次に変更した
    • 復旧できるか確認すること
  • PostgreSQLのアーカイブを作成してダウンロード
    • →SSH/SCPを使わなくても良くしたい、というか手間を減らしたい

psql

2022/4/30 21:45:00

あれ

2022/4/16 20:02:00

文輪のデータベースはPostgresqlでもいいかもしれない。再帰クエリを使うことができる。