Subject | Re: [firebird-support] Procedures and Triggers missing |
---|---|
Author | Helen Borrie |
Post date | 2015-06-25T07:27:07Z |
At 08:20 a.m. 25/06/2015, Chris Valentine chrisvalentinemail@... [firebird-support] wrote:
How? Well, you are looking at a malevolent practitioner here. That person would need to have SYSDBA or Owner access to the tables and procedures and the means to connect to the server machine, e.g., Remote Desktop or equivalent, if off-site. Somebody on site with access to the local network would not even require that. S/he could query the system tables to find all the triggers and procedures and write an isql script to do the dirty deed with a series of CREATE OR ALTER statements. The script might be permanently on the network somewhere, running on a schedule from a batch or cron job; or the person may be logging in and running the script as and when s/he pleases.
When? Well, a small clue would be that the script would fail if any of the triggers, tables or procedures was in use...so it's possibly happening out of hours.
Who? a disgruntled former employee? a competitor who has access to your client's network? Skilled kids with after-hours access to the server?
Good luck with the forensics.
Helen Borrie, Support Consultant, IBPhoenix (Pacific)
Author of "The Firebird Book" and "The Firebird Book Second Edition"
http://www.firebird-books.net
__________________________________________________________________
>We have a Firebird 1.5.6 database that we have been using for several years. Many clients use it, there are rarely any issues.Why? No. There is no way that any PSQL modules can spontaneously disappear or be replaced with no-op code.
>
>One particular client, suddenly is missing triggers and procedures, seemingly with no cause.
>
>Procedures get replace with: Â Â BEGIN EXIT; END
>
>Triggers get replaced with: Â AS Declare variable I integer; BEGIN I = 0; END
>
>The database does not appear to be corrupt in anyway and validates fully with no issues. I have backuped/restored, replaced the missing procedures and returned to the client only to find out today the triggers/procedures are missing again.
>
>Can anyone enlighten me on why these might disappear, but not only disappear be replaced by empty procedures? Where can I look for the cause? My application does not alter the database DDL it only does CRUD type operations.
How? Well, you are looking at a malevolent practitioner here. That person would need to have SYSDBA or Owner access to the tables and procedures and the means to connect to the server machine, e.g., Remote Desktop or equivalent, if off-site. Somebody on site with access to the local network would not even require that. S/he could query the system tables to find all the triggers and procedures and write an isql script to do the dirty deed with a series of CREATE OR ALTER statements. The script might be permanently on the network somewhere, running on a schedule from a batch or cron job; or the person may be logging in and running the script as and when s/he pleases.
When? Well, a small clue would be that the script would fail if any of the triggers, tables or procedures was in use...so it's possibly happening out of hours.
Who? a disgruntled former employee? a competitor who has access to your client's network? Skilled kids with after-hours access to the server?
Good luck with the forensics.
Helen Borrie, Support Consultant, IBPhoenix (Pacific)
Author of "The Firebird Book" and "The Firebird Book Second Edition"
http://www.firebird-books.net
__________________________________________________________________