প্রশ্ন শত শত ব্রেক-ইন প্রচেষ্টা প্রতিদিন স্বাভাবিক?


আমি শুধু আমার সার্ভার এর চেক /var/log/auth.log এবং আমি পেয়েছি যে 500 টিরও বেশি ব্যর্থ পাসওয়ার্ড / বিরতি-ইন প্রচেষ্টা প্রচেষ্টা প্রতিদিন! আমার সাইট ছোট, এবং তার URL টি অস্পষ্ট। এটা কি স্বাভাবিক? আমি কোন ব্যবস্থা গ্রহণ করা উচিত?


196
2018-03-08 11:26


উত্স


আমরা সব অপ্রয়োজনীয় বহিরাগত বন্দর বন্ধ না হওয়া পর্যন্ত, আমি মনে করি না আমরা অনেক হ্যাক প্রচেষ্টা পেয়েছি, কিন্তু একদিন এটি এত খারাপ ছিল যে আমাদের দুটি ভিন্ন দেশ থেকে হ্যাক করা হচ্ছে - একই সময়ে! তাই হ্যাঁ, ব্রেক-ইন প্রচেষ্টা 100 এর পুরোপুরি স্বাভাবিক। - Django Reinhardt
আমাদের সার্ভার রয়েছে যা প্রতি 16 সেকেন্ডে একবার একটি নতুন আক্রমণ "ক্রম" উপভোগ করে। একটি একক ক্রম সাধারণত বিভিন্ন পোর্ট জুড়ে প্রায় 100 প্রচেষ্টা একটি ব্যাচ হয়। শুধু একটি দিন kicks জন্য আমি আমাদের ফায়ারওয়াল বাইরে একটি unpatched সার্ভার চালু; এটি পাওয়ার জন্য এটি চালানোর সময় 10 মিনিটেরও কম সময় নেয়। পয়েন্ট ইন্টারনেট সত্যিই একটি জঙ্গল হয়; খাওয়া না করার চেষ্টা করুন। - NotMe
আমি দেখতে পাচ্ছি ভুল প্রশ্নে আমি আমার প্রশ্ন পোস্ট করেছি: superuser.com/questions/200896/... - Justin C
যখন আমি অন্যদের সাথে একমত, সাধারণ পোর্টগুলির জন্য এটি স্বাভাবিক (80, 443) আমি আমার এসএসএইচ পোর্টের বিরুদ্ধে 22২ থেকে ডিফল্ট পোর্ট পরিবর্তন করে উদাহরণস্বরূপ 60২২ এর মত অস্পষ্ট কিছু করে এই প্রচেষ্টাগুলি কার্যকরীভাবে বাদ দিয়েছি। শুধু যে, একা, প্রায় 99% যে ধরনের হামলা নির্মূল। - Kilo
আপনি যদি আপনার এসএসএইচ পোর্ট পরিবর্তন করতে যাচ্ছেন তবে এটি পোর্ট 1024 এর নিচে রাখার জন্য নিরাপত্তার কারণ রয়েছে (শুধুমাত্র রুটগুলি পোর্টগুলি খুলতে পারে <1024, তাই এটি আপনাকে অন্যান্য ব্যবহারকারীদের SSH হাইজ্যাক করার থেকে রক্ষা করে)। - Brendan Long


উত্তর:


আজকের ইন্টারনেটে এই দুঃখজনকভাবে স্বাভাবিক। সম্পূর্ণ আইপি নেটওয়ার্কে পাওয়া প্রতিটি সার্ভারে লগইন করার চেষ্টা করে এমন বোটনেটগুলি রয়েছে। সাধারণত, তারা সুপরিচিত অ্যাকাউন্টগুলিতে সাধারণ অভিধান আক্রমণ ব্যবহার করে (যেমন রুট বা নির্দিষ্ট অ্যাপ্লিকেশন অ্যাকাউন্ট)।

আক্রমণ লক্ষ্যগুলি Google বা DNS এন্ট্রিগুলির মাধ্যমে পাওয়া যায় না, তবে আক্রমণকারীরা কেবল একটি নির্দিষ্ট সাবনেট (যেমন পরিচিত রুট-সার্ভার হোস্টিং কোম্পানিগুলির মধ্যে) প্রতিটি আইপি ঠিকানা চেষ্টা করে। সুতরাং আপনার URL (সুতরাং DNS এন্ট্রি) বরং অস্পষ্ট যে কোন ব্যাপার না।

