কীভাবে একটি মুক্ত পোস্টগ্রিজ এসকিউএল পোর্ট সুরক্ষিত করা যায়

Question

সুতরাং, এই অবস্থা। দেখে মনে হচ্ছে আমাদের কাছে বিশ্বের কাছে একটি উন্মুক্ত টিসিপি পোর্ট 5432 থাকা দরকার, যেখানে কোনও গ্রাহকের তার পোস্টগ্রিজ এসকিউএল ডাটাবেসে অ্যাক্সেস রয়েছে।

সুস্পষ্ট কারণে, আমরা কেবল "না" বলতে পারি না, কেবল শেষ-শেষ অবলম্বন হিসাবে।

সবচেয়ে বড় ঝামেলা কি? আমি কীভাবে আমাদের অবকাঠামো রক্ষা করতে পারি?

যাইহোক: কেন এটি বিশ্বের কাছে খোলা উচিত নয় ? আমি মনে করি, সম্ভবত এটি প্রায় 20 বছরের পুরানো, অবিস্মরণীয় এফটিপি সার্ভারের চেয়ে বেশি সুরক্ষিত।

পিএস ভিপিএন ঠিক আছে না। কিছু এনক্রিপশন হতে পারে (যদি আমি তাকে জেডিবিসি সংযোগের URL দিতে পারি যা কাজ করে )।

Comments

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

— লুসিফার স্যাম

@ লুসিফারসাম নং। ডিবিটি প্রায় 100 টি কোম্পানির মেশিনে অভ্যন্তরীণ উন্নত জাভা অ্যাপ্লিকেশন দ্বারা ব্যবহৃত হবে। তাদের কনফিগার করার আমাদের একমাত্র উপায় হ'ল তাদের লোকালনেট প্রশাসনের কাছে একটি জেডিবিসি সংযোগ ইউআরএল দেওয়া, অন্য যে কোনওটি খুব সমস্যাযুক্ত।

@ মিল্কম্যান অ্যাপটি কি করে? সম্ভবত এটি পরিবর্তে কোনও RESTful সার্ভারের জিজ্ঞাসা করতে পারে? স্পষ্টতই,

— এসকিউএলকে আরএসএসে পাস করা কোনও লাভই

@ tedder42 এটি ব্যবহারকারীর সিএমএসের ডেটাবেস পরিচালনা করে, যা আমাদের দ্বারা হোস্ট করা হয়। আমাদের এর উত্স পরিবর্তন করার অনুমতি নেই।

Answer 1

এসএসএল প্রয়োজন, এসইএলিনাক্স চালু রাখুন, লগগুলি নিরীক্ষণ করুন এবং একটি পোস্টগ্রিজ এসকিউএল সংস্করণ ব্যবহার করুন ।

সার্ভার পাশ

এসএসএল প্রয়োজন

ইন postgresql.confসেট ssl=onএবং আপনি আপনার keyfile এবং certfile উপযুক্তভাবে ইনস্টল করা আছে (ডক্স এবং মন্তব্য দেখতে নিশ্চিত postgresql.conf)।

আপনার যদি কোনও ক্লায়েন্টের বিশেষ সেটআপ ছাড়াই ক্লায়েন্টরা বিশ্বাস করতে চান তবে আপনার কোনও সিএ থেকে শংসাপত্র কিনতে হবে।

ইন pg_hba.confভালো কিছু ব্যবহার:

hostssl theuser thedatabase 1.2.3.4/32 md5

... সম্ভবত ব্যবহারকারী এবং / অথবা ডাটাবেসগুলির জন্য "সমস্ত" এবং সম্ভবত একটি বৃহত্তর উত্স আইপি অ্যাড্রেস ফিল্টার সহ।

লগ ইন করতে পারে এমন ব্যবহারকারীদের সীমাবদ্ধ করুন, দূরবর্তী সুপারসার লগইনকে অস্বীকার করুন

সম্ভব হলে ব্যবহারকারীদের জন্য "সমস্ত" অনুমতি দিন না; আপনি যদি প্রয়োজনের অতিরিক্ত এড়াতে পারেন তবে দূরবর্তীভাবে সুপারজারের লগইনগুলির অনুমতি দিতে চান না।

ব্যবহারকারীদের অধিকার সীমাবদ্ধ করুন

ব্যবহারকারী (গুলি) লগ ইন করতে পারেন অধিকারকে সীমাবদ্ধ করুন। তাদের দেবেন না CREATEDBবা CREATEUSERঅধিকার।

