কম সংখ্যক SYN_RECV সংযোগ থাকা সত্ত্বেও লগতে "সম্ভাব্য এসওয়াইএন বন্যা"

30

সম্প্রতি আমাদের একটি অ্যাপাচি সার্ভার রয়েছে যা এসওয়াইএন বন্যার কারণে খুব ধীরে ধীরে সাড়া দিচ্ছিল। এর জন্য কাজটি ছিল tcp_syncookies ( net.ipv4.tcp_syncookies=1 in /etc/sysctl.conf) সক্ষম করা ।

আপনি যদি আরও পটভূমি চান তবে আমি এই সম্পর্কে এখানে একটি প্রশ্ন পোস্ট করেছি ।

সিঙ্কুকি সক্ষম করার পরে আমরা প্রায় 60 সেকেন্ডে নীচের বার্তাটি / ভার / লগ / বার্তাগুলিতে দেখতে শুরু করি:

[84440.731929] possible SYN flooding on port 80. Sending cookies.

Vinko Vrsalovic আমাকে অবহিত যে, এই উপায়ে SYN ব্যাকলগ পূর্ণ হচ্ছে, তাই আমি 4096. করার tcp_max_syn_backlog উত্থাপিত কিছু পয়েন্ট (5 ডিফল্ট থেকে নেমে) আমিও 3 tcp_synack_retries নত এ জারি করে sysctl -w net.ipv4.tcp_synack_retries=3। এটি করার পরে, বার্তাটি প্রায় 60 এবং 180 সেকেন্ডের মধ্যে ব্যবধানের ব্যবধান সহ ফ্রিকোয়েন্সিটি হ্রাস পেয়েছিল।

পরবর্তী আমি জারি করলাম sysctl -w net.ipv4.tcp_max_syn_backlog=65536, তবে লগের মধ্যে এখনও বার্তাটি পাচ্ছি।

এই সমস্তটি জুড়ে আমি SYN_RECV রাজ্যে সংযোগের সংখ্যাটি দেখছি (চালিয়ে watch --interval=5 'netstat -tuna |grep "SYN_RECV"|wc -l') এবং এটি কখনই প্রায় 240 এর চেয়ে বেশি যায় না, ব্যাকলগের আকারের চেয়ে অনেক কম। তবুও আমার কাছে একটি রেড হ্যাট সার্ভার রয়েছে যা প্রায় 512 ঘোরাফেরা করে (এই সার্ভারটির সীমা 1024 এর ডিফল্ট)।

অন্য কোনও টিসিপি সেটিংস আছে যা ব্যাকলোগের আকার সীমাবদ্ধ করবে বা আমি ভুল গাছটি ছাঁটাই করছি? SYN_RECV সংযোগের সংখ্যাটি কি ব্যাকলগের netstat -tunaআকারের সাথে সম্পর্কিত হতে হবে?

হালনাগাদ

সর্বোত্তম হিসাবে আমি বলতে পারি যে আমি এখানে বৈধ সংযোগগুলি নিয়ে কাজ করছি, netstat -tuna|wc -lপ্রায় 5000 এর কাছাকাছি ঘুরে বেড়াচ্ছি research আমি আজ এটি নিয়ে গবেষণা করে চলেছি এবং গত পোস্ট.এফএম কর্মচারীর কাছ থেকে এই পোস্টটি পেয়েছি যা বরং দরকারী।

আমি এটিও আবিষ্কার করেছি যে সিঙ্কুকি সক্ষম করা থাকলে tcp_max_syn_backlog এর কোনও প্রভাব নেই ( এই লিঙ্ক অনুসারে )

সুতরাং পরবর্তী পদক্ষেপ হিসাবে আমি নিম্নলিখিতটি সিস্টেস্টল কনফনে সেট করে রেখেছি:

net.ipv4.tcp_syn_retries = 3
        # default=5
net.ipv4.tcp_synack_retries = 3
        # default=5
net.ipv4.tcp_max_syn_backlog = 65536
        # default=1024
net.core.wmem_max = 8388608
        # default=124928
net.core.rmem_max = 8388608
        # default=131071
net.core.somaxconn = 512
        # default = 128
net.core.optmem_max = 81920
        # default = 20480

আমি তখন আমার প্রতিক্রিয়া সময় পরীক্ষা সেটআপ করেছি, দৌড়েছি sysctl -pএবং এর মাধ্যমে সিঙ্কুকিকে অক্ষম করেছি sysctl -w net.ipv4.tcp_syncookies=0।