এটি কেন এত গুরুত্বপূর্ণ:

  • এসএসএইচ রুট লগইন নিষিদ্ধ (কিভাবে)
  • সর্বত্র শক্তিশালী পাসওয়ার্ড ব্যবহার করুন (আপনার ওয়েব অ্যাপ্লিকেশনগুলিতেও)
  • SSH এর জন্য, যদি সম্ভব হয় তাহলে সর্বজনীন-কী প্রমাণীকরণ ব্যবহার করুন এবং পাসওয়ার্ড-অট সম্পূর্ণরূপে অক্ষম করুন (কিভাবে)

উপরন্তু, আপনি ইনস্টল করতে পারেন fail2ban যা authlog কে স্ক্যান করবে এবং যদি এটি একটি আইপি থেকে ব্যর্থ লগইন প্রচেষ্টাগুলির একটি নির্দিষ্ট পরিমাণ খুঁজে পায় তবে এটি আইপি যোগ করতে এগিয়ে যাবে /etc/hosts.deny অথবা কয়েক মিনিটের জন্য আক্রমণকারী লক করার জন্য iptables / netfilter।

এসএসএইচ আক্রমণের পাশাপাশি, আপনার ওয়েব সার্ভারটি দুর্বল ওয়েব-অ্যাপ্লিকেশনগুলির জন্য স্ক্যান করা সাধারণ হয়ে উঠছে (কিছু ব্লগিং অ্যাপ্লিকেশন, সিএমএস, পিপিএমডামিন ইত্যাদি)। সুতরাং যারা আপ টু ডেট রাখা এবং নিরাপদে খুব কনফিগার করা নিশ্চিত করুন!


207
2018-03-08 11:35



Fail2ban এর মতো অ্যাপ্লিকেশনগুলি 'সাময়িকভাবে' সকালের সময়ে আপনার সার্ভারকে হিট করতে বাধা দেওয়ার জন্য অনেকগুলি 'সহায়তা' করতে পারে :-) আমার 24 ঘন্টা ধরে ভুল প্রচেষ্টা 3 নিষিদ্ধ করার জন্য আমি সেট আপ করেছি। - emtunc
এবং ssh এর পোর্ট 22 থেকে 222 সরানো। এটা বেশ ভাল কাজ করে। - Tom O'Connor
+1, পাবলিক-কী প্রমাণীকরণ শুধুমাত্র :) - 0xC0000022L
@ STATUS_ACCESS_DENIED: কর্ম fail2ban সঞ্চালনের জন্য শেল কমান্ডের তালিকাগুলির মধ্যে রয়েছে। তাই এটি সত্যিই কোন নমনীয় কনফিগারেশন সঙ্গে কাজ সঠিকভাবে নমনীয় এবং সহজ। সেরা রেফারেন্স এটি ডাউনলোড এবং তাকান হয় action.d/iptables.conf। - mattdm
এই ধরনের আক্রমণকারীদের অবরোধ করা সময় অপচয়। আপনি যদি রুট লগইন নিষ্ক্রিয় করেন, তবে এমন একটি ভাল সুযোগ রয়েছে যে কেউ নিজের সঠিক লগইন নামটি অনুমান করবে না, একা পাসওয়ার্ড দিন। এসএসএইচ নিজেই ইতিমধ্যে পাসওয়ার্ড অনুরোধ সীমাবদ্ধ করে দিচ্ছে, তাই যদি তারা আপনার ব্যবহারকারীর নাম জানেন (র্যান্ডম বটগুলি হবে না), যদি আপনার কাছে একটি উপযুক্ত পাসওয়ার্ড থাকে তবে তারা এটি অনুমান করবে না। - Brendan Long


কয়েক 100 ঠিক আছে জরিমানা ... গত মাসে আমি দেখেছি আমার সার্ভারগুলির একটিতে 40 কে ব্যর্থ হয়েছে। আমি তাদের plotting সমস্যা trough গিয়েছিলাম: মানচিত্র

একবার আমি এসএসএস পোর্ট পরিবর্তন এবং পোর্ট নকিং বাস্তবায়িত, সংখ্যা 0 :-)


58
2018-03-08 11:36



