Friday, June 27, 2008

אנטי - Agent

ועם כותרת משונה שכזו , נסביר...

במשך השנים, פיתחתי דעה די מוצקת לגבי כיצד אני רואה ורוצה לראות יישום של מערכות אבטחת מידע אשר מטפלות בהגנה על המידע עצמו - צריכות להיבנות מבחינת ארכיטקטורה.

כמו שרבים וטובים יודעים, פתרונות אבטחת המידע השונים המושתתים על טכנולוגיה - מתחלקים כמעט תמיד לשתי תצורות שונות - Host Based מבוסס AGENT , וNetwork Based מבוסס Appliance.

העיקרון תמיד היה פשוט . מצד אחד יש את פתרונות הAGENT אשר תפקידם הוא אכן לבצע פעולות מתקדמות להגנה על תחנת הקצה\שרת , ומצד שני יש את פתרונות הAPPLIANCE אשר נועדו לבצע את כל הבדיקות האפשריות לפני שההתקפה מגיעה בכלל למערכת הקצה.

ובכן , כפי שכותרת המאמר מציינת , אכן אני נגד פתרונות הAgent ברוב המקרים. אני אפילו מאמין שאם ניתן היה לבצע הכל בשכבת הACCESS ולא היו בעיות של גישה פיזית למערכות - לא הייתה הצדקה כלל לפתרונות AGENT.

ומה מניע את עמדתי ?

כאשר אנו מתקינים Agent על השרת, יש לקחת בחשבון שתהיה תמיד פגיעה בביצועים , אבל במקום סתם לזרוק מושגים , אסביר : כאשר Packet מגיע מהרשת לכיוון השרת עליו לעבור דרך מנגנוני ההגנה שהושמו על ידי הAgent שהותקן. כלומר - עלינו לנסות ולהבין מה הפעולה הקשה ביותר שיבצע אותו Agent ? והתשובה היא לא תמיד פשוטה ...

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

מובן שאין מנוס ,וישנם דברים שצריכים להיבדק ברמת מקטע מקומי , אך אלו דברים בודדים כגון גישה פיזית, וביצוע פעולות Localhost אשר הינן כ0.5% מסך הפעולות שמבוצעות על השרת ... ואם כך , לפתרון מאסת התעבורה - אין סקאלאביליות בכלל. ופתרון Agent-ONLY אינו יכול להיכנס לנישת פתרון כאשר מדובר בכמויות מידע ובמערכות גדלות.

לעומת זאת , פתרונות הAppliance השונים , נבנים תוך ראיה מסוג שונה --> Throughput.

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

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

Labels: , , , , ,

Wednesday, January 09, 2008

נבואה ראשונה מתקיימת השנה - Facebook Attack

למי שמכיר ויודע , לאחרונה הצפתי מספר פעמים את נושא ההתקפות בוקטורים חדשים לקראת 2008, מי שהספיק להשתתף אולי בהרצאה שלי לגבי Differentiated Vector Attacks אפילו קיבל מספר דוגמאות חיות ודרכים ליישום התקפות מסוג זה.

והנה מסתיים לאט לאט השבוע הראשון של 2008 , והוירוס הראשון ( שאני יודע עליו ) מופץ דרך אפליקציה בתוך FACEBOOK. ובדרך די מרשימה.

הראשונים לנתח ולתפוס את ההתקפה היו חברת Fortinet אשר מראים בקישור הבא את מבנה ההתקפה והתחושה למשתמש.

בגדול - הופצה אפליקציה אשר גורמת למשתמש להבין שכדאי לו להתקין אותה בעמוד הFB שלו , בכדי לגלות אנשים אשר "דלוקים" על אותו משתמש. כאשר המשתמש מתקין את האפליקציה , מגיע אליו לינק על גבי IFRame אשר סוחב עימו את הוירוס Zango.

לא רע ... וגם די אפקטיבי.

Labels: , , , , ,

Tuesday, October 30, 2007

Stateful Inspection Is Dead