REVOKECONNECTথেকে সরাসরি PUBLICআপনার সব ডাটাবেস উপর, তারপর এটি ফিরে শুধুমাত্র ব্যবহারকারীদের / ভূমিকা যে ডাটাবেসের অ্যাক্সেস করতে সক্ষম হওয়া উচিত দেব। (সরাসরি ব্যবহারকারীদের পৃথক পরিবর্তে ভোক্তাদের গোষ্ঠীভুক্ত করা এবং ভূমিকার অধিকার প্রদান করুন)।

নিশ্চিত করুন যে রিমোট অ্যাক্সেস সহ ব্যবহারকারীরা কেবল তাদের প্রয়োজনীয় ডিবিগুলির সাথে সংযোগ করতে পারবেন এবং কেবলমাত্র তাদের প্রয়োজনীয় স্কিমা, টেবিল এবং কলামগুলির অধিকার রয়েছে। এটি স্থানীয় ব্যবহারকারীদের পক্ষেও ভাল অনুশীলন, এটি কেবল বোধগম্য সুরক্ষা।

ক্লায়েন্ট সেটআপ

পিজজেডিবিসি-তে, প্যারামিটারটি পাস করুনssl=true :

জেডিবিসি ড্রাইভারকে একটি এসএসএল সংযোগ স্থাপনের চেষ্টা করার জন্য নির্দেশ দেওয়ার জন্য আপনাকে অবশ্যই সংযোগের URL পরামিতি যুক্ত করতে হবে এসএসএল = সত্য।

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

চলমান ক্রিয়া

এখন আপনি PostgreSQL আপডেট রাখছেন তা নিশ্চিত করুন । পোস্টগ্রেএসকিউএল-এর কেবল বেশ কয়েকটি প্রাক-প্রমাণ সুরক্ষা গর্ত রয়েছে তবে এটি শূন্যের চেয়ে বেশি, তাই আপ টু ডেট থাকুন। আপনার যাইহোক, বাগফিক্সগুলি রাখা ভাল জিনিস।

সামনে যদি বড় নেটব্লক / অঞ্চল থাকে আপনি জানেন যে আপনাকে কখনই অ্যাক্সেসের দরকার নেই সেদিকে সামনে একটি ফায়ারওয়াল যুক্ত করুন।

লগ সংযোগ এবং সংযোগ বিচ্ছিন্ন করুন (দেখুন postgresql.conf)। ব্যবহারিক হলে প্রশ্নগুলি লগ করুন। ব্যবহারিক হলে অনুপ্রবেশ সনাক্তকরণ সিস্টেম বা ব্যর্থ 2 বা এটির সামনে অনুরূপ চালান। Postgres সহ ব্যর্থ 2 ব্যাবহারের জন্য, এখানে কীভাবে করা যায় তা সুবিধাজনক

লগ ফাইল নিরীক্ষণ।

বোনাস পারানো

এ সম্পর্কে ভাবার অতিরিক্ত পদক্ষেপ ...

ক্লায়েন্ট শংসাপত্র প্রয়োজন

আপনি যদি চান pg_hba.confতবে ক্লায়েন্টটি সার্ভারের দ্বারা বিশ্বস্ত X.509 ক্লায়েন্ট শংসাপত্র উপস্থাপন করতে হবে তাও আপনি ব্যবহার করতে পারেন । এটি সার্ভার শংসাপত্রের মতো একই সিএ ব্যবহার করার দরকার নেই, আপনি হোমব্রিউ ওপেনসেল সিএ দিয়ে এটি করতে পারেন। একটি জেডিবিসি ব্যবহারকারীর ক্লায়েন্ট শংসাপত্রটি তাদের জাভা কীস্টোরের সাথে তাদের কীস্টোরে জাভা নির্দেশ করার জন্য keytoolকিছু জেএসএসই সিস্টেম বৈশিষ্ট্য কনফিগার করতে হবে এবং এটি সম্পূর্ণ স্বচ্ছ নয়।

উদাহরণ পৃথক

আপনি যদি সত্যিই ভৌতিক হতে চান, তবে ক্লায়েন্টের জন্য পৃথক ধারক / ভিএম, বা কমপক্ষে একটি পৃথক ব্যবহারকারীর অ্যাকাউন্টের অধীনে কেবলমাত্র প্রয়োজনীয় ডাটাবেস (গুলি) ব্যবহার করুন।

যদি তারা পোস্টগ্র্যাসকিউএল উদাহরণটি আপস করে তবে তারা আর কিছুই পাবে না।

SELinux ব্যবহার করুন

আমাকে এটা বলতে হবে না, তবে ...

আরএইচইএল 6 বা 7 এর মতো সেলইনাক্স সমর্থন সহ একটি মেশিন চালান, এবং সেলইনাক্স বন্ধ করবেন না বা এটি অনুমতিমূলক মোডে সেট করবেন না । এটি প্রয়োগকারী মোডে রাখুন।