চমৎকার মানচিত্র। আমি কিভাবে এটা করতে ভালোবাসি! - jftuga
@jftuga আমি প্রথম লগ থেকে সব আইপি পেয়েছিলাম। grep 'Failed password' /var/log/secure* | grep sshd | grep -o '[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}\.[0-9]\{1,3\}' | sort | uniq(যদি আপনি সদৃশ অনুমতি দিতে চান তাহলে শেষে | uniq মুছে ফেলুন)। তারপর আপনি তাদের একটি CSV এ রাখতে এবং zeemaps.com এ আপলোড করতে পারেন। আমি মানচিত্রের পরে আরও ভাল মানচিত্র দেখেছি, যেখানে তারা মানচিত্রটি রঙ করতে গণনাটি ব্যবহার করবে (প্রতি কাউন্টি চেষ্টা করার জন্য সবুজ থেকে লাল) কিন্তু আমি জেটটিকে খুঁজে পাইনি যে এক আউট - Bart De Vos
আপনি 'পোর্ট Knocking বাস্তবায়িত' মানে কি? এই অ্যাপ্লিকেশনটি কি আমি APT-get মাধ্যমে ইনস্টল করতে পারি? 0 ড্রপ করা সংখ্যা সুন্দর শব্দ
Obscurity মাধ্যমে নিরাপত্তা একটি খারাপ মোড়ানো পায়। এটি যতক্ষণ পর্যন্ত পুরোপুরি জরিমানা অংশ সমগ্র কৌশল পরিবর্তে সামগ্রিক কৌশল। সব পরে, একটি অস্পষ্ট স্ট্রিং ছাড়া অন্য একটি পাসওয়ার্ড কি? - Joel Coel
@ জোয়েল কোয়েল, এটি একটি গোপন স্ট্রিং, অস্পষ্টতা সমস্যা মাধ্যমে সবচেয়ে নিরাপত্তা বিরোধিতা - একটি অস্পষ্ট, কিন্তু অপরিহার্য গোপন প্রক্রিয়া। - tobyodavies


আমি কেবল একটি জনক কী প্রমাণীকরণ এবং রুট লগইনগুলিকে অনুমতি দেওয়ার অনুমতি ছাড়াও একটি "টারপিট" ব্যবহার করি।

মধ্যে netfilter সেখানে একটি recent মডিউল, যা আপনি ব্যবহার করতে পারেন (INPUT শৃঙ্খল):

iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --set --name tarpit --rsource
iptables -A INPUT -i if0 -p tcp --dport 22 -m state --state NEW -m recent --update --seconds 180 --hitcount 6 --name tarpit --rsource -j DROP
iptables -A INPUT -i if0 -p tcp --dport 22 -j ACCEPT

যে কি, পোর্ট 22 সংযোগ প্রতিটি প্রচেষ্টা তালিকাভুক্ত করা হয় recent আইপি এবং কিছু অন্যান্য স্টাফ নামের সাথে মডিউল "tarpit" (যদি আপনি আগ্রহী হন তবে দেখুন /proc/net/xt_recent/tarpit)। স্পষ্টত আপনি অন্যান্য নাম ব্যবহার করতে পারেন।

তালিকা বা তালিকাভুক্ত আইপি ব্যবহার করুন:

echo "+123.123.123.123" > /proc/net/xt_recent/tarpit
echo "-123.123.123.123" > /proc/net/xt_recent/tarpit

এই রেট-300 সেকেন্ডে 5 টি প্রচেষ্টা সীমাবদ্ধ করে। অনুগ্রহ করে মনে রাখবেন যে একটি বিদ্যমান সংযোগের ব্যবহারকারীরা সেই সীমা দ্বারা বিরক্ত হয় না, কারণ তাদের ইতিমধ্যে একটি প্রতিষ্ঠিত সংযোগ রয়েছে এবং আরও তৈরি করার অনুমতি দেওয়া হয়েছে (এমনকি হার সীমা ছাড়াই)।

আপনার পছন্দের নিয়মগুলি সামঞ্জস্য করুন তবে নিশ্চিত করুন যে সেগুলি যাতে যোগ করা হবে (যেমন, যখন যোগ করা হয় তখন এই ক্রম অনুসারে সেগুলি ব্যবহার করুন, বিপরীত ক্রম অনুসারে ঢোকানো)।

এই অত্যন্ত গোলমাল কাটা। এটি পোর্ট পরিবর্তন করার অনুভূত নিরাপত্তার বিপরীতে প্রকৃত নিরাপত্তা (বক্র-জোরদারের বিরুদ্ধে) সরবরাহ করে। যাইহোক, আমি এখনও আপনার পরিবেশে সম্ভব হলে পোর্ট পরিবর্তন সুপারিশ চাই। এটি গোলমাল স্তরের অনেকটা কাটাবে ...

