ארכיון חודשי: אוקטובר 2010

הגנה על מערכות VoIP

כמו שכתבתי בעבר בDigital Whisper, יש הרבה דרכים להגן על המרכזייה של הארגון שלכם, או המרכזייה כאפליקציה בארגון.

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

הנה כמה דברים שאתם חייבים להבין על אבטחת מידע בכל מה שנוגע למרכזייה שלכם בנקודות:

  • טלפוניה (ללא קשר לסוג המערכת) רגישה להתקפות כדוגמת Man In The Middle – כלומר מחשב באמצע התעבורה באיזשהו צד יכול לעשות נזק לשיחה או רק להאזין לה בברירת מחדל.
  • טלפוניה רגישה להתקפות כדוגמת DoS – כלומר מניעת שירות. זה יכול להיות מניתוקים רבים של כל בקשה ליצירת שיחה, זה יכול להיות הרבה התקשרויות מעבר למה שהקו או המרכזייה מסוגלים לטפל, זה יכול להיות עוד הרבה דברים שימנעו שימוש בטלפון אצלכם בארגון.
  • ניתוב לא נכון יכול לעלות לארגון הרבה כסף. נגיד שיחות לחו"ל, שיחות למספרים "אסורים" (שעולים הרבה כסף) וכו' יכולים לגרום לכם להיות קורבנות של גניבת שיחות.
  • מתן גישה לכל דורש למרכזייה אומר שאפשר לעשות כל מה שרוצים בה.

אז איך מגנים על המרכזייה ? ובכן אתם יכולים לקרוא את המאמר הקצת טכני שלי שקישרתי למעלה, או להתחיל לנקוט בצעדים הבאים (להתחלה):

  1. כל התקשורת מ ואל המרכזייה מתבצעת רק מהרשת המקומית של הארגון.
  2. כל תקשורת יוצאת ונכנסת חייבת להיכנס דרך VPN מוצפן.
  3. ספקי SIP או VoIP חיצוניים צריכים להיות מאושרים לגשת למרכזייה ברמת ה IP שלהם ורק לפורטים הספציפיים שהם עבור SIP: פורט 5060 ועבור תעבורת המידע של RTP ו SDP בטווח של 10,000 עד 20,000 פורטים. שיטת התקשורת היא UDP.
  4. בתוך הארגון אפשרו למרכזייה להיות ברשת משל עצמה (VLAN) ותגבילו גישה רק לMac Address ידוע של טלפונים מורשים בנוסף לכתובות IP סטטיות מוקצות מראש עבור כל טלפון וטלפון.

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

כמו כן, תוכלו למצוא עוד יעוץ בנושא אצלי בעסק.

מי יודע ?

A consensus means that everyone agrees to say collectively what no one believes individually — Abba Eban

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

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

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

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

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

וחשוב לזכור, כי מי שלא לומד מההיסטוריה (או בכלל), נגזר עליו לחזור בשנית על אותן הטעויות.

מוקדש כחומר למחשבה.

העץ של ג'יסון

"The best time to plant a tree was 20 years ago.  The next best time is now." — Chinese Proverb

יש לי מנוע שאני עובד איתו ליצור כל מיני דברים שקשורים לאסטריסק, והוא מקבל JSON כמיפוי מה לעשות. הבעיה היא שהפרוייקט האחרון שאני יוצר, היה לי שבוע שלם בעיות עם העץ ולא הצלחתי לשים את היד מה הבעיה שם, היות ועל פניו המידע נראה תקין, אבל בפועל הוא לא התאים לצורת העבודה שלי, ובגלל שמדובר בלמעלה מ500 שורות של מידע (רק המידע, בלי כל הדברים מסביב), כמעט בלתי אפשרי להבין מה לא בסדר במידע, שעל פניו נראה תקין.

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

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

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

מחשב ניווט לספינות

פנו אלי לסייע בניתוח בעייה במחשב ניווט לספינות ישן שפתאום הפסיק לעלות. הסיבה שפנו אלי, היא בגלל שמדובר בלינוקס, והמעבדה לא מכירה מערכות הפעלה שהן לא של מיקרוסופט. לאחר בדיקה גיליתי שלא רק שהוא לא כובה כמו שצריך, ויש בעיה קטנה בלוח אם אשר גורמת לקרנל להיתקע. העברתי את הדיסק הקשיח אל מחשב אחר (הרבה יותר חדש), והצלחתי לגרום להכל לעלות. כבר בהתהחלה fsck היה מאוד ישן (שנות ה90 היה חלק מהבאנר שלו), וגיליתי שמדובר בלינוקס סוזה גרסה 5.3 עם קרנל 2.0.35. הקרנל מן הסתם שודרג, היות ובשנות ה90, כמו 95 (שזה בערך מתי שהגרסה הזו יצאה), הקרנל עדיין היה בגרסה 1 שלו…

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

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

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

