From bwotring at cisco.com Thu Nov 11 12:11:15 2004 From: bwotring at cisco.com (Brian Wotring) Date: Thu, 11 Nov 2004 10:11:15 -0700 Subject: [osiris-devel] removing features Message-ID: <41939D33.9050906@cisco.com> I am seriously considering removing all of the http code from the management console. This includes md_http.h, md_http.c, as well as the relavent code to handle the settings for http_host and http_port. The impact would be that it will not be possible to update the trusted database via a web browser. The suggested alternative is to turn on the auto-accept feature. I have a couple of reasons for removing this. First, it's problematic to support. Many people get hung up by firewalls, and email clients munging the URL. Second, it is a lot of code to handle the parsing of HTTP requests from the management daemon itself. The role of the management console is to manage streams of agent data, not act as a web server. Please speak up if there any major objections to this? -brian From wrp at voyagertec.com Thu Nov 11 12:36:02 2004 From: wrp at voyagertec.com (Bill Perkins) Date: Thu, 11 Nov 2004 12:36:02 -0500 (EST) Subject: [osiris-devel] removing features In-Reply-To: <41939D33.9050906@cisco.com> References: <41939D33.9050906@cisco.com> Message-ID: On Thu, 11 Nov 2004, Brian Wotring wrote: > > I am seriously considering removing all of the http code from the management > console. This includes md_http.h, md_http.c, as well as the relavent code to > handle the settings for http_host and http_port. > > The impact would be that it will not be possible to update the trusted > database via a web browser. The suggested alternative is to turn on the > auto-accept feature. > > I have a couple of reasons for removing this. First, it's problematic to > support. Many people get hung up by firewalls, and email clients munging the > URL. Second, it is a lot of code to handle the parsing of HTTP requests from > the management daemon itself. The role of the management console is to > manage streams of agent data, not act as a web server. > > Please speak up if there any major objections to this? > > -brian > _______________________________________________ > osiris-devel mailing list > osiris-devel at lists.shmoo.com > https://lists.shmoo.com/mailman/listinfo/osiris-devel turning on auto-accept would defeat the purpose of monitoring changes on the managed systems, would it not? I really wouldn't like for the changes to be blindly accepted before looking them over to ensure somebody didn't sneak something bad onto my systems. I use the web interface for convenience (my browser has a large window, but my email window is usually quite small; the long lines are more readable in a large window). True, it's kind of silly to have a web server built in, but a plain web interface is useful. -- Bill Perkins Voyager Technologies From friz at godshell.com Thu Nov 11 17:16:44 2004 From: friz at godshell.com (Jason 'XenoPhage' Frisvold) Date: Thu, 11 Nov 2004 17:16:44 -0500 Subject: [osiris-devel] removing features In-Reply-To: <41939D33.9050906@cisco.com> References: <41939D33.9050906@cisco.com> Message-ID: <4193E4CC.6050808@godshell.com> Brian Wotring wrote: > > I am seriously considering removing all of the http code from the > management console. This includes md_http.h, md_http.c, as well as > the relavent code to handle the settings for http_host and http_port. > > The impact would be that it will not be possible to update the trusted > database via a web browser. The suggested alternative is to turn on > the auto-accept feature. Well, I don't think I will ever turn on auto-accept... I'd rather have osiris bother me with emails than to possibly miss an ultra-important email... > I have a couple of reasons for removing this. First, it's problematic > to support. Many people get hung up by firewalls, and email clients > munging the URL. Second, it is a lot of code to handle the parsing of > HTTP requests from the management daemon itself. The role of the > management console is to manage streams of agent data, not act as a > web server. Agreed. Having a webserver can be problematic at best. How about some sort of PHP script that can be installed on the managment machine? Let the user deal with the webserver bits, and the php script can do everything else. In fact, it might even be possible to put more functionality into the script, allowing a user to add new hosts, edit configs, etc. via the web.. ? > Please speak up if there any major objections to this? Not *really* ... It's definitely convenient, but if it's that much of a problem, I can stay with 4.0.6 .... > -brian -- --------------------------- Jason 'XenoPhage' Frisvold Engine / Technology Programmer friz at godshell.com RedHat Certified - RHCE # 803004140609871 MySQL Pro Certified - ID# 207171862 MySQL Core Certified - ID# 205982910 --------------------------- "Something mysterious is formed, born in the silent void. Waiting alone and unmoving, it is at once still and yet in constant motion. It is the source of all programs. I do not know its name, so I will call it the Tao of Programming." From Alexei_Roudnev at exigengroup.com Thu Nov 11 18:30:34 2004 From: Alexei_Roudnev at exigengroup.com (Alexei_Roudnev) Date: Thu, 11 Nov 2004 15:30:34 -0800 Subject: [osiris-devel] removing features References: <41939D33.9050906@cisco.com> Message-ID: <1d8001c4c846$716d7040$2c7f300a@sjc.exigengroup.com> This is one of MOST IMPORTANT features of osiris. It means, that 50% of osiris functionality will be lost. HTTPS code have a problems, it is true; may be, we should take some existing _simple_ https server and use it's code. Anyway, it should not cause a problems (support), because you can always state that it should work thru local network only and require accurate dns naming. In reality, http acces is the only good way to get reports and allow people really confirm changes - we can not learn application engineer (who should confirm changes in his servers) to use CLI system (such as 'osiris' console). So, removing http makes osiris useless except if we use 'auto-approval' mode , which means lower level of attention to the changes (it is good mode, but not for all cases). ----- Original Message ----- From: "Brian Wotring" To: Sent: Thursday, November 11, 2004 9:11 AM Subject: [osiris-devel] removing features > > I am seriously considering removing all of the http code from the > management console. This includes md_http.h, md_http.c, as well as the > relavent code to handle the settings for http_host and http_port. > > The impact would be that it will not be possible to update the trusted > database via a web browser. The suggested alternative is to turn on the > auto-accept feature. > > I have a couple of reasons for removing this. First, it's problematic > to support. Many people get hung up by firewalls, and email clients > munging the URL. Second, it is a lot of code to handle the parsing of > HTTP requests from the management daemon itself. The role of the > management console is to manage streams of agent data, not act as a web > server. > > Please speak up if there any major objections to this? > > -brian > _______________________________________________ > osiris-devel mailing list > osiris-devel at lists.shmoo.com > https://lists.shmoo.com/mailman/listinfo/osiris-devel > From Alexei_Roudnev at exigengroup.com Thu Nov 11 18:46:31 2004 From: Alexei_Roudnev at exigengroup.com (Alexei_Roudnev) Date: Thu, 11 Nov 2004 15:46:31 -0800 Subject: [osiris-devel] removing features References: <41939D33.9050906@cisco.com> Message-ID: <1d8601c4c848$abf9eca0$2c7f300a@sjc.exigengroup.com> As I said - I prefer 100% WEB console, isntead of having CLI 'osiris' . For example, I need to see change history for particular host, set up Automatic confirm on/off, see 'lsl -l' ovber the data base. And I can not learn admins and managers to use primitive 'cli' interface, which may be fine for configuration, but is not proper tool for 'ops'. ----- Original Message ----- From: "Bill Perkins" To: ; "Osiris Developers" Sent: Thursday, November 11, 2004 9:36 AM Subject: Re: [osiris-devel] removing features > On Thu, 11 Nov 2004, Brian Wotring wrote: > > > > > I am seriously considering removing all of the http code from the management > > console. This includes md_http.h, md_http.c, as well as the relavent code to > > handle the settings for http_host and http_port. > > > > The impact would be that it will not be possible to update the trusted > > database via a web browser. The suggested alternative is to turn on the > > auto-accept feature. > > > > I have a couple of reasons for removing this. First, it's problematic to > > support. Many people get hung up by firewalls, and email clients munging the > > URL. Second, it is a lot of code to handle the parsing of HTTP requests from > > the management daemon itself. The role of the management console is to > > manage streams of agent data, not act as a web server. > > > > Please speak up if there any major objections to this? > > > > -brian > > _______________________________________________ > > osiris-devel mailing list > > osiris-devel at lists.shmoo.com > > https://lists.shmoo.com/mailman/listinfo/osiris-devel > > turning on auto-accept would defeat the purpose of monitoring changes on > the managed systems, would it not? I really wouldn't like for the changes > to be blindly accepted before looking them over to ensure somebody didn't > sneak something bad onto my systems. I use the web interface for > convenience (my browser has a large window, but my email window is usually > quite small; the long lines are more readable in a large window). True, > it's kind of silly to have a web server built in, but a plain web > interface is useful. > > -- > Bill Perkins > Voyager Technologies > _______________________________________________ > osiris-devel mailing list > osiris-devel at lists.shmoo.com > https://lists.shmoo.com/mailman/listinfo/osiris-devel > From spike at indra.com Thu Nov 11 19:07:37 2004 From: spike at indra.com (Spike Ilacqua) Date: Thu, 11 Nov 2004 17:07:37 -0700 Subject: [osiris-devel] removing features In-Reply-To: <1d8601c4c848$abf9eca0$2c7f300a@sjc.exigengroup.com> References: <41939D33.9050906@cisco.com> <1d8601c4c848$abf9eca0$2c7f300a@sjc.exigengroup.com> Message-ID: <4193FEC9.6090401@indra.com> Personally I use the CLI interface, but I think Alexei does have a valid point, your average user is going to prefer a pretty Web interface. That said, I don't think the management console should be a Web server. Let Web servers be Web servers, and Osiris be Osiris. Create a CGI that can be installed on an existing Web server. That way you don't have to be writting HTTP code and if the user can't get to the Web server, than it's a problem with the Web server, not Osiris. ->Spike From Alexei_Roudnev at exigengroup.com Thu Nov 11 20:40:47 2004 From: Alexei_Roudnev at exigengroup.com (Alexei_Roudnev) Date: Thu, 11 Nov 2004 17:40:47 -0800 Subject: [osiris-devel] removing features References: <41939D33.9050906@cisco.com> <1d8601c4c848$abf9eca0$2c7f300a@sjc.exigengroup.com> <4193FEC9.6090401@indra.com> Message-ID: <1e5d01c4c858$a2366e90$2c7f300a@sjc.exigengroup.com> I use CLI for configuration. But I _DO NOT APPROVE_ changes usually - every group of servers sent messages to the group of 'xxx-change: ' mail list, which includes me, our manager and solution chief engineer. And _THEY_ do approve this changes. They can not use CLI, not a chance. I never use CLI for change approval (which I have 2 - 40 / day - for example, I approved 40 changes yesterday when we removed old account from all unix servers - local passwords. It is absolutely impossible to use CLI for such things). Of course, I do not bother_how_ EB and osiris interacts, but what's the problem with http -it works, it _do not require 100% compatibility_ - you can apply any client restrictions - because it is _technical management web service_. ----- Original Message ----- From: "Spike Ilacqua" To: "Osiris Developers" Cc: Sent: Thursday, November 11, 2004 4:07 PM Subject: Re: [osiris-devel] removing features > Personally I use the CLI interface, but I think Alexei does have a valid > point, your average user is going to prefer a pretty Web interface. > > That said, I don't think the management console should be a Web server. > Let Web servers be Web servers, and Osiris be Osiris. Create a CGI > that can be installed on an existing Web server. That way you don't > have to be writting HTTP code and if the user can't get to the Web > server, than it's a problem with the Web server, not Osiris. > > ->Spike > _______________________________________________ > osiris-devel mailing list > osiris-devel at lists.shmoo.com > https://lists.shmoo.com/mailman/listinfo/osiris-devel > From Alexei_Roudnev at exigengroup.com Thu Nov 11 21:30:38 2004 From: Alexei_Roudnev at exigengroup.com (Alexei_Roudnev) Date: Thu, 11 Nov 2004 18:30:38 -0800 Subject: [osiris-devel] removing features References: <41939D33.9050906@cisco.com> <1d8601c4c848$abf9eca0$2c7f300a@sjc.exigengroup.com> <4193FEC9.6090401@indra.com> Message-ID: <1e8901c4c85f$9937dd40$2c7f300a@sjc.exigengroup.com> Problem 1 - there is not way to create CGI for osiris console. Problem 2 - such CGI will be highly system dependent and will reproduce existing (in osirismd) functionality - what for? For reports, I agree with such approach - osiris can generate static web files, available by standard web server. PS. Notice, that 90% of modern tools use web access, and most of them just implements primitive web server inside. ----- Original Message ----- From: "Spike Ilacqua" To: "Osiris Developers" Cc: Sent: Thursday, November 11, 2004 4:07 PM Subject: Re: [osiris-devel] removing features > Personally I use the CLI interface, but I think Alexei does have a valid > point, your average user is going to prefer a pretty Web interface. > > That said, I don't think the management console should be a Web server. > Let Web servers be Web servers, and Osiris be Osiris. Create a CGI > that can be installed on an existing Web server. That way you don't > have to be writting HTTP code and if the user can't get to the Web > server, than it's a problem with the Web server, not Osiris. > > ->Spike > _______________________________________________ > osiris-devel mailing list > osiris-devel at lists.shmoo.com > https://lists.shmoo.com/mailman/listinfo/osiris-devel > From brian at shmoo.com Thu Nov 11 22:28:59 2004 From: brian at shmoo.com (Brian Wotring) Date: Thu, 11 Nov 2004 20:28:59 -0700 Subject: [osiris-devel] removing features In-Reply-To: <1e8901c4c85f$9937dd40$2c7f300a@sjc.exigengroup.com> References: <41939D33.9050906@cisco.com> <1d8601c4c848$abf9eca0$2c7f300a@sjc.exigengroup.com> <4193FEC9.6090401@indra.com> <1e8901c4c85f$9937dd40$2c7f300a@sjc.exigengroup.com> Message-ID: <41942DFB.3000401@shmoo.com> I received a lot more response from others offline, all objecting to the removal of this feature; I guess it stays. I'm glad I asked. Thanks for the feedback :) Alexei_Roudnev wrote: > Problem 1 - there is not way to create CGI for osiris console. > Problem 2 - such CGI will be highly system dependent and will reproduce > existing (in osirismd) functionality - what for? > > For reports, I agree with such approach - osiris can generate static web > files, available by standard web server. > > PS. Notice, that 90% of modern tools use web access, and most of them just > implements primitive web server inside. > > ----- Original Message ----- > From: "Spike Ilacqua" > To: "Osiris Developers" > Cc: > Sent: Thursday, November 11, 2004 4:07 PM > Subject: Re: [osiris-devel] removing features > > > >>Personally I use the CLI interface, but I think Alexei does have a valid >>point, your average user is going to prefer a pretty Web interface. >> >>That said, I don't think the management console should be a Web server. >> Let Web servers be Web servers, and Osiris be Osiris. Create a CGI >>that can be installed on an existing Web server. That way you don't >>have to be writting HTTP code and if the user can't get to the Web >>server, than it's a problem with the Web server, not Osiris. >> >>->Spike >>_______________________________________________ >>osiris-devel mailing list >>osiris-devel at lists.shmoo.com >>https://lists.shmoo.com/mailman/listinfo/osiris-devel >> > > > _______________________________________________ > osiris-devel mailing list > osiris-devel at lists.shmoo.com > https://lists.shmoo.com/mailman/listinfo/osiris-devel > From Alexei_Roudnev at exigengroup.com Thu Nov 11 23:47:48 2004 From: Alexei_Roudnev at exigengroup.com (Alexei_Roudnev) Date: Thu, 11 Nov 2004 20:47:48 -0800 Subject: [osiris-devel] removing features References: <41939D33.9050906@cisco.com> <1d8601c4c848$abf9eca0$2c7f300a@sjc.exigengroup.com> <4193FEC9.6090401@indra.com><1e8901c4c85f$9937dd40$2c7f300a@sjc.exigengroup.com> <41942DFB.3000401@shmoo.com> Message-ID: <1ea001c4c872$c24698d0$2c7f300a@sjc.exigengroup.com> Q. is not _to stay or to remove_. Unfortunately, osiris interface today is a mixture of primitive 'command line' technology (which is difficult to use even for configuration) and primitive WEB interface which can only show list of changes. A huge number of possible options stays behind, because osiris as a system is excellent, with excellent design , good scanning agent, great simplicity. But I can not: - see report of the system status - servers, date of change, number of changes, sheduled scans, last scan time, etc... - browse old database, for example, see list of files (sizes, dates, owners) before change (for forencic purpose, for example); - deliver every day ops (approvals, adding new servers, changing e-mail and schedule) to tier-1 person (again, because of primitive interface). On the other hand, I do agree - merging http server and osirismd server is dangerous, and does not aloow to expand it easily (I mean - expand web interface). So, if you want to remove http daemon from osirismd (which is not crazy idea - it have it's own reasons), we need some way to write simple web add-ons first, then rewrite existing functionality on somethimg like cgi or php or python, then remove http functionality. Other way is to adapt http interface for everything, so simplifying administrative interface. But it can require more complicated http parser, this is correct. Alexei Roudnev ----- Original Message ----- From: "Brian Wotring" To: "Osiris Developers" Sent: Thursday, November 11, 2004 7:28 PM Subject: Re: [osiris-devel] removing features > > I received a lot more response from others offline, all objecting to the > removal of this feature; I guess it stays. > > I'm glad I asked. Thanks for the feedback :) > > Alexei_Roudnev wrote: > > Problem 1 - there is not way to create CGI for osiris console. > > Problem 2 - such CGI will be highly system dependent and will reproduce > > existing (in osirismd) functionality - what for? > > > > For reports, I agree with such approach - osiris can generate static web > > files, available by standard web server. > > > > PS. Notice, that 90% of modern tools use web access, and most of them just > > implements primitive web server inside. > > > > ----- Original Message ----- > > From: "Spike Ilacqua" > > To: "Osiris Developers" > > Cc: > > Sent: Thursday, November 11, 2004 4:07 PM > > Subject: Re: [osiris-devel] removing features > > > > > > > >>Personally I use the CLI interface, but I think Alexei does have a valid > >>point, your average user is going to prefer a pretty Web interface. > >> > >>That said, I don't think the management console should be a Web server. > >> Let Web servers be Web servers, and Osiris be Osiris. Create a CGI > >>that can be installed on an existing Web server. That way you don't > >>have to be writting HTTP code and if the user can't get to the Web > >>server, than it's a problem with the Web server, not Osiris. > >> > >>->Spike > >>_______________________________________________ > >>osiris-devel mailing list > >>osiris-devel at lists.shmoo.com > >>https://lists.shmoo.com/mailman/listinfo/osiris-devel > >> > > > > > > _______________________________________________ > > osiris-devel mailing list > > osiris-devel at lists.shmoo.com > > https://lists.shmoo.com/mailman/listinfo/osiris-devel > > > > _______________________________________________ > osiris-devel mailing list > osiris-devel at lists.shmoo.com > https://lists.shmoo.com/mailman/listinfo/osiris-devel > From dfetter at pdx.edu Fri Nov 12 13:26:53 2004 From: dfetter at pdx.edu (David M. Fetter) Date: Fri, 12 Nov 2004 10:26:53 -0800 Subject: [osiris-devel] removing features In-Reply-To: <41939D33.9050906@cisco.com> References: <41939D33.9050906@cisco.com> Message-ID: <1100284013.5596.7.camel@thoth.oit.pdx.edu> Personally, I'm not sure I like the http bit anyway. It seems like a nasty potential for a security hole in a piece of security software. However, that said, I know that several of the folks here are kind of looking forward to the ease of clicking on links in an email to acknowledge the changes, etc. It would be nice if there was another alternative besides auto-accept. I would like to see user access control a bit more segmented. Like an admin priv setting and a user priv setting for starters. Then perhaps making it so you can allow specific users to only work with specific hosts. In any case, I don't think striping it out would make our setup of it too much different. On Thu, 2004-11-11 at 10:11 -0700, Brian Wotring wrote: > I am seriously considering removing all of the http code from the > management console. This includes md_http.h, md_http.c, as well as the > relavent code to handle the settings for http_host and http_port. > > The impact would be that it will not be possible to update the trusted > database via a web browser. The suggested alternative is to turn on the > auto-accept feature. > > I have a couple of reasons for removing this. First, it's problematic > to support. Many people get hung up by firewalls, and email clients > munging the URL. Second, it is a lot of code to handle the parsing of > HTTP requests from the management daemon itself. The role of the > management console is to manage streams of agent data, not act as a web > server. > > Please speak up if there any major objections to this? > > -brian > _______________________________________________ > osiris-devel mailing list > osiris-devel at lists.shmoo.com > https://lists.shmoo.com/mailman/listinfo/osiris-devel -- David M. Fetter - UNIX Systems Administrator Portland State University - www.oit.pdx.edu -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.shmoo.com/pipermail/osiris-devel/attachments/20041112/1662ade6/attachment.pgp From Alexei_Roudnev at exigengroup.com Fri Nov 12 14:10:02 2004 From: Alexei_Roudnev at exigengroup.com (Alexei Roudnev) Date: Fri, 12 Nov 2004 11:10:02 -0800 Subject: [osiris-devel] removing features References: <41939D33.9050906@cisco.com> <1100284013.5596.7.camel@thoth.oit.pdx.edu> Message-ID: <025c01c4c8eb$38099b80$980ea8c0@exigengroup.com> It is not a security hole - vice versa, it alows me do not provide direct access to the secure environment, restricting access to http only (and you can do nothing wrong using it - even if I make it open public, you can not compromise osiris having http access). Vice versa, if I have not itr, I need to allow more people direct acces to the secure server or to osirismd server , which compromise network security. More access is ofnet _more_ security, not _less_ - depending on the case. Here is the case, when http access improves overall security (by separating every-days ops access and administration access). ----- Original Message ----- From: "David M. Fetter" To: ; "Osiris Developers" Sent: Friday, November 12, 2004 10:26 AM Subject: Re: [osiris-devel] removing features > _______________________________________________ > osiris-devel mailing list > osiris-devel at lists.shmoo.com > https://lists.shmoo.com/mailman/listinfo/osiris-devel From thelists at gmail.com Tue Nov 23 17:25:04 2004 From: thelists at gmail.com (mailing lists) Date: Tue, 23 Nov 2004 17:25:04 -0500 Subject: [osiris-devel] Agent Architecture question Message-ID: <9f7f8ab5041123142556d89c62@mail.gmail.com> This question pertains to a particular architectural issues with the scan agent component of Osiris. The knowledge I have was gathered solely from the online documentation and through perusal of the mailing lists. It appears that the scan agent component listens on a TCP port (2265) for incoming connections from the management console. Presumably all conversations between these pieces take place within this connection (encrypted). Assuming this is all correct; What was the reasoning for having an open port on all agent machines versus one open port on the management system? Admittedly, it is simple enough to firewall off this port with little to no consequence to other activities, but I'm not fond of having any more open ports on my systems. Could the communication not have been done with a client push / pull to the management console instead? Is it possible to turn off the listening feature of the agent component and force a push within the current framework? I would tend to agree that letting the management piece initiate the conversations lends itself to a more real-time reporting environment, but what are the trade offs? That said, I'm looking forward to giving Osiris a whirl. It's good to see solutions out there that are open. From brian at shmoo.com Wed Nov 24 01:15:53 2004 From: brian at shmoo.com (Brian Wotring) Date: Tue, 23 Nov 2004 23:15:53 -0700 Subject: [osiris-devel] Agent Architecture question In-Reply-To: <9f7f8ab5041123142556d89c62@mail.gmail.com> References: <9f7f8ab5041123142556d89c62@mail.gmail.com> Message-ID: <41A42719.4010904@shmoo.com> > What was the reasoning for having an open port on all agent machines > versus one open port on the management system? Admittedly, it is > simple enough to firewall off this port with little to no consequence > to other activities, but I'm not fond of having any more open ports on > my systems. A few reasons. First, it's a lot easier to manage. If you decide to change scheduling, check status of hosts, update configs, or whatever, you can operate on many hosts from a single interface. Otherwise, you would have to perform these operations from each managed host. Second, it made more sense (to me) in the beginning to initiate the connections from the more trusted system, as opposed to receiving them. The management console is critical in that it is to be a secure store for all of the monitoring data. If this is compromised, the whole system is almost useless. Third, if the agents initiated connections, it could be argued that the management console would have a harder time detecting that an agent didn't scan when it was supposed to. That is, it may be easier for a broken agent to go unnoticed. There may be other reasos, but these are the main ones that were considered during design and development. This isn't to say that doing it the other way is wrong, it's just not the way Osiris was built. > Could the communication not have been done with a client push / pull > to the management console instead? Is it possible to turn off the > listening feature of the agent component and force a push within the > current framework? No, not really. You could just run a management console on each monitored host, tripwire style, but that doesn't scale very well. -brian From Alexei_Roudnev at exigengroup.com Wed Nov 24 13:17:00 2004 From: Alexei_Roudnev at exigengroup.com (Alexei_Roudnev) Date: Wed, 24 Nov 2004 10:17:00 -0800 Subject: [osiris-devel] Agent Architecture question References: <9f7f8ab5041123142556d89c62@mail.gmail.com> <41A42719.4010904@shmoo.com> Message-ID: <04f601c4d251$cacb46c0$2c7f300a@sjc.exigengroup.com> This port is open only when managemenbt system is not connected to the agent. And it is not any problem to restrict this port on firewall, as you wish. Remembering that osirismd server is usually in high security zone, and agents are spread around, current approach is even more secure vs. open port on central server (which I must to allow access from all systems around). ----- Original Message ----- From: "Brian Wotring" To: "mailing lists" ; "Osiris Developers" Sent: Tuesday, November 23, 2004 10:15 PM Subject: Re: [osiris-devel] Agent Architecture question > > > What was the reasoning for having an open port on all agent machines > > versus one open port on the management system? Admittedly, it is > > simple enough to firewall off this port with little to no consequence > > to other activities, but I'm not fond of having any more open ports on > > my systems. > > A few reasons. First, it's a lot easier to manage. If you decide to > change scheduling, check status of hosts, update configs, or whatever, > you can operate on many hosts from a single interface. Otherwise, you > would have to perform these operations from each managed host. > > Second, it made more sense (to me) in the beginning to initiate the > connections from the more trusted system, as opposed to receiving them. > The management console is critical in that it is to be a secure store > for all of the monitoring data. If this is compromised, the whole > system is almost useless. > > Third, if the agents initiated connections, it could be argued that the > management console would have a harder time detecting that an agent > didn't scan when it was supposed to. That is, it may be easier for a > broken agent to go unnoticed. > > There may be other reasos, but these are the main ones that were > considered during design and development. This isn't to say that doing > it the other way is wrong, it's just not the way Osiris was built. > > > Could the communication not have been done with a client push / pull > > to the management console instead? Is it possible to turn off the > > listening feature of the agent component and force a push within the > > current framework? > > No, not really. You could just run a management console on each > monitored host, tripwire style, but that doesn't scale very well. > > -brian > > > > _______________________________________________ > osiris-devel mailing list > osiris-devel at lists.shmoo.com > https://lists.shmoo.com/mailman/listinfo/osiris-devel > From thelists at gmail.com Tue Nov 30 09:49:54 2004 From: thelists at gmail.com (mailing lists) Date: Tue, 30 Nov 2004 09:49:54 -0500 Subject: [osiris-devel] Agent Architecture question In-Reply-To: <41A42719.4010904@shmoo.com> References: <9f7f8ab5041123142556d89c62@mail.gmail.com> <41A42719.4010904@shmoo.com> Message-ID: <9f7f8ab5041130064926b69156@mail.gmail.com> > > > What was the reasoning for having an open port on all agent machines > > versus one open port on the management system? Admittedly, it is > > simple enough to firewall off this port with little to no consequence > > to other activities, but I'm not fond of having any more open ports on > > my systems. > > A few reasons. First, it's a lot easier to manage. If you decide to > change scheduling, check status of hosts, update configs, or whatever, > you can operate on many hosts from a single interface. Otherwise, you > would have to perform these operations from each managed host. I like the idea of a centralized management console; no argument there, though I'm not sure server->client push is the only way to implement it. > Second, it made more sense (to me) in the beginning to initiate the > connections from the more trusted system, as opposed to receiving them. > The management console is critical in that it is to be a secure store > for all of the monitoring data. If this is compromised, the whole > system is almost useless. > > Third, if the agents initiated connections, it could be argued that the > management console would have a harder time detecting that an agent > didn't scan when it was supposed to. That is, it may be easier for a > broken agent to go unnoticed. However, this makes Osiris plausible only in static environments. I'm not arguing that this is a bad thing -- change management and intrusion detection of servers is a serious issue that requires more attention than I think most are willing to give. What this doesn't lend well to is the idea of monitoring dynamic environments (at least not that I can see). Being able to slap an agent on every desktop in a corporate environment to detect modification of critical system files or insertion of prohibited applications would be immensely useful. Of course, this is generally all possible without the introduction of the Osiris agent, but I think it lends itself well to the framework of the application. Is it, through some hack or unnamed configuration setting, possible to monitor hosts with dynamically assigned IPs? Are there plans to introduce this feature in the future? With PKI, this functionality shouldn't necessitate any less integrity than the present. > There may be other reasos, but these are the main ones that were > considered during design and development. This isn't to say that doing > it the other way is wrong, it's just not the way Osiris was built. > > > Could the communication not have been done with a client push / pull > > to the management console instead? Is it possible to turn off the > > listening feature of the agent component and force a push within the > > current framework? > > No, not really. You could just run a management console on each > monitored host, tripwire style, but that doesn't scale very well. > I'm not disagreeing with the centralized management console. That feature is a requirement in a mature intrusion detection system intended for any mid-to-large scale deployment. In fact, I prefer a console that can be accessed through a secure terminal environment as opposed to a platform-dependant GUI (though I could settle for a webpage, which, as a feature of Osiris, I haven't yet checked out). > -brian > > -bill From bwotring at cisco.com Tue Nov 30 11:06:20 2004 From: bwotring at cisco.com (Brian Wotring) Date: Tue, 30 Nov 2004 09:06:20 -0700 Subject: [osiris-devel] Agent Architecture question In-Reply-To: <9f7f8ab5041130064926b69156@mail.gmail.com> References: <9f7f8ab5041123142556d89c62@mail.gmail.com> <41A42719.4010904@shmoo.com> <9f7f8ab5041130064926b69156@mail.gmail.com> Message-ID: <41AC9A7C.7020402@cisco.com> No, it is not currently possible to have the agents initiate scans. The current implementation is very simple. Having agents initiate scans increases the complexity, probably more than most would consider worth it. I admit that the actual implementation changes to the console and the agent to support this are minor. The real problem here is how to deal with authenticating the agents. The only way that I know of to do this would be to begin issuing client certificates to the agents. This would be a nightmare to manage, at least. As far as addressing your concerns about monitoring dynamic hosts, a simple way to do this is with dynamic DNS. I hope this helps. -brian mailing lists wrote: >>Second, it made more sense (to me) in the beginning to initiate the >>connections from the more trusted system, as opposed to receiving them. >> The management console is critical in that it is to be a secure store >>for all of the monitoring data. If this is compromised, the whole >>system is almost useless. >> >>Third, if the agents initiated connections, it could be argued that the >>management console would have a harder time detecting that an agent >>didn't scan when it was supposed to. That is, it may be easier for a >>broken agent to go unnoticed. > > > However, this makes Osiris plausible only in static environments. I'm > not arguing that this is a bad thing -- change management and > intrusion detection of servers is a serious issue that requires more > attention than I think most are willing to give. What this doesn't > lend well to is the idea of monitoring dynamic environments (at least > not that I can see). Being able to slap an agent on every desktop in > a corporate environment to detect modification of critical system > files or insertion of prohibited applications would be immensely > useful. Of course, this is generally all possible without the > introduction of the Osiris agent, but I think it lends itself well to > the framework of the application. > > Is it, through some hack or unnamed configuration setting, possible to > monitor hosts with dynamically assigned IPs? Are there plans to > introduce this feature in the future? With PKI, this functionality > shouldn't necessitate any less integrity than the present. > > >>There may be other reasos, but these are the main ones that were >>considered during design and development. This isn't to say that doing >>it the other way is wrong, it's just not the way Osiris was built. >> >> >>>Could the communication not have been done with a client push / pull >>>to the management console instead? Is it possible to turn off the >>>listening feature of the agent component and force a push within the >>>current framework? >> >>No, not really. You could just run a management console on each >>monitored host, tripwire style, but that doesn't scale very well. >> > > > I'm not disagreeing with the centralized management console. That > feature is a requirement in a mature intrusion detection system > intended for any mid-to-large scale deployment. In fact, I prefer a > console that can be accessed through a secure terminal environment as > opposed to a platform-dependant GUI (though I could settle for a > webpage, which, as a feature of Osiris, I haven't yet checked out).