আপনি এখনও fail2ban সঙ্গে এটি একত্রিত করতে পারেন, যদিও আমি এটি ছাড়া এবং শুধুমাত্র উপরে নিয়ম ঠিক সূক্ষ্ম চলমান হয়েছে।

সম্পাদনা করুন:

এটি করা আপনার স্বতঃস্ফূর্ত করা সম্ভব, তাই আপনি এমন কিছু যোগ করতে পারেন যা আপনাকে একটি নির্দিষ্ট পোর্টে ডক করে আপনাকে নিষিদ্ধ করতে দেয়:

iptables -A INPUT -i if0 -p tcp --dport <knockport> -m state --state NEW -m recent --name tarpit --remove

29
2018-03-08 14:24



আমি এটি ব্যবহার করি এবং মাঝে মাঝে নিজেকে ব্লক করতে পরিচালনা করি, তাই অন্য একটি পোর্ট সেট করতে চাইলে আপনি আপনার নিষেধাজ্ঞাটি সাফ করতে "হাঁটতে" পারেন। - benlumley
@ বেনলুমলি: ভাল পয়েন্ট। পোর্ট ডকিং ডিফল্ট পোর্ট পরিবর্তন করতেও একই রকম হতে পারে - এমনকি উভয়ই সমন্বয়ে ... - 0xC0000022L
@ বেনলুমলি: আপনার মন্তব্যটি দেখেছেন (এখন স্যাম দ্বারা সরানো হয়েছে)। উত্তরটি সম্পাদিত / উন্নত হয়ে গেলে আমি একেবারে কিছু মনে করি না;) - 0xC0000022L


আপনি বাস্তবায়ন করতে পারে fail2ban, বা আপনার আইপি SSH লকিং মত অনুরূপ পদ্ধতি। দুঃখজনকভাবে বটসফোর্স অ্যাক্সেস করার সময় সব সময় প্রবেশ করুন যাতে এটি বেশ স্বাভাবিক, আপনাকে নিশ্চিত করতে হবে আপনার একটি ভাল পাসওয়ার্ড আছে।


15
2018-03-08 11:32



আপনি SSH ব্যবহার করছেন, পাবলিক কী প্রমাণীকরণ বিবেচনা করুন। এটি পাসওয়ার্ড প্রমাণীকরণের চেয়ে আরও বেশি নিরাপদ। - Piskvor


হাঁ। আজকাল বেশ স্বাভাবিক।

সম্ভব হলে প্রশাসনিক উদ্দেশ্যে শুধুমাত্র পাবলিক কী প্রমাণীকরণ ব্যবহার করুন। ওয়ার্কস্টেশনে একটি ব্যক্তিগত কী জেনারেট করুন:

$ ssh-keygen -t dsa

বিষয়বস্তু কপি পেস্ট করুন ~ / .Ssh / id_dsa.pub আপনি সার্ভারের জন্য ~ / .Ssh / authorized_keys -র (এবং /root/.ssh/authorized_keys, আপনার সরাসরি রুট লগইন প্রয়োজন)।

আপনার সার্ভার কনফিগার করুন জন্য / etc / SSH / sshd_config শুধুমাত্র পাবলিক কী প্রমাণীকরণ গ্রহণ করতে:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin without-password

আপনি যদি অনেক সার্ভার আছে, আপনি ব্যবহার করতে পারেন পুতুল পাবলিক কী এবং তাদের কনফিগারেশন চালানোর জন্য।

দেখুন Denyhosts এবং fail2ban পুনরাবৃত্তি SSH লগইন প্রচেষ্টা এবং দেখুন হ্রেষাধ্বনি যদি আপনি সম্পূর্ণ আইডিএস / আইপিএস প্রয়োজন।


12
2018-03-09 23:32