ואחרי כותרת מפוצצת שכזו וכמובן אחרי שתפסתי את תשומת הלב שחיפשתי - אפשר להתחיל לדבר.

בתקופה האחרונה יצא לי לחקור רבות אודות טכנולוגיות FW שונות ומוטציות שהן עברו מאז שהומצא מנגנון הStateful Inspection ( נסמן כ "SI" כשנדרש ) וכמובן הטכנולוגיות הללו התפתחו ולקחו את עולם הNetwork Firewall לעולמות רחוקים ומתקדמים יותר , שהופכים את הטכנולוגיות

ראשית, מהו Stateful Inspection :

באופן מאוד מאוד כללי , מדובר בטכנולוגיה אשר מתבססת על טבלאות הנקראות State Tables אשר מכילות את פרטים אודות כל TCP Stream שעובר דרך המערכת. למעשה , עבור כל SESSION נשמרים פרטים מזהים אודות חלון הTCP והפרטים השונים לגבי המשך הSESSION , ולכן כל פאקט חדש שיגיע יבדק אל מול הטבלה למציאת שייכות , אם שייך - יועבר למנוע הROUTING , אם לא - יבדק אל מול הRULEBASE של אותה מערכת FW. המאפיין הכללי כמובן הוא מקור , יעד , ופורט. הומצאה במקור על ידי CheckPoint

ובכן לפני מספר שנים בודדות , עם עליית טכנולוגיות הUTM , התווספו מספר מנגנונים לעולם הSI שעיקרם הוא הDPI או בפירוט - Deep Packet Inspection. הרעיון מאחורי הקונספט הוא - להשתמש במנגנוני Content Inspection כאלו או אחרים , על מנת לוודא שהPACKET אכן תקין ונקי ממזיקים , ולשמש כשכבה נוספת במנגנון ההחלטה לגבי הכנסה לState Table. במקרה של DPI אגב , הסריקה ממשיכה להתבצע לכל אורך התהליך בכדי לשמור על תעבורה נקיה ככל האפשר. מה שכבר הופך את טכנולוגיית הSI כריקה ולא משמעותית , כי ההסתכלות צריכה להיות מעבר לLayer 4 ויותר לכיוון Layer 7. ולשם צריך לכוון.

עד היום למעשה כל FW עדיין מבסס חוקים על פי Source/Dest/Service מבלי באמת להסתכל לתוך אותו הService. וכאן בעצם הבעיה , למרות שהקונספט עובד ועובד טוב, הוא כבר לא מספיק מעמיק בשביל להתמודד עם התקפות מתפתחות שעוברות מוטציות בין שכבות שונות במודל OSI.

לצערנו ( והאמת היא שזה היה צפוי לקרות בשלב זה או אחר ) אפילו הפתרונות הרובסטיים ביותר אינם מספקים להתקפות של מחר.

לדוגמא : כל אפליקציה מתוחכמת יודעת היום לעבוד במספר דרכים , לעבור דרך SSL או בכל מודל אחר כמו למשל מעבר לפורטים לא סטנדרטיים, וכל זאת על מנת להסתיר את זהות האפליקציה. ואז בעצם אנחנו רואים EMULE עובר דרך פורט 80 . וזה כמובן נכון להמון המון המון אפליקציות , כאשר רובן אפילו לא זדוניות.

מה באמת רץ לנו ברשת ?

הBUZZWORD שמתפתח מעולם זה הוא בעצם יצירת דור חדש ( דור 6 ? ) של מערכות FW אשר מוסיף תווך נוסף למערכת ובעצם מהווה האבולוציה האמיתית של עולם ה FW וגורם לSI לקבל את התגית Obsolete. ולמה בעצם - דור חדש של מערכות FW עולה וצף , Application Aware Firewall או בשם אחר Application Categorized Rule Based Security . והכוונה מאוד מעניינת ( ובעלת המון טכנולוגיה מאחוריה ) הקונספט הוא כזה שבו כל STREAM של אפליקציה ניתן לזהות לפי מבנה הPACKETS או מבנה של מספר PACKETS ולהשוות למול DB כזה או אחר , ובכך בעצם לתת משמעות לעמודת הService בחוקי הFW. כלומר - מידע יעבור מעתה לפי 4 שדות שונים - source/destination/port/APPLICATION .