এটি করার পরে SYN_RECV রাজ্যে সংযোগের সংখ্যা এখনও 220-250 এর কাছাকাছি থেকে যায় তবে সংযোগগুলি আবার বিলম্ব হতে শুরু করে। একবার আমি এই বিলম্বগুলি লক্ষ্য করেছিলাম আমি পুনরায় সক্ষম সিঙ্ককিগুলি এবং বিলম্বগুলি বন্ধ হয়ে যায়।

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

তবে সাইন ব্যাকলগটি কেবলমাত্র SYN_RECV অবস্থায় 250 ডলার সংযোগের সাথে পূর্ণ বলে মনে হচ্ছে না! এটি কি সম্ভব যে এসওয়াইএন বন্যার বার্তাটি একটি লাল রঙের উত্তোলক এবং এটি সিএন_ব্লগ ছাড়াও অন্য কিছু যা পূর্ণ করছে?

কারও কাছে যদি অন্য কোনও টিউনিং বিকল্প থাকে তবে আমি এখনও চেষ্টা করি নি আমি তাদের চেষ্টা করে দেখতে আরও বেশি খুশি হব, তবে সিন্ন_ব্লগ সেটিংটি কোনও কারণে সঠিকভাবে প্রয়োগ হচ্ছে না কিনা তা নিয়ে আমি ভাবতে শুরু করি।

— অ্যালেক্স ফোর্বস
সূত্র

সম্পর্কিত সার্ভারফলট.কোশনস

— ভিঙ্কো ভার্সালোভিক

27

সুতরাং, এটি একটি ঝরঝরে প্রশ্ন।

প্রাথমিকভাবে, আমি অবাক হয়ে গিয়েছিলাম যে আপনি SYN_RECV রাজ্যে কোনও সংযোগ দেখে SYN কুকিজ সক্ষম করেছেন। এসওয়াইএন কুকিজের সৌন্দর্য হ'ল আপনি ক্রিপ্টোগ্রাফি ব্যবহার করে সার্ভার হিসাবে টিসিপি ত্রি-মুখী হ্যান্ডশেকটিতে রাজ্যহীনভাবে অংশ নিতে পারেন, তাই আমি সার্ভারকে আশা করব যে অর্ধ-খোলা সংযোগগুলিকে আদৌ উপস্থাপন করবে না কারণ এটি একই অবস্থা হবে না রাখা হচ্ছে না।

প্রকৃতপক্ষে উত্সটিতে একটি দ্রুত উঁকি দেওয়া (tcp_ipv4.c) কার্নেল কীভাবে এসওয়াইএন কুকিজ প্রয়োগ করে সে সম্পর্কে আকর্ষণীয় তথ্য দেখায়। মূলত, এগুলি চালু করা সত্ত্বেও, কার্নেলটি স্বাভাবিকভাবে তার আচরণ করে যতক্ষণ না তার মুলতুবি সংযোগগুলির সারি পূর্ণ না হয় until এটি আপনার বিদ্যমান সংযোগগুলির তালিকা SYN_RECV রাজ্যে ব্যাখ্যা করে।

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

অন্য একটি উপায় রাখুন, আপনি যদি এসওয়াইএন কুকিজ বন্ধ করেন তবে বার্তাটি চলে যাবে। আপনি কেবল এসইএনএন প্লাবিত না হয়ে থাকলে এটি কেবল আপনার জন্য কাজ করবে।

আপনার করা অন্যান্য কিছু কাজের জন্য সম্বোধন করতে:

net.ipv4.tcp_synack_retries:
- এটি বাড়ানোর ফলে যারা ছদ্মবেশী হয়ে আসছে আগত সংযোগগুলির জন্য বা সার্ভার-সাইড স্টেটের পরিবর্তে কোনও এসওয়াইএন কুকি গ্রহণ করে তাদের জন্য (তাদের জন্য কোনও চেষ্টাও নেই) কোনও ইতিবাচক প্রভাব ফেলবে না।
- আগত স্পোফযুক্ত সংযোগগুলির জন্য, এটি বাড়ানো আপনার কোনও নকল ঠিকানায় পাঠানো প্যাকেটের সংখ্যা এবং সম্ভবত স্পুফড ঠিকানাটি আপনার সংযোগ টেবিলে থাকা সময়ের পরিমাণ বাড়িয়ে তোলে (এটি উল্লেখযোগ্য নেতিবাচক প্রভাব হতে পারে)।
- স্বাভাবিক লোড / আগত সংযোগের সংখ্যার অধীনে, এটি তত বেশি, প্যাকেটগুলি ড্রপ করে এমন লিঙ্কগুলির উপর আপনি দ্রুত / সাফল্যের সাথে সংযোগগুলি সম্পন্ন করার সম্ভাবনা তত বেশি। এটি বাড়ানোর জন্য হ্রাসকারী রিটার্ন রয়েছে।
net.ipv4.tcp_syn_retries: এটি পরিবর্তন আউটবাউন্ড সংযোগগুলির উপর কোনও প্রভাব ফেলতে পারে না (এটি কেবল আউটবাউন্ড সংযোগগুলিকেই প্রভাবিত করে)

