タグ付けされた質問 「security」

UFWを使用して保護したいVPSを実行し、ポート80への接続のみを許可します。ただし、リモートで管理できるようにするには、ポート22を開いたままにして、自宅から到達できるようにする必要があります。 特定のIPアドレスからのみポートへの接続を許可するようにUFWを構成できることを知っています。 ufw allow proto tcp from 123.123.123.123 to any port 22 しかし、私のIPアドレスは動的であるため、これはまだ解決策ではありません。 質問は次のとおりです。DynDNSを使用した動的DNS解決があるので、IPの代わりにドメインを使用してルールを作成することは可能ですか？ 私はすでにこれを試しました： ufw allow proto tcp from mydomain.dyndns.org to any port 22 しかし、私は得た ERROR: Bad source address

32 security  firewall  ufw  dynamic-dns 

ここ数週間、Ubuntuテストサーバーで奇妙な活動がありました。以下のスクリーンショットをhtopから確認してください。毎日、この奇妙なサービス（暗号通貨マイニングサービスのように見える）が実行されており、CPUを100％使用しています。 サーバーはsshキーを介してのみアクセス可能であり、パスワードによるログインは無効になっています。この名前のファイルを見つけようとしましたが、見つかりませんでした。 以下の問題で私を助けてください プロセスIDからプロセスの場所を見つける方法 これを完全に削除するにはどうすればよいですか？ これが私のサーバーにどのように侵入するか考えていますか？サーバーは、主にいくつかのDjangoデプロイメントのテストバージョンを実行します。

31 ubuntu  security  process 

Linuxを実行しているマシンに最近侵入した後、弱いパスワードを持つユーザーのホームフォルダーに実行可能ファイルが見つかりました。すべての損傷と思われるものをクリーンアップしましたが、確実に完全なワイプを準備しています。 非sudoまたは非特権ユーザーが実行できるマルウェアは何ですか？感染するための世界書き込み可能な許可でマークされたファイルを探しているだけですか？管理者以外のユーザーがほとんどのLinuxシステムで実行できる脅威は何ですか？この種のセキュリティ侵害が引き起こす現実の問題の例をいくつか提供できますか？

30 security  malware 

新しいユーザーを作成し、sudoアクセスを許可したいと思います。具体的には、sudo vimhttpd.conf を使用および編集してもらいます。私はこれをsudoersで書きました： user ALL=(ALL) /usr/bin/vim /etc/httpd/confs/httpd.conf しかし、これはリスクが高いと聞いた。なぜこれが問題なのですか？問題はどの程度深刻ですか？

30 security  vim  sudo 

で一時ファイルを作成するのが最善であると認識していますがmktemp、名前付きパイプはどうですか？ 私は物事を可能な限りPOSIX準拠にすることを好みますが、Linuxのみが許容されます。私が書いているように、バシズムを避けることは私の唯一の厳しい基準dashです。

30 linux  shell  security  pipe 

tarファイルを抽出して、抽出されたすべてのファイルが特定のプレフィックスディレクトリの下に配置されるようにします。tarファイルが外部ディレクトリに書き込もうとすると、抽出が失敗します。 ご想像のとおり、これは信頼できないtarファイルを安全に抽出できるようにするためです。 GNUでこれを行うにはどうすればよいtarですか？ 私は思いついた： tar --exclude='/*' --exclude='*/../*' --exclude='../*' -xvf untrusted_file.tar しかし、これが十分に妄想的であるかどうかはわかりません。

30 security  tar 

読み込みCVE-2009-4487の詳細を（ログファイル内のエスケープシーケンスの危険性についてである）私は少し驚いています。 CVE-2009-4487を引用するには： nginx 0.7.64は、印刷できない文字をサニタイズせずにログファイルにデータを書き込みます。これにより、リモート攻撃者は、ターミナルエミュレータのエスケープシーケンスを含むHTTPリクエストを介して、ウィンドウのタイトルを変更したり、任意のコマンドを実行したり、ファイルを上書きしたりできます。 明らかに、これは実際にはnginxのセキュリティホールではなく、ターミナルエミュレータにあります。 確かに、おそらくcat端末へのログファイルgrepの書き込みは偶然だけで起こりますが、ログファイルの書き込みは非常に一般的です。lessおそらくエスケープシーケンスをサニタイズしますが、どのシェルコマンドがエスケープシーケンスを変更しないかを知っている人は... 私はワニスの反応に同意する傾向があります： 一般に、端末応答エスケープの知恵は定期的に疑問視されていますが、主要な端末エミュレーションプログラムはいずれも、おそらく使用されていない1970年代の技術との互換性の見当違いの試みで、これらのシーケンスを破棄するのにふさわしいものではありませんでした。[..]ログファイルを書き込むすべてのプログラムを非難するのではなく、セキュリティの観点から、端末エミュレーションプログラムに愚かなことをやめさせ、この問題やその他のセキュリティ問題を一度修正する方がはるかに生産的です。そしてすべてのために。 したがって、私の質問： コマンドを実行したり、エスケープシーケンスを介してファイルを上書きしたりすることができなくなるように、xtermをセキュリティで保護するにはどうすればよいですか？ Xのどのターミナルエミュレーターがこの攻撃から保護されていますか？

29 security  xterm  escape-characters  terminal-emulator  special-characters 