אגב , ברור שפתרונות מסוג זה לא ניתן לבצע בתוכנה בלבד, יש צורך במעבדים מיוחדים ובחומרה שנבנתה במיוחד למטרה זו . קחו למשל אינטגרציה בין סביבת PGP לסביבה שכזו - המערכת צריכה להיות מקושרת עם הKeyring הארגוני , בשביל לפתוח את ההצפנות השונות שעוברות ברשת ולבצע ניתוח למידע המוצפן.    - הOverhead ברשת הוא מטורף, הLatency בלתי נסבל - ולכן הפלטפורמה תמיד מבוססת ASIC ואפיקי BUS אדירים.

גישה מעניינת היא האם יש צורך בהפעלת PROXY LAYER במערכות אלו , או לעבוד בSTREAM מבחינת עומסים , ובעצם עד כמה עמוק אנחנו צריכים לסרוק את התעבורה , אם אנחנו כבר יודעים שזו אכן האפליקציה שלנו , ויתרה מכך - שהיא מתנהגת כפי שרצינו. השקיפות פה נפלאה - כי אני יכול לדעת בעצם כל אפליקציה שעובדת ברמה רשתית אצלי בארגון , ולקבוע מדיניות בLEVEL אחר לגמרי.

Labels: , , , , , ,

Monday, September 17, 2007

MSN Messenger - Ad Block - Revisited


Following some email requests ( too many for that specific question ) that ive got to help various FORTIGATE ( by fortinet ) owners - to set their firewall security policy to block MSN Advertisment within the client ( as a Proof Of Concept ONLY ) ... and following an old post ( that i have posted here on march 13th 2007 - Link ) i am posting the requested configuration for the machines.

I have devided to re-post this , with better technical explenation - and in english this time , as a gesture to the "Security Bloggers Network" ( which i only post english feeds to , and this is one worth mentioning ).