আপনি যে অন্যান্য ভেরিয়েবলগুলি উল্লেখ করেছেন আমি গবেষণা করেছি নি, তবে আমি সন্দেহ করি যে আপনার প্রশ্নের উত্তর এখানে ঠিক আছে।

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

— Slartibartfast
সূত্র

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

— অ্যালেক্স ফোর্বস

একটি নেটওয়ার্ক ইঞ্জিনিয়ারকে একবার দেখার জন্য সম্মতি জানানো - ভাল পরামর্শ কিন্তু আমরা এই ডাটাসেন্ট্রে থেকে দূরে সরে যাচ্ছি, সুতরাং আমরা অন্য কোথাও অনলাইনে বেশ কয়েকটি নতুন সার্ভার আনার সময় এটি সার্থক নয়। আমি মনে করি এটি একটি নেটওয়ার্ক সমস্যা হিসাবে আপনার সম্পর্কে সঠিক হতে পারে - সম্ভবত লোড ব্যালেন্সার বা ফায়ারওয়াল নিয়ে কোনও সমস্যা। আপনার অন্তর্দৃষ্টি জন্য আবার ধন্যবাদ!

— অ্যালেক্স ফোর্বস

13

আমি ভারী বোঝাই ওয়েবসাইট সহ ওয়েবসারভার (অ্যাপাচি 2) চালিয়ে উবুন্টু ওয়ানিরিক ১১.১০ এর একটি নতুন ইনস্টল করতে ঠিক একই সমস্যার মুখোমুখি হয়েছি। উবুন্টুতে ওয়ানিরিক ১১.১০ সিনকুকি ডিফল্টরূপে সক্ষম হয়েছিল।

ওয়েবসারভার পোর্টে একটি সম্ভাব্য এসওয়াইএন বন্যার আক্রমণ উল্লেখ করে আমার কাছে একই কার্নেল বার্তা ছিল:

কার্নেল: [739408.882650] টিসিপি: 80 পোর্টে সম্ভাব্য এসওয়াইএন বন্যা cookies কুকি পাঠানো হচ্ছে।

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

net.ipv4.tcp_max_syn_backlogপ্যারামিটারটি টিউন করার ফলে কোনও উন্নতি হয়নি - বার্তা একই হারে অব্যাহত রয়েছে। SYN_RECV সংযোগের সংখ্যাটি সর্বদা সত্যই কম ছিল (আমার 250 বছরের নিচে ক্ষেত্রে) একটি সূচক ছিল যে অন্য কোনও প্যারামিটার অবশ্যই থাকতে হবে, যা এই বার্তার জন্য দায়ী।

রেড টুপি সাইটে এই বাগ-বার্তাটি https://bugzilla.redhat.com/show_bug.cgi?id=734991 পেয়েছি যে উল্লেখ করে যে কার্নেল বার্তাটি অ্যাপ্লিকেশনটিতে কোনও বাগ (বা ভুল কনফিগারেশন) এর ফলে হতে পারে । অবশ্যই লগ বার্তাটি খুব বিভ্রান্তিমূলক! যেহেতু এটি কার্নেল প্যারামিটার নয় যে ক্ষেত্রে এটি দায়ী, তবে আপনার অ্যাপ্লিকেশনটির প্যারামিটার, বিয়িংটি কার্নেলের কাছে পৌঁছেছে।

সুতরাং আমাদের ওয়েবসারভার অ্যাপ্লিকেশনটির কনফিগারেশন প্যারামিটারগুলিও একবার দেখে নেওয়া উচিত। অ্যাপাচি ডকগুলি ধরুন এবং http://httpd.apache.org/docs/2.0/mod/mpm_common.html#listenbacklog এ যান

ListenBacklogপ্যারামিটারের ডিফল্ট মান 511 ((এটি আপনার লাল টুপি সার্ভারে লক্ষ্য করা সংযোগের সংখ্যার সাথে মিলে যায় Your আপনার অন্য সার্ভারে সম্ভবত কম সংখ্যক কনফিগার হওয়া থাকতে পারে))

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