Debianを搭載したラップトップを所有しており、このラップトップを販売する予定です。 Debianのインストールを販売前に消去してラップトップを個人データから完全にクリーンアップするだけで十分ですか？はいの場合、Debianをアンインストールできます（ラップトップにオペレーティングシステムが存在しないように）。

29 linux  security  data-destruction 

どの.rsa、.pem、およびその他のファイルが「ロード」または「アクティブ」であるssh-addかを確認するにはどうすればよいですか？私はこの恐怖を感じました： $ scp -i /home/dotancohen/.ssh/dotancohen.pem someUser@1.2.3.4:~/files.tgz . Warning: Identity file /home/dotancohen/.ssh/dotancohen.pem not accessible: No such file or directory. files.tgz 100% 89MB 1.5MB/s 00:59 $ scp someUser@1.2.3.4:~/all_git.tgz . files.tgz 100% 89MB 1.7MB/s 00:54 サーバーが実際に.pemキーを必要とすることを確認した後、私はそれについて知らずにロードされている他のキーを知りたいです！

28 ssh  security 

特定の範囲のIPアドレスがサーバーに問題を引き起こしていることを知ってい172.64.*.*ますが、Amazon EC2インスタンスへのアクセスをブロックする最良の方法は何ですか？セキュリティグループを使用してこれを行う方法はありますか、それともサーバー自体のファイアウォールで行う方が良いですか？

27 security  firewall  ip  amazon-ec2 

どうやら、実行中： perl -n -e 'some perl code' * または find . ... -exec perl -n -e '...' {} + （の-p代わりに同じ-n） または perl -e 'some code using <>' * このサイトに投稿されたワンライナーでよく見られるものは、セキュリティに影響します。どうしたんだ？それを避ける方法は？

27 security  perl  filenames  options 

コマンドをブロックする方法mkdir、特定のユーザー向けに言ってみましょうか？ 読み取り専用関数を作成し、ユーザープロファイルに保存したところ ~/.bashrc /bin/mkdir() { echo "mkdir command not allow for you" } mkdir() { echo "mkdir command not allow for you" } ./mkdir() { echo "mkdir command not allow for you" } readonly -f /bin/mkdir readonly -f mkdir readonly -f ./mkdir テスト： rahul@ubuntu:~$ cd /bin/ rahul@ubuntu:/bin$ ./mkdir /home/rahul/ggg mkdir …

27 linux  security  account-restrictions  restricted-shell 

/var/log/auth.logパブリックWebサーバーの1つでの監査中に、これを見つけました。 Jan 10 03:38:11 Bucksnort sshd[3571]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=61.19.255.53 user=bin Jan 10 03:38:13 Bucksnort sshd[3571]: Failed password for bin from 61.19.255.53 port 50647 ssh2 一見したところ、これはsshランダムなハッカーからの典型的なログインスパムのように見えます。しかし、よく見ると何か他のものに気づきました。ほとんどの失敗した/var/log/auth.logエントリはinvalid user、次のようにそれらで言います： Jan 9 10:45:23 Bucksnort sshd[3006]: Failed password for invalid user sales from 123.212.43.5 port 10552 ssh2 以下のためにその失敗したログインメッセージに関する不穏な事はbin、それがあるということである有効なユーザで/etc/passwdあっても持っているログインシェルは： [mpenning@Bucksnort …

27 linux  debian  security 

NFSを使用して仕事からホームサーバーに接続したい。sshfsを試しましたが、NFSほど信頼性が低いと言う人もいます。 sshfsトラフィックが暗号化されていることは知っています。しかし、NFSはどうでしょうか？誰かが私のトラフィックを盗聴し、コピーしているファイルを表示できますか？ LANでNFSv4を使用していますが、うまく機能します。

27 security  nfs 

2017年5月1日付のIntelセキュリティセンターの投稿によると、Intelプロセッサに重大な脆弱性があり、攻撃者がAMT、ISM、およびSBTを使用して特権（特権の昇格）を取得する可能性があります。 AMTはコンピューターのネットワークハードウェアに直接アクセスするため、このハードウェアの脆弱性により、攻撃者は任意のシステムにアクセスできます。 Intel®Active Management Technology（AMT）、Intel®Standard Manageability（ISM）、およびIntel®Small Business Technologyバージョンファームウェアバージョン6.x、7.x、8.x 9.x、10に特権の昇格の脆弱性があります.x、11.0、11.5、および11.6。これらは、特権のない攻撃者がこれらの製品が提供する管理機能を制御できるようにします。この脆弱性は、IntelベースのコンシューマPCには存在しません。 インテルは、Windows 7および10で使用可能な検出ツールをリリースしました。dmidecode -t 4インテルのWebサイトで情報を検索し、使用していIntel® Active Management Technology (Intel® AMT) 8.0ます。 影響を受ける製品： この問題は、Intel®Active Management Technology、Intel®Small Business Technology、およびIntelのIntel管理容易性ファームウェアバージョン6.x、7.x、8.x 9.x、10.x、11.0、11.5、および11.6で確認されています®標準の管理性。6より前または11.6より後のバージョンは影響を受けません。 説明： 特権のないローカルの攻撃者は、Intelの管理性SKU（Intel®Active Management Technology（AMT）、Intel®Standard Manageability（ISM）、およびIntel®Small Business Technology（SBT））で非特権ネットワークまたはローカルシステムの特権を取得する管理機能をプロビジョニングできます LinuxシステムでIntelの特権昇格の脆弱性を簡単に検出して軽減するにはどうすればよいですか？

26 linux  security  hardware  x86  vulnerability