একটি ডিফল্ট পোর্ট ব্যবহার করুন

কেবল অস্পষ্টতার দ্বারা সুরক্ষা বোকামি। আপনি বুদ্ধিমান জিনিসগুলি একবার সম্পন্ন করার পরে সুরক্ষা যা কিছুটা অস্পষ্টতা ব্যবহার করে সম্ভবত ক্ষতি করবে না।

অটোমেটেড আক্রমণকারীদের জন্য জীবনকে আরও শক্ত করার জন্য একটি অ-ডিফল্ট পোর্টে পিজি চালান।

সামনে একটি প্রক্সি রাখুন

আপনি সংযোগ পুল এবং প্রক্সি হিসাবে অভিনয় করে পোস্টগ্রেএসকিউএল এর সামনে পিজবাউনার বা পিজপুল -২ চালাতে পারেন। এইভাবে আপনি প্রক্সি হ্যান্ডেল করতে পারবেন এসএসএল, আসল ডাটাবেস হোস্ট নয়। প্রক্সিটি পৃথক ভিএম বা মেশিনে থাকতে পারে।

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

Comments

ক্লায়েন্টের যদি একটি স্ট্যাটিক $ আইপি থাকে তবে কেবল ফায়ারওয়ালের মাধ্যমে $ পোর্টেও এটি অনুমতি দেয়।

— ব্যবহারকারী 9517 GoFundMonica

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

@ সর্বোপরি, আমি মনে করি কোনও ভিপিএন প্রকাশ করা কেবলমাত্র একটি সীমাবদ্ধ পরিষেবার তুলনায় আক্রমণ পৃষ্ঠকে ব্যাপকভাবে বৃদ্ধি করে। লোকেরা ভুলে যায় যে ভিপিএন তারপরে রিমোট মেশিনের যেকোন ম্যালওয়্যারের জন্য সমস্ত ঘেরের সুরক্ষার মধ্য দিয়ে ঘুষি মারতে এবং নেটওয়ার্কের সাহস পাওয়ার জন্য আক্রমণ চ্যানেলে পরিণত হয়। আমি কেবল তাদের গ্রহণযোগ্য মনে করি যদি তারা কোনও ডিএমজেডের সাথে সংযুক্ত থাকে যা তাদের ইন্টারনেট হোস্টের মতো বিষাক্ত বলে মনে করে।

— ক্রেগ রিঞ্জার

@ ক্রেইগ্রিংঞ্জার আমি বাকী সুরক্ষা অপসারণ করার জন্য বলছি না, তবে ভিপিএন

— লেস্টোতে

@ ইস্টো শিওর, একমত, অনেক অ্যাডমিনদের দুর্ভাগ্যক্রমে যাদুকরী সুরক্ষা সস হিসাবে যদি এটি চিকিত্সা না করা হয় তবে কোনও ভিপিএন কার্যকর অতিরিক্ত স্তর হতে পারে।

— ক্রেগ রিঞ্জার

Answer 2

ক্রেগগুলির চিত্তাকর্ষক অ্যাকশন পরিকল্পনার একটি সাধারণ বর্ধন:

সম্ভবত ব্যবহারকারী কেবলমাত্র নেটওয়ার্ক সরবরাহকারীদের একটি আপেক্ষিক সামান্য সেট ব্যবহার করছেন (উদাহরণস্বরূপ, চলার সময় তার মুবিল নেটওয়ার্ক সরবরাহকারী, বাড়ি থেকে তার কেবল নেটওয়ার্ক এবং কাজ থেকে কর্মস্থলের বাইরে বেরিয়ে আসা আইপি)।

বেশিরভাগ নেটওয়ার্ক সরবরাহকারীর অনেক আইপি থাকে তবে সত্যিকারের অনেক সাবনেট থাকে না। সুতরাং, আপনি একটি iptables ফিল্টার দিতে পারেন, যা আপনার গ্রাহক দ্বারা ব্যবহৃত নেটওয়ার্ক বিভাগগুলিতে পোস্টগ্র্যাস্কল অ্যাক্সেসকে সীমাবদ্ধ করে। এটি নেট এর এলোমেলোভাবে-নির্বাচিত সমস্যা উত্সের আক্রমণ সম্ভাবনাগুলি হ্রাস করে।

একটি সাধারণ সমর্থন দৃশ্য:

