Reverse Proxy \ Forward Proxy

moranw515

New member
Reverse Proxy \ Forward Proxy


שלום לכולם


אם אפשר עצה מהחבר'ה המנוסים כאן בנושא הפרוקסי ושרתי WEB.
אם אני מעוניין להימנע מ SQL Injections ככל האפשר, Load Balancing טוב יותר ובגדול הסתרה של אחד האתרים הגדולים שאני מאחסן ואחראי עליהם
בצורה כזאת שהגולש יפנה אל שרת פרוקסי ולא אל שרת ה WEB עצמו.. האם מדובר ב Reverse או Forward ?
קראתי המון על הנושא אבל זה נורא מבלבל..
והבנתי שבסביבת עבודה של IIS ניתן להגדיר זאת ב AAR 3.0 בצורה די נוחה.

יש גם URL Rewrite שהבנתי מה הוא עושה ואני לא ממש צריך הסוואה של אתר בצורה של כתובת URL אחרת.. אבל האם זה הכרחי בהגדרה של Reverse Proxy ?

תודה לכל העוזרים
 

ירון316

New member
כדי להימנע מ-SQL Injections

הקוד צריך להיות כתוב טוב, השרת המארח צריך להיות מעודכן ועדיף שהקוד לא יהיה ב-PHP

לא בטוח כמה ריברס פרוקסי יעזור לך נגד זה. יותר ברמה של מתקפות נגד שרת האפאצ'י.
ביחס ל-LB, זה כבר עסק אחר לגמרי. אם אתה לא משתמש ב-HTTPS, אני ממליץ על Varnish:
https://www.varnish-cache.org/trac/wiki/LoadBalancing

אם כן, נסה פתרונות אחרים, המובנה של רד האט או של אפאצ'י נניח:
http://httpd.apache.org/docs/2.2/mod/mod_proxy_balancer.html
 

moranw515

New member
תודה על התגובה :)

בעניין הקוד, יש פירצות ואין לי הרבה מה לעשות נגד זה כי מדובר בעבודה של המתכנתים כאן וההנהלה לא מוכנה לעשות משהו בעניין..
מה שכן מדובר ב ASP.NET ולא PHP


פשוט אח"כ אני זה שעובד הרבה כדי לשחזר DB ל TEMPS ומשם למקורי רק בגלל שהשחיתו כמה טבלאות..
בכל אופן קראתי שזה כן די יעיל נגד מתקפות Injections אבל אולי התבדיתי.

תודה בכל אופן :)
 
ברגע שאתה מפעיל reverse proxy אתה יכול

לכתוב חוקים לסינון תעבורה, כמו תווים לא רציונלים בבקשות GET שגורמות לSQLI.
כמובן שזה תלוי בעיקר ביכולות המערכת שעושה לך את הRP.
&nbsp
אם מדובר במערכת מסחרית, אחרי שימחקו לכם כמה טבלאות וימשכו חומר סודי להנהלה יהיה אכפת.
&nbsp
 

moranw515

New member
כבר קרה, אבל לא שמשכו חומר סודי.. כי אנחנו מאחסנים אתרים

בעיקר..
אלא שפשוט אירגוני טרור ערבים הכניסו חומר אנטי-ישראל לאתרים ושיבשו את מערכות הניהול של האתרים.
&nbsp
יש לך מערכת Reverse Proxy מומלצת?
על פלטפורמה של מיקרוסופט
 

F00D Is G00D

New member
יש לי כמה התנגדויות אם תרצה להשתמש בהם

1. משאבי השרת הנוסף הזה, והניהול שלו שווים כסף. הוא עלול להוסיף איטיות כלשהי, והוא מהווה בפני עצמו עוד נקודת כשל בשרשרת.

2. אם המתכנתים ייתרגלו שיש קופסת קסם כזו ששומרת עליהם - הם יפסיקו לבדוק קלט. זה יוסיף סיכון (כי קופסת הקסם לא תמיד עובדת) ולא ייאפשר להסיר את הקופסה בעתיד כשייתגלו חסרונות.

3. ניהול הקלט הרבה יותר נוח בקוד ומאפשר למתכנת שליטה בתהליך. שלעומת זאת קופסת הקסם פשוט תזרוק את המשתמש מהאתר - שזה פוטנציאלית איבוד לקוח. לקוח שכל מה שהוא רצה זה לפני התשלום להוסיף הערה שיש בה צ'ופציק או גרשיים או לא יודע מה. לא היה כבר יותר קל להחליף תו אחד בתו אחר בתוך הקוד?!?


אגב, אנחנו חווים את זה כאן בתפוז! נסה לכתוב הודעה עם המילה סיסטם32 או בצג (סי.אם.די) ותראה איך הודעה שהשקעת שעות בהקלדה שלה הולכת לקיבינימט.

אין לי שום דבר נגד הקופסה. אבל צריך להבין שזה לא קסם מוצלח במיוחד.
 

yossik111

New member
מנצל את ההזדמנות ובאותו ענין

עד כמה אכן נחוץ ,מבחינת סקיוריטי נטו , isa server (והדומים / מחליפים שלו וכ'ו) כאשר הוא משמש עבור owa/activesync/outlook anywere (בלבד - כלומר העברת פורט 443 בלבד ללא filtering packets , קאשינג וכ'ו ) כאשר מאחוריו נמצא פיירוול מספיק "מכובד" (או לפחות ברמה של ה isa ) הפתוח ב 443 בלבד ל ISA ?
איזה ערך מוסף / יתרון אבטחתי יכול לתת החוצץ הנ"ל (ה isa ) עבור הסנריו שתיארתי עכשיו ?
חסרונות כפי שציין פוד לא חסר (לאו דווקא בקטע של הסקיוריטי (ואכן חוויתי יותר מפעם אחת לאחרונה את ענין נקודת כשל שהעלה פוד) )
אני מחפש כאמור יתרונות בכדי לדעת האם אכן "שווה" להחזיק חוצץ שכזה (שוב , בסנריו שציינתי ) .
יוס .
 
למעלה