ממש נהנתי לסייר בעולם הישן הזה. מומלץ לכל מי שיכול לחזור אחורה בזמן ולראות איך העולם התקדם כל כך.

מה חסר בעולם הקוד הפתוח ?

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

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

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

מייד שאלתי אותו לכוונתו והוא הראה לי קטע קוד שהוא מצא באינטרנט ב ++C בשביל להציג רשימה של מידע עם כפתורים שישנו את היכולת לגרור את האיברים ברשימה (רשימה וויזואלית כמובן) היה שם קרוב ל1,000 שורות קוד, שכתוב ב GTK+. ואז הוא מוסיף ואומר "ב #C אתה אולי תכתוב 50 שורות קוד בשביל אותו הדבר בדיוק, ואתה בטח תצחק עלי, אבל כשהייתי מתכנת בדלפי זה היה אולי 12 שורות קוד. זה לא צריך להיות כל כך מסובך, או קשה. לא צריך להקציב למשימה כזו כל כך הרבה קוד, זה פשוט לא הגיוני".

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

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

להבין את רובי

לאחרונה יצא לי לגעת בקוד הראשון ביותר שאי פעם כתבתי בשפת רובי, ואני חייב לציין שאינני יודע באיזו שפה זה כתוב, התחביר אומנם רובי, אבל הקוד נראה הכלאה בין ג'אווה לבין פרל – לא רובי. חשוב לציין שב2006 כאשר כתבתי אותו, כתבתי אז בעיקר ב2 השפות האלו, ובכלל לא ברובי…

רובי היא שפה שהיא Object Oriented אמיתית, בה פיזית הכל הוא אובייקט. אין primitives כמו בג'אווה אלא ממש הכל הוא אובייקט. אם זה מספר, או תו או כל דבר אחר.

עד רובי 1.8.7 כולל, האובייקט הנמוך ביותר ברובי נקרא Object. ברובי 1.9 (גרסת הפיתוח של גרסה 2), יש אובייקט שObject יורש ממנו הנקרא BasicObject. התוספת נבנתה מצד אחד ליצור תאימות לאחור, תוך כדי יצירה של אובייקט אב המכיל כמעט לגמרי כלום.

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

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

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

מקמפל אורז

לאחרונה אני מוצא את עצמי יוצר הרבה חבילות (יחסית) עבור Arch Linux אשר קצת חסרות לנו במאגרים הרשמיים, ומוסיף אותם ל AUR במקום. את החבילות האחרונות שאני מוסיף כמו שאתם בטח מנחשים, הוספתי עבור Firebird SQL, אשר בניגוד לדביאן, שם יש יצירה רשמית של החבילות, כאן ההפצה של Arch לא תומכת במסד הנתונים וחבל.

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

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

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

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

שם זמני

כל מי שמתכנת, מגיע באיזשהו שלב למצב בו הוא צריך לשמור בצורה זמנית מידע לקובץ. בשביל זה המציאו את הספריות שנועדו לזה בשמות שונים ומשונים.  עד כאן הכל נחמד. הבעיה היא שיש הרבה מאוד בעיות עם שמות הקבצים הזמניים. למשל אם אני אקרא לקובץ temp1.tmp אז אולי יהיה סיכוי שהוא יהיה קיים כבר. אז מה עושים ? ובכן יש כאלו שמספקים את שם ה pid ביוניקס/לינוקס כשם הקובץ. יש כאלו שמספקים את שם אפליקציה עם ה pid, וכאלו שמספקים מספר של השם האחרון הלא קיים מתבנית מסויימת.

העניין הוא שיש בעיה עם הגישות האלו, וזה שאפשר לגרום למצב בו יהיה DoS או גרוע מזה במכונה. בד"כ ניתן לעשות את זה על ידי התקפה שנקראת Symlink Attach, כלומר יוצרים קובץ שהוא symlink לקובץ אמיתי שקיים, ובעצם התוכנה שחושבת שהיא יצרה את הקובץ, כי הרגע היא ראתה שאין קובץ כזה, משכתבת קובץ אמיתי, נגיד init או bash או אם אין לתוכנה הרשאות, בד"כ (אלא אם ציפו למצבים כאלו של חוסר הרשאות בזמן כתיבה) היא תקרוס, ועוד הרבה בעיות, כולל איבוד מידע שמנסים לכתוב אותו.

בד"כ ההתקפה מתרחשת כאשר יש גישה ישירה למחשב, אבל אין אפשרות להגיע להיות root, אז בעזרת ההתקפה, מנסים להשיג את הרשאות ה root.