1. আপনার গ্রাহক আপনাকে কল করে, "আমি লগইন করতে পারি না" ।
2. আপনি একটি tcpdump -i eth0 -p tcp port 5432আদেশ দিয়ে জানতে পারেন , তিনি কোথা থেকে আসছেন।
3. একটি দিয়ে whois 1.2.3.4আপনি এই আইপি দ্বারা ব্যবহৃত আইপি ঠিকানা পেতে পারেন। উদাহরণস্বরূপ, এটি হতে পারে 1.2.3.0/24।
4. একটি iptables -A INPUT -s 1.2.3.0/24 -p tcp --dport 5432 -j ACCEPT(বা কিছু অনুরূপ) দিয়ে আপনি তার নতুন সাবনেটের সাথে টিসিপি সংযোগের অনুমতি দিন।

নামে একটি খুব ভাল পার্ল স্ক্রিপ্ট রয়েছে uifযা স্থায়ী এবং স্বজ্ঞাত হিসাবে ঘোষণাযোগ্য iptables নিয়মকানুন সরবরাহ করতে পারে। ("Uif iptables" এর জন্য গুগল)।

Comments

আকর্ষণীয় ধারণা, তবে এটি কিছুটা ভঙ্গুর মনে হলেও।

— নিশান্তজর

@ নিশান্তজর অবশ্যই এটি একক সমাধান নয়, কেবল জিনিসকে আরও উন্নত করার সম্ভাবনা।

— পিটার বলেছেন মোনিকা

আরও কার্যকর ব্যবহারিক পদ্ধতি পৃথক আইএসপি এবং / অথবা দেশগুলিকে শ্বেত তালিকাভুক্ত করা হতে পারে, এটি করার উপায়গুলির জন্য যেমন দেখুন স্ট্যাকওভারফ্লো

— জোসিপ রডিন

Answer 3

উপরে উল্লিখিত HOWTO এর উপর ভিত্তি করে পোস্টগ্র্রেএসকিউএল এর জন্য মোটামুটি সাধারণ Fail2ban কনফিগারেশন রয়েছে তবে উবুন্টু প্যাকেজগুলির সাথে প্রকৃতপক্ষে কাজ করার জন্য, অন্য একটি ত্রুটি শর্তটি ধরা এবং দ্রুততর করার জন্য বিভিন্ন ডিবাগ বার্তাগুলি বাদ দেওয়া:

/etc/fail2ban/filter.d/local-postgresql.conf:

[Definition]

failregex = <HOST>\(\d+\) FATAL:  password authentication failed for .+$
            <HOST>\(\d+\) FATAL:  no pg_hba.conf entry for host .+$

ignoreregex = duration:

/etc/fail2ban/jail.d/local-postgresql.conf:

[local-postgresql]
enabled  = true
filter   = local-postgresql
action   = iptables[name=PostgreSQL, port=5432, protocol=tcp]
           sendmail-whois[name=PostgreSQL, dest=root@localhost]
logpath  = /var/log/postgresql/postgresql-9.3-main.log
maxretry = 3

Answer 4

Fail2ban একটি শক্তিশালী সরঞ্জাম, তবে কোনও ফিল্টার যেমন চলবে তেমন বিশ্বাস করবেন না। ফেলেরেক্সেক্স সরঞ্জামটি ব্যবহার করে যে কোনও ফিল্টার পরীক্ষা করুন এবং কোনও উদ্ধৃতি থেকে বাঁচতে ভুলবেন না (অর্থাত "অ্যাডমিন" \ "অ্যাডমিন \" হবে)। উদাহরণস্বরূপ, আমার /etc/log/postgresql/postgresql-9.3-main.log থেকে নিম্নলিখিত ফিল্টার ব্যর্থতার লাইনটি পরীক্ষা করা আমার পক্ষে কাজ করে না।

fail2ban-regex '2016-09-20 14:30:09 PDT FATAL:  password authentication failed for user "admin"' '<HOST>\(\d+\) FATAL:  password authentication failed for .+$'

উপরের আমাকে দিয়েছে

ব্যর্থতা: মোট 0

লগ ফর্ম্যাটের সাথে মেলে আমাকে ব্যর্থতা সম্পর্কিত আপডেট করতে হয়েছিল।

fail2ban-regex '2016-09-20 14:30:09 PDT FATAL:  password authentication failed for user "admin"' 'FATAL:  password authentication failed for user \"<HOST>\"'

এটি আমাকে একটি ইতিবাচক ফলাফল দিয়েছে।

ব্যর্থতা: মোট 1 টি

ব্যর্থ 2ban-regex পরীক্ষাটি সম্পূর্ণ লগ ফাইলগুলিতে প্রয়োগ করা যেতে পারে।

fail2ban-regex /var/log/postgresql/postgresql-9.3-main.log /etc/fail2ban/filter.d/postgresql.local

উপরেরগুলি আমাকে আপডেট ব্যর্থতার সাথে নিম্নলিখিত ধরণের ফলাফল দিয়েছে।

ব্যর্থতা: মোট 169