এটি সমাধানের জন্য, আমি নীচের লাইনটি /etc/apache2/ports.confবা অন্য একটি .conf ফাইলগুলিতে যুক্ত করব, এটি অ্যাপাচি দ্বারা লোড করা হবে ( /etc/apache2/apache2.confএটিও ঠিক হওয়া উচিত):

লিসব্যাকলগ 5000

আপনি net.ipv4.tcp_max_syn_backlogএকটি যুক্তিসঙ্গত মান সেট করা উচিত । আমার উপলব্ধিতে, কার্নেল সর্বাধিক মান সীমাবদ্ধ করবে, আপনি অ্যাপাচি কনফিগারেশনে কনফিগার করতে সক্ষম হবেন। তাই চালান:

sudo sysctl -w net.ipv4.tcp_max_syn_backlog=5000

কনফিগার টিউন করার পরে, আপনার অ্যাপাচি পুনরায় চালু করতে ভুলবেন না:

sudo service apache2 restart ( or sudo /etc/init.d/apache2 restart )

আমার ক্ষেত্রে, এই কনফিগারেশন পরিবর্তনটি তত্ক্ষণাত কার্নেলের সতর্কতাগুলি বন্ধ করে দিয়েছে। আমি অ্যাপাচি কনফিগারেশনে কম লিসনব্যাকলগ মান সেট করে বার্তাগুলি পুনরুত্পাদন করতে সক্ষম।

— জেফ
সূত্র

2

দুর্দান্ত উত্তর। আপনি যা বলছেন তা সঠিক বলে ধরে নিচ্ছি আমি এটিকে গ্রহণযোগ্য উত্তর হিসাবে চিহ্নিত করব তবে আমি সত্যিই এটি পরীক্ষা করতে পারি না - লোড হ্রাস সমস্যার সমাধান করেছে এবং আমার কোনও কারণ নেই কারণ প্রডাকশন সার্ভারের সাথে ঝাঁকুনি না দেওয়ার নীতি :)

— অ্যালেক্স ফোর্বস

আমি নিশ্চিত করতে পারি যে এটি মূলত এটি কার্নেল অ্যান্টি-ডিডিওএস বৈশিষ্ট্যরূপে কাজ করে তবে আপনি যখন গ্রহণ করছেন তখন প্রচুর ওয়েব ট্র্যাফিক এটি আপনার বৈধ ব্যবহারকারীদের অবরুদ্ধ করে দেবে!

— আরিব সু ইয়াসির

5

কার্নেল ৩.৪.৯ এর সাথে কিছু পরীক্ষার পরে নেটস্যাটে SYN_RECV সংযোগের সংখ্যা নির্ভর করে

/proc/sys/net/core/somaxconn 2 এর পরবর্তী পাওয়ার পর্যন্ত গোল (যেমন 128 -> 256)
75% /proc/sys/net/ipv4/tcp_max_syn_backlogযদি /proc/sys/net/ipv4/tcp_syncookiesসেট করা হয় 0বা 100% যদি /proc/sys/net/ipv4/tcp_syncookiesসেট করা হয়1
ListenBackLog অ্যাপাচি কনফিগারেশনে 2 এর পরবর্তী পাওয়ার পর্যন্ত গোল (যেমন 128 -> 256)

এই প্রতিটি প্যারামিটারের সর্বনিম্ন ব্যবহার করা হয়। সোমেক্সকন বা লিজব্যাকলগ পরিবর্তন করার পরে অ্যাপাচি পুনরায় চালু করতে হবে।

এবং tcp_max_syn_backlog বৃদ্ধির পরে অ্যাপাচি পুনরায় চালু করতে হবে।

Tcp_syncookies ছাড়া অ্যাপাচি ব্লক করা হচ্ছে, কেন এই ক্ষেত্রে শুধুমাত্র 75% টিসিপি_ম্যাক্স_সিন_ব্লগলগ সীমাটি অদ্ভুত। এবং এই প্যারামিটারটি বাড়িয়ে অ্যাপাচি পুনরায় আরম্ভ না করেই SYN_RECV সংযোগগুলি পুরানো মানের 100% এ বাড়িয়ে দেয়।

— usoft
সূত্র

এবং এছাড়াও কলটি /bin/echo m >/proc/sysrq-triggerপ্রায়শই 80 পোর্টে একটি সম্ভাব্য এসওয়াইএন বন্যার দিকে পরিচালিত করে cookies কুকিজের বার্তা প্রেরণ ।

— usoft