আমি আপনার সার্ভারে শেল অ্যাক্সেসের জন্য SSH এ সর্বজনীন কী প্রমাণীকরণ ব্যবহার করার সুপারিশ করব না। যদি আপনার ওয়ার্কস্টেশনটি আপোস করা হয় বা এমনকি আরওও চুরি হয়ে যায় তবে আপনার কাছে এখন কোনও পাসওয়ার্ডের প্রয়োজন ছাড়াই আপনার সার্ভারগুলিতে খোলা অ্যাক্সেস রয়েছে। পাবলিক কী প্রমাণীকরণ এমন পরিস্থিতিগুলির জন্য আরো যেখানে আপনি কোনও স্ক্রিপ্ট বা প্রোগ্রামের মতো কোনও পাসওয়ার্ডের প্রয়োজন ছাড়াই অন্য সিস্টেমে এসএসএইচ অ্যাক্সেস পেতে সক্ষম হওয়ার জন্য আরও কিছু প্রয়োজন, তাই আপনাকে আপনার স্ক্রিপ্ট / প্রোগ্রামে প্লেইন-পাঠ্য পাসওয়ার্ডগুলি এম্বেড করতে হবে না। - Registered User
@ ডিলিট অ্যাকাউন্ট: আপনি এসএসএইচ ব্যক্তিগত কী জন্য একটি পাসফ্রেজ সেট করতে পারেন। - Phil Cohen
"নিবন্ধিত ব্যবহারকারীর" মন্তব্য বিভ্রান্ত হয়। শুধু ব্যাখ্যা করতে: সর্বদা আপনার ব্যক্তিগত কীতে একটি ভাল পাসওয়ার্ড সেট করুন এবং কোনও সার্ভারে ব্যক্তিগত কী সংরক্ষণ করবেন না। আপনার নিজস্ব ওয়ার্কস্টেশনে ব্যক্তিগত কী রাখুন। একবার আপনি ssh-এজেন্ট প্রোগ্রামে কী যোগ করেন এবং আপনার পাসওয়ার্ডটি প্রবেশ করার পরে, আপনার পাসওয়ার্ডটি পুনরায় প্রবেশ না করেই আপনি যে সমস্ত সিস্টেমে পাবলিক কী ইনস্টল করেছেন তাতে লগ ইন করতে পারেন। আপনার ssh ক্লায়েন্টে এজেন্ট-ফরওয়ার্ডিং সক্ষম করুন যাতে আপনি সার্ভার থেকে সার্ভারে লগ ইন করতে পারেন। আপনার ব্যক্তিগত কী চুরি করা হচ্ছে খারাপ, কিন্তু এটি একটি শালীন পাসওয়ার্ড দিয়ে এটি চুরি হওয়া পাসওয়ার্ড হিসাবে খারাপ নয়। - Martijn Heemels
ঠিক আছে, অ্যাডমিনের ব্যক্তিগত কীগুলি এনক্রিপ্ট করাও মনে করবেন না। - yarek


ব্যবহার http://denyhosts.sourceforge.net/

এবং হ্যাঁ, আপনি পাবলিক-কী প্রমাণীকরণ ব্যবহার করতে এবং পাসওয়ার্ড auth অক্ষম করা উচিত।


8
2018-03-09 09:37



পাসওয়ার্ড auth নিষ্ক্রিয় করা সবসময় একটি কার্যকর সমাধান নয়। - Publiccert


প্রচেষ্টাগুলি মেকানিকাইজড, তাই সংখ্যা ঠিক বলে মনে হয় (হ্যাঁ তারা কিছু সাইটের তুলনায় উচ্চ এবং অন্যদের তুলনায় কম)। আপনি সাধারণত আপনার কাছে যে পদক্ষেপগুলি গ্রহণ করেছেন তা গ্রহণ করা উচিত: আপনি আপনার সাইটকে আক্রমণের লক্ষ্য হিসাবে প্রতিদিন বিবেচনা করেন, এমনকি যখন আপনি কোনও আক্রমণ সনাক্ত করেন না; একটি আক্রমণ সনাক্ত না, এটি বিদ্যমান নেই মানে


6
2018-03-08 11:33





আমি কেবলমাত্র 500 পেয়েছি বলতে চাই।

পূর্ববর্তী নিয়োগকর্তা, কম্পিউটার নিরাপত্তা গবেষকগুলির মধ্যে একটি ব্রেক-ইনের ধ্রুবক স্ট্রিম নামক "ইন্টারনেট সমতুল্য" মহাজাগতিক শব্দ"তিনি ইন্টারনেটে সিস্টেমগুলির জন্য অনুসন্ধান করা দূষিত ট্র্যাফিকের একটি স্বাভাবিক, ক্রমাগত প্রবাহ হিসাবে বর্ণনা করেছেন এবং স্বয়ংক্রিয়ভাবে সিস্টেম হাইজ্যাক করার চেষ্টা করার জন্য স্ক্রিপ্টগুলিকে কাজে লাগান। বোট-নেট এবং অন্যান্য দূষিত সিস্টেমগুলি সর্বদা অনিয়মিত সিস্টেমগুলির জন্য ইন্টারনেট স্ক্যান এবং পুনরায় স্ক্যান করবে। অনেক মত SETI।


6
2018-03-08 17:06