אבל יחסית מאוד קל לפתור את הבעיה, וזה על ידי 4 או 5 מהלכים פשוטים:

  1. קביעת שם רנדומאלי לחלוטין ולהבטיח שהוא לא קיים
  2. לפתוח את הקובץ שאחרים לא יכולים לגעת בו כל עוד הוא פתוח אצלנו (לא תמיד אפשרי)
  3. בפתיחת הקובץ להגיד לAPI שאסור ללכת לsymlink, כך שתהיה כתיבה ישירה לקובץ ולא למסלול שהוא מצביע אליו.
  4. בדיקה האם הקובץ הוא symlink ואם כן, אז לשנות שוב פעם את השם.
  5. לעגן בצורה מיוחדת את ספריות ה tmp (בהתאם לצורך, יכול להיות ספרייה שונה לגמרי), כך שמראש בהגדרת ה mount אי אפשר לעקוב אחרי symlink.

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

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

Firebird 2.5 שוחררה

בשעה טובה ומצולחת שוחררה היום (04.10.2010) גרסה חדשה של firebird : 2.5. הגרסה מכילה בתוכה בראש ובראשונה שכתוב מלא של מערכת ה threading של מסד הנתונים, אשר מאפשרת לעבוד טוב יותר מול SMP וזו הסיבה לגרסה הזו, אך זה לא כל השינויים שנמצא בגרסה הזו. הגרסה הזו ד"א היא עוד צעד (מאוד חשוב) לגרסה 3.

בזכות הגרסה החדשה של מנוע ה Thread נוצרה עוד סוג של עבודה עם מנוע מסד הנתונים שנקרא SuperClassic, אשר משלב תכונות שקיימות בשרת הקלאסי, מול שרת Super, וכך יש למשל Cache אחיד כמו שרת ה Super, אבל תמיכה בריבוי מעבדים כמו בClassic. מצד שני, כמו בSuper, כאשר הפרוסס קורס, כל החיבורים הולכים איתו, וזה בניגוד ל Classic. כך שלכל צורת עבודה יש יתרונות שונים עבור צורת השימוש בה, ובמידה ויש יותר זכרון מאשר כוח עיבוד, אז למשל בד"כ שרת הSuper יקבל תעדוף, אבל זה לא כזה פשוט כמו שזה נשמע, וצריך לעשות ניסויים ולראות בעצמנו כל פעם מה מתאים יותר לצורך הספציפי שלנו באותו המקום.

למרות השינוי המשמעותי הזה, זה לא השינוי היחיד שהתבצע במסד הנתונים. יש תוספות ממש מעניינות למסד הנתונים, למרות שאלו נוספו "על הדרך":

  1. תמיכה טובה יותר ב Audit ו trace – יש עוד יותר תעוד על מי ביצע איזו פעולה באיזה שלב ובאיזו צורה (נשמר במסד הנתונים עצמו כמו תמיד), כולל בזמן אמת, וכן אפשרי לצפייה פר חיבור (סשן) ספציפי.
  2. יכולת של משתמש ספציפי לדעת מה הוא עשה (עבודה עם audit).
  3. האצלת סמכויות של SYSDBA. כאשר המשתמש יכול במסד נתונים ספציפים לתת חלק מיכולותיו למשתמשים אחרים בהתאם לצורך.
  4. ביטול חיבורים בצורה אסינכרונית
  5. נוספה תמיכה לעבודה ב Regex עם תחביר של SIMILAR TO
  6. ניתן לשנות (ALTER TABLE) שדה שהוא Computed By
  7. טרנזאקציות אוטונומיות בPSQL (כלומר התחביר של טריגרים, Stored Procedures וכו')
  8. תמיכה טובה יותר לגישה של Stored Procedure תחת View
  9. תמיכה של GRANTED BY וGRANTED TO (וגם של REVOKE) בשביל לספק הרשאות עבור משתמשים אחרים (בדומה ל sudo ביוניקס).
  10. ביטול הרשאות כללי על ידי שימוש בתחביר של REVOKE ALL, ובכך לבטל בצורה מיידית את כל ההרשאות של משתמש מסויים
  11. תמיכה בתנאים של WHERE SOME_COL = ? OR ? IS NULL
  12. נוספה פונקציה חדשה עבור תמיכה בעבודה עם UUID התואמת לRFC4122
  13. נוספה האפשרות להוסיף למספר שלם בגודל 32 ו64 ביט, מספר הקסה דצימלי בצורה מילולית.
  14. נוספה יכולת הגדרה עבור ברירת מחדל של מסד הנתונים עצמו לCOLLATE.
  15. שינוי COLLATE על בסיס סוג קידוד השפה
  16. gbak משחזר טוב יותר קידוד שפה, כאשר הדגל של הקידוד לא קיים בגרסאות ישנות יותר
  17. תמיכה בחיבורים למסד נתונים אחר, גם אם הוא לא נמצא פיזית בשרת שאנחנו שייכים אליו כחלק משאילתת SQL.

זה כמובן לא הכל, ויש הרבה מה להרחיב עוד בנושא, אבל אפשר לראות שיש הרבה תוספות ושינויים מרעננים במסד הנתונים, בדרך לגרסה 3.0.

להכרזה הרשמית: http://www.firebirdsql.org/pop/pop_pressRelease25.html

להורדה: http://www.firebirdsql.org/index.php?op=files&id=engine_250