the main concept is to block 3 reg-ex uri links that the messenger client gets its advertisment ads from. ( as you may or may not know , this IM uses HTTP to get things done , well - lets break its path...

[ note : configuration is made for the FortiOS mr5 patch 2 and tested on FGT60 ]

As i previsously posted , this is a good way of handeling messenger usage within organizations that do not approve end-user advertisment on its computer environment.

There are two ways of doing it ... one through the url filter engine , and the other one is through the IPS ( which i find much more exotic way of getting things done through deep packet inspection ).

Method 1 - URL Filter :

1. goto the CLI on the machine and paste the following configuration -

  • config webfilter urlfilter
        edit 1
                config entries
                    edit "ad.msn.co.il/js.ng"
                        set action block
                    next
                    edit "rad.msn.com/ADSAdClient31.dll"
                        set action block
                        set type regex
                    next
                    edit "config.messenger.msn.com/Config/MsgrConfig.asmx"
                        set action block
                        set type regex
                    next
                end
            set name "block-msn-ad-engine"
        next
    end

2. choose the "block-msn-ad-engine" within your protection-profile of choice.

Method 2 - IPS :

1. go to the Intrusion Protection >> Signature >> Custom menu and add the following signatures -

  • F-SBID( --name "bs_MSN-AD-Stop.A"; --protocol tcp; --flow established ; --regex "ADSAdClient31.dll"; --no_case)
  • F-SBID( --name "bs_MSN-AD-Stop.B"; --protocol tcp; --flow established ; --content "ad.msn.co.il"; --no_case)
  • F-SBID( --name "bs_MSN-AD-Stop.C"; --protocol tcp; --flow established ; --regex "MsgrConfig.asmx"; --no_case)

2. choose appropriate severity and include the severity in the desired protection-profile.

 

Disclaimer : this is a POC only , this kind of usage may conflict with the MSN Messenger usage aggreement , and i am not to take any responsibility for and unethical or illegal usage of this article and the information it provides. and although i tink using this information to violate any EULA or other agreement is wrong - if you use it - you are taking for responsability for it.


i am not sure that there is any violation , since all this solution does is changing the availability of web data to an application - so basically treating the application as a user in the network and denying it from getting to some internet content . legitimate isnt it ?

Labels: , , , ,

Wednesday, July 18, 2007

I Would Like To Thank Mr Richard Stiennon

חברים , אבקש להודות למר ריצ'ארד סטיינון , כיום CMO של חברת Fortinet , ולשעבר
אנאליסט אבטחת מידע בכיר בGartner.

ריצ'ארד נפגש איתי בארץ לפני מספר חודשים במהלך כנס של פורטינט בו הרצתי , והינו המחבר של אחד מהבלוגים הטובים ביותר בעולם לגבי אבטחת מידע - ThreatChaos שאני מאוד מעריך.

ריצ'ארד נחשב היום בין 50 האנשים המשפיעים ביותר בתעשיה העולמית בכל הנוגע לאבטחת מידע בתקשורת נתונים , ואתמול - בחר לכתוב POST באתר שלו , אשר מתייחס למאמר שפרסמתי פה באנגלית בעבר ( קישור למאמר ) ולציין אותי בבלוג שנקרא עלידי מאות אלפי אנשים בחודש , ואני רוצה להודות לו באופן אישי.


קישור למאמר בבלוג של ריצ'ארד
קישור נוסף למאמר שכתב המקביל לשלי

כמו כן , נכתב FOLLOWUP בבלוג נוסף - הקישור כאן


Thank you Richard for your comment , and for your post about UTM
keep on writing great columns .

Labels: , , , ,

Monday, December 04, 2006

UTM – Antithesis For The Current Concept Technology


The world of IT security technologies has evolved greatly for the last 5 years.
By understanding the structure of the current threats that threatens the IT environment of corporate infrastructure – security vendors have created very highly crafted technologies to deal with these threats. We had some major breakthroughs with IPS technologies that currently serves both signature based and proactive scanning methods, Antivirus and AntiSpam technologies can now inspect information to the deepest levels . and there are more than enough URL filtering mechanisms that serves about every major company that require these kind of services to be implemented on their users surfing habits.

UTM is something pretty fresh In that aspect, we’ve seen it growing In the last
couple of years as a major aspect for creating “All-In-One” solutions. The concept is
brought to life by taking one machine that is taking care of stateful firewalling , advanced routing ,IPSec connectivity, and giving it the extra edge by allowing it to connect to modules such as the IPS, AntiSpam, Antivirus and the URL Filtering mechanism to create a full blown inspection gateway that scans just about everything that passes through it, and decide based on scan results if to pass the traffic or rather stop and log it and that point of entry.
Now lets look at the problem. By the UTM concept – our IT should be “secured”
If we are using a UTM device at our core network environment . but – what about
blended threats ? , what about attack and code mutations?
In the second half of 2005 , many analysts and security engineers have faced new
types of attacks , the blended ones , and the mutated ones. These attacks were crafted to skip from one method to the other , from one technology to the other , and IT security measures where if you had a virus , an antivirus solution would have taken care of it, And if you had a DoS attack , the Firewall would have taken care of it , but when an attack would have begun as an Exploit that injects a virus that later on sends out spam and infects other entities via IM , or via SMB – systems are useless to these attacks.

The problem with the UTM concept today – is that companies that manufacture
these solutions , are applying OEM solutions with other vendors . one could OEM with
the best-of-breed antivirus company for his AV module , and OEM with the best-of-breed IPS company for the IPS module and pass the traffic through the both of them . but ! and here is the problem – the modules of different vendors , could not speak to each other . each module of its own honorable vendor is written as a closed source application and can receive traffic from one end , check it and pass it through , but when the IPS module and AV module co-exist but cannot take mutual decisions on the traffic that passes through – blended threats could not be inspected in any way . mutations of the traffic will pass as if there was nothing there to stop them.

Let me explain further more : when the UTM device is used to establish a layer 3
up to layer 7 connection between two entities , it inspects the traffic . now – if there is a mutation attack of some kind ( here is just an example ) – a session is being established
via VPN between two entities , and runs just http traffic between the two. The
termination of the IPSec is being done by the UTM device , which cannot see up until
now if there was an attack hidden in the traffic that came through the IPSec tunnel . then the data is getting into the http server with a 0day exploit on it , so the IPS does not know it. And sends a file that was previously accepted by the UTM device because of the tunnel access control rules. Contains a virus , and the attacker entity is passing it through an IM service . the new crafted virus is the populating itself not via IM , but via SMB , and when that occurs – the virus manipulates itself to attack the core switch via a simple DDoS attack. no UTM device would stop this attack , no single entity to take care of one module will stop this attack. The solution is being send from one or two vendors today , that have come to
mind that if they write their own antivirus , they can manipulate it , and if the IPS code is their proprietary code , they could manipulate is , and where the URL filter is a service which they own . modifications and alterations could be performed . the main issue here is that if you are the sole vendor for all modules inside your UTM device , you can ask them to speak to each other , you could take access control decisions based o blended results of the traffic that passes through your device , and because of stateful technologies, you could understand the deep behavior of your traffic , and so – have access control decisions done by the deepest analysis available.

By creating a single-vendor solution , one is able to interconnect the different
security modules and create a real UTM device , in my terms – “Real UTM” is applicable only if the device , and the different modules come from the same vendor , so it could sanitize the traffic using decisions based on a matrix check of each packet.

The following diagram ( D01 ) shows how a current concept UTM device actually passes
the traffic :



On current UTM environments , the packet actually has to go through each and every
module as a stage of inspection. What may happen is that one module might not be
certain if the packet contains an attack and so not mark it as attack and pass it on. The attack will pass between the different “Best Of Breed” modules and no decision will be taken to drop the packet , because no module found a specific attack in the mechanism and if it could , it wouldn’t be able to tell the following module about the attack because of different technologies , and vendor code confidentiality.

The following diagram ( D02 )shows exactly what happens to a packet that runs through
what is considered a real utm :



What is clearly visible from this diagram , is that a packet that runs through a real
UTM mechanism , runs through each and every one of the modules . note : if a packet is being intercepted by the IPS mechanism – it will ask for the antivirus to check it too , and so on for the AntiSpam and every UTM module. And later on , the UTM mechanism will decide based on scan checks from all of the modules , if to pass it on , or to drop the packet. It is not session based , but packet based.
Now , what is happening in that environment is that each module can give some
kind of grading to the packet , even if it is not sure it is an attack . next , the UTM consolidation engine can grade the packet based on all of the modules , and have a sophisticated decision to drop or to accept the packet , and that is after a real deep inspection.

A new UTM RFC/Protocol is required.

One cannot realize how major vendors will exchange code parts between them,
But maybe some kind of a consolidation protocol is needed here . we had ICAP in the
past to check for different traffic methods, maybe now is the time to write a new protocol that inspection modules could grade traffic by , and a consolidated decision could be made.

In conclusion , the UTM world is a wonderful and insightful world, the best of the
vendors are doing a great effort in order to give us the best practice results and the solutions we require. But because of misleading assumptions ,that “attacks may be more sophisticated but they still spread in the same ways” the UTM world will not be complete. What should be the concept is “an attack can come In different ways and
blended ways , check them all and never skip a phase”.


Labels: , , ,


About

    My Name is Barry Shteiman, im a devoted tech junkie, and this is my blog.
    E: barry.shteiman -at- gmail.com
    Twitter : bshteiman

Tags & Categories

Mailing List & RSS

Stay Updated  
Add to Technorati Favorites