RE: firewall logging
On Wed, 12 Jun 2002, Ben Nagy wrote: level) and a tamper-evident log auditor. [1] For other OS's - we need to have indelible log generation. Simply sending those messages out as Let's not forget that the OS running the services may not need to be the only OS running (Don't know how much UML and pico kernel stuff you've looked at in this context...) they occur to a syslog server may be enough for some people, although we risk someone killing the syslog process as their first action. Some folks attach line printers to serial ports for this reason. Self contained logs on most general purpose OS's must obviously be taken with a pinch of salt, and ditto any system that uses batched or on-demand transfers. We could, in a virtual or layered multi-kernel environement (and this doesn't directly address the insider stuff, but may be interesting[1] for the attacker-compromise stuff do some transaction journaling on the real/host side that replays logs and potentially machine actions against the virutal/guest infrastructure. At the collector: The collector needs to be as secure as possible, obviously. I guess that would mean it should be single purpose. Denial of Service, which is often only an annoyance against normal systems can be a critical security issue against a log collector, so collectors need to be as robust as possible in that regard. Unfortunately the I'm not sure- it may be that a DoS against the collector is indicative of an event of a magnitude that obliviates the need for logs, and more importantly you can trade architecture for robustness (out of band logging for instance could happen to a box you wouldn't put on the data network. new doors for DoS. Third party admin, as Bernd suggests, may be good, but unless we're up to scratch on the other two fronts we still don't win against an internal attacker, and if it's only maintaining complete We may win against internal attackers in other ways (video, workstation monitoring, other-group network monitoring...) so let's not limit solutions to a single point of information. And I _still_ say that this is not one of the nuts that is best turned by the PKI monkey-wrench. Agreed. Paul - Paul D. Robertson My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact. -- Firewalls mailing list - [ [EMAIL PROTECTED] ] To unsubscribe: http://www.isc.org/services/public/lists/firewalls.html
RE: firewall logging
Agreed. The way we are doing the binary logging is simply raising the bar. That is why I avoided the term Tamperproof and suggested that the whole box would need analysis, not just the log files. Many other factors of the OS with the MLS MAC determine the overall authenticity of the logs. The main point is, of all the leading FWs I've seen, no one seems to be taking similar extensive measures. Most of them are simple, editable text logs. Anyone know of others that are NOT using text? erik _ Erik Elsasser System Engineering CyberGuard Corporation Northeast Region -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ben Nagy Sent: Wednesday, June 12, 2002 5:07 AM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: RE: firewall logging Importance: High You tell me how the log auditing app verifies the logs and I'll tell you how to subvert it. 8) While it's true that it protects against naiive log tampering, the app itself must be vulnerable to attack. Let's say, for the sake of argument, that it stores, against each entry, a SHA hash of (logfile + secret key) - yes that's a boring protocol and full of holes, but it works on the surface, since I can't fake logs because I can't reproduce the correct hash for my faked entry. In that faked up example, all I need to do is dig around in the binary for the logger program, rip out the key and away I go. Cyberguard gets points for its MAC code, which would make it really unlikely that an external attacker could ever get the right sort of access to do that - but here the attacker is internal and has full access to all the accounts on the box (plus physical access, if necessary, and I know that Cyberguard can run on standard x86 boxes - removing the disks and remounting them raw on the nearby linux box would be an obvious way to evade all the B level security). I'm sure that your mechanism is smarter than that, but I'm still asserting that it's just a bigger hurdle. Lots has been written about assembly/machine code obfuscation, and while it's possible to make things hard it's impossible to make them impossible. Cheers, -- Ben Nagy Network Security Specialist Mb: TBA PGP Key ID: 0x1A86E304 -- Firewalls mailing list - [ [EMAIL PROTECTED] ] To unsubscribe: http://www.isc.org/services/public/lists/firewalls.html
RE: firewall logging
In response to Ron DuFresne: Baltimore's UniCERT product is designed to be a root CA and the digital signing of the log entry by its agent software upon creation of the log entry will meets the legal requirements for providing trustworthiness. Baltimore also operates a commercial CA if an organization prefers not to build its own CA infrastructure. Note that best practice would have the log entry signed at its creation by an internal trusted program, such as Baltimore's agent code. While you could send the entry to an external notary service for signing, such an approach would allow a narrow window for also sending false entries for signing. The external approach is good for producing evidence of when something occurred and ensuring the integrity of the contents of the log entry once it is signed. The only way that I know to prove that the log entry is original, would be to sign it as part of its creation. The public key infrastructure (PKI) software to accomplish this exists. It would be ideal to have it signed via an API call from within the firewall's logging code. Marc Mandel At 11:21 AM 06/11/2002 -0500, Ron wrote: I think perhaps Ben was meaning, there's no verification his signed logs are any more trustworthy/courtworthy then the application/appliance you mention below would be. There's no 'verisign' as middleman to guarrentee his signature makes those logs, or the logs from SelectAccess which determines they are in fact something more then cheat signed. Unless I read you wrong here, even B T plc does not have this in place, or do they? Are they acting as a syslog CA? ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
On Tue, 11 Jun 2002, Marc E. Mandel wrote: In response to Ron DuFresne: Baltimore's UniCERT product is designed to be a root CA and the digital signing of the log entry by its agent software upon creation of the log entry will meets the legal requirements for providing trustworthiness. Baltimore also operates a commercial CA if an organization prefers not to build its own CA infrastructure. Note that best practice would have the log entry signed at its creation by an internal trusted program, such as Baltimore's agent code. While you could send the entry to an external notary service for signing, such an approach would allow a narrow window for also sending false entries for signing. The external approach is good for producing evidence of when something occurred and ensuring the integrity of the contents of the log entry once it is signed. The only way that I know to prove that the log entry is original, would be to sign it as part of its creation. The public key infrastructure (PKI) software to accomplish this exists. It would be ideal to have it signed via an API call from within the firewall's logging code. This still eaves me and/or my company in charge of all verification, there is no 3rd party involved to verify my work and signature and such, one might well do the same thing with home grown tools under openssl far cheaper? Thanks, Ron DuFresne ~~ Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation. -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
You tell me how the log auditing app verifies the logs and I'll tell you how to subvert it. 8) While it's true that it protects against naiive log tampering, the app itself must be vulnerable to attack. Let's say, for the sake of argument, that it stores, against each entry, a SHA hash of (logfile + secret key) - yes that's a boring protocol and full of holes, but it works on the surface, since I can't fake logs because I can't reproduce the correct hash for my faked entry. In that faked up example, all I need to do is dig around in the binary for the logger program, rip out the key and away I go. Cyberguard gets points for its MAC code, which would make it really unlikely that an external attacker could ever get the right sort of access to do that - but here the attacker is internal and has full access to all the accounts on the box (plus physical access, if necessary, and I know that Cyberguard can run on standard x86 boxes - removing the disks and remounting them raw on the nearby linux box would be an obvious way to evade all the B level security). I'm sure that your mechanism is smarter than that, but I'm still asserting that it's just a bigger hurdle. Lots has been written about assembly/machine code obfuscation, and while it's possible to make things hard it's impossible to make them impossible. Cheers, -- Ben Nagy Network Security Specialist Mb: TBA PGP Key ID: 0x1A86E304 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Wednesday, June 12, 2002 5:27 AM To: 'Ben Nagy'; [EMAIL PROTECTED] Subject: RE: firewall logging (I don't know that I want to post this on the list, since I'm a lurking FW vendor, but pass it on if you deem it fit.) Just as an FYI, The CyberGuard Firewalls have a binary encoded Tamper-Evident audit logging mechanism. It logs all kernel/network activity on the box for forensic evidence. I have tried to tamper with them at a hex level and when it runs into that section of the file, it warns of an inconsistency. I suppose that if the need arose, you'd have to submit the whole firewall for analysis, since the binary logs can only be read and extracted directly on the firewall and not on any other platform. Then there's that whole pesky chain of custody stuff... Much of this design was due to the heritage CyberGuard has as the first and only B1 rated firewall with B2 functionality builtin. I can explain more if you want. Regards, Erik _ Erik Elsasser System Engineering CyberGuard Corporation Northeast Region 908.638.3185-Phone 908.638.3190-Fax [EMAIL PROTECTED] www.cyberguard.com -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ben Nagy Sent: Tuesday, June 11, 2002 4:35 PM To: [EMAIL PROTECTED] Subject: RE: firewall logging OK, I need to be more explicit. I assert that nobody can describe to me a system that I cannot subvert for providing signed logs for use as evidence _without_ using a trusted third party in some manner.[...] ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ron DuFresne Sent: Wednesday, June 12, 2002 8:40 AM To: Marc E. Mandel Cc: [EMAIL PROTECTED] Subject: RE: firewall logging On Tue, 11 Jun 2002, Marc E. Mandel wrote: In response to Ron DuFresne: Baltimore's UniCERT product [will make you breakfast, wash your car and still have time to broker a peace deal between India and Pakistan] [...] The only way that I know to prove that the log entry is original, would be to sign it as part of its creation. The public key infrastructure (PKI) software to accomplish this exists. It would be ideal to have it signed via an API call from within the firewall's logging code. Warning - impending rant... I think this highlights one of the big myths of PKI. Signing things proves exactly ONE thing - that they were signed by someone/thing who knew the corresponding private key to whatever public key the signature is verified against. That's all. It doesn't prove originality, authenticity or any of that other fluff that vendors like to talk about. If your private key is compromised, you lose. If someone out there decides that they'll sign people's digital IDs for five bucks as long as they pass the scout's honour ID test, you lose. When someone copies the Private Key, Do Not Copy file from your firewall then they can sign logs just as convincingly as your Secure Signing API. Let me give you a scenario. I, Unlucky Ben, have just left XYZCorp after a disagreement with my manager. Said manager, Evil Bill, decides to have the last word. Having access to all the servers, Evil Bill extracts the private key from the Baltimore UniCERT server, just as it is in the process of whipping up another ham omlette. Armed with the private key, Evil Bill fakes up firewall logs showing me logging in via VPN to the firewall, accessing one of the servers and defacing the XYZCorp website with pictures of camels in sexual congress. Signing the logs with the private key, Evil Bill (who seems to know a lot about this sort of stuff for a manager) then replaces yesterdays logs on the collector with the new, signed logs, calls the FBI and off I go (apparently) to jail, where a large man called Susan wants to be my special friend. Unlucky. I'll put all this more simpy - every scheme to provide authenticated logs needs to use something secret. If it's onsite, then the secret isn't safe, and the logs just can't be trusted by an outsider. Sure, they're better than random logs in text, but if I were trying to prove beyond reasonable doubt (if that's still required in the US - lucky I'm not from the middle east... ;) that something happened based only on my logs, then I really should have major problems. (I don't want to get into the legal side of all this, since it's US centric, boring and time has shown that opinions from actual real life lawyers almost never turn up.) Cheers, -- Ben Nagy Network Security Specialist Mb: TBA PGP Key ID: 0x1A86E304 ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
Re: firewall logging
Ben Nagy wrote: [will make you breakfast, wash your car and still have time to broker a peace deal between India and Pakistan] ... extracts the private key from the Baltimore UniCERT server, just as it is in the process of whipping up another ham omlette Bwhahaha! Da capo, da capo! :) /Mike wipes the corner of his eye -- ouch, my belly is aching now :) -- Mikael Olsson, Clavister AB Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05 Fax: +46 (0)660 122 50 WWW: http://www.clavister.com Senex semper diu dormit ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
Re: firewall logging
Let me give you a scenario. I, Unlucky Ben, have just left XYZCorp after a disagreement with my manager. Said manager, Evil Bill, decides to have the last word. Having access to all the servers, Evil Bill extracts the private key from the Baltimore UniCERT server, just as it is in the process of whipping up another ham omlette. Armed with the private key, Evil Bill fakes up firewall logs showing me logging in via VPN to the firewall, accessing one of the servers and defacing the XYZCorp website with pictures of camels in sexual congress. Signing the logs with the private key, Evil Bill (who seems to know a lot about this sort of stuff for a manager) then replaces yesterdays logs on the collector with the new, signed logs, calls the FBI and off I go (apparently) to jail, where a large man called Susan wants to be my special friend. Unlucky. Just show him the pictures of the camels. That ought to give Susan pause. Or maybe not. Maybe Susan AND the camels will insist on being your special friend. Now aren't you a lucky guy. Kidding aside a very good point. And well taken in this security adled time. Patricia Brown, CNA5, MCP, A+, CUSA Desktop Support Analyst [EMAIL PROTECTED] ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
On Wed, 12 Jun 2002, Ben Nagy wrote: I'll put all this more simpy - every scheme to provide authenticated logs needs to use something secret. If it's onsite, then the secret isn't safe, and the logs just can't be trusted by an outsider. I think it's possible to do up a scheme with a TCB that makes the bar high enough that it's essentially tamper resistant (once upon a time I started to work on such a system, but then decided that the effort just wasn't worth it since most people just don't care that something is designed far enough to take care of the 99.9th percentile, 20% seems good enough :( ) Ideally, it'd include tamper resistant hardware, though that really just wants something like the flash RAM epoxied to the motherboard and a custom BIOS, as well as a physical tamper alarm on the case (I'll spare the boring thoughts there.) Given that, so that physical boots are an auditable event and there's a write-only BIOS area (enforced by the BIOS/OS) with some shared public/private OS-BIOS checking going on (to stop foreign OS booting, which stops BIOS flashing, which keeps a relatively good level of integrity in the process, and given that as a mechanism for seeding the encryption of the filesystem(s), with only things in the TCB being able to have the key you get to the point where the manager will have much better luck slipping half a kilo of $narcotic in your car. Sure, you could go out, buy the equipment to monitor the RF, see the key exchange, get a newfangled crypto cracking machine and break the keys, overcome the physical tampering alerts, whip out the drive, add your evidence, unepoxy the flash, remove the downtime record, then put it all back in place- but at that point the cost of the attack is well outside of the realm of sanity. It'd be easier to fake video of you carrying off the machine at that point. The point in infosec shouldn't be to try to negate an attack, that's a silly goal (and as you can see, it's possible to go to sillier lengths to protect things) it should be to make an attack vector not feasible. This theoretical uberManager could vacuum the skin cells off the chair you sat in, lift your prints from the mouse, and go plant physical evidence of you killing his Director (so he can nail you AND get a promotion) as well. With the right preperation, you'd still get to meet Susan- who'd still be happy to see you. Sure, they're better than random logs in text, but if I were trying to prove beyond reasonable doubt (if that's still required in the US - lucky I'm not from the middle east... ;) that something happened based So long as you're lucky enough to hit the criminal justice system, that's still the case. If we decide you're an enemy combatant, then you go into a military brig and we let you rot[1]. Paul [1] I'm not necessarily against this policy. - Paul D. Robertson My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact. ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Paul D. Robertson Sent: Wednesday, June 12, 2002 1:44 PM To: Ben Nagy Cc: [EMAIL PROTECTED] Subject: RE: firewall logging On Wed, 12 Jun 2002, Ben Nagy wrote: I'll put all this more simpy - every scheme to provide authenticated logs needs to use something secret. If it's onsite, then the secret isn't safe, and the logs just can't be trusted by an outsider. I think it's possible to do up a scheme with a TCB that makes the bar high enough that it's essentially tamper resistant[...] Ideally, it'd include tamper resistant hardware, though that really just wants something like the flash RAM epoxied to the motherboard and a custom BIOS, as well as a physical tamper alarm on the case (I'll spare the boring thoughts there.) Given that, so that physical boots are an auditable event and there's a write-only BIOS area (enforced by the BIOS/OS) with some shared public/private OS-BIOS checking going on (to stop foreign OS booting, which stops BIOS flashing, which keeps a relatively good level of integrity in the process, and given that as a mechanism for seeding the encryption of the filesystem(s), with only things in the TCB being able to have the key you get to the point where the manager will have much better luck slipping half a kilo of $narcotic in your car. Nice box. Ok, I'll pay a point for that. Sure, you could go out, buy the equipment to monitor the RF, see the key exchange, get a newfangled crypto cracking machine and break the keys, overcome the physical tampering alerts, whip out the drive, add your evidence, unepoxy the flash, remove the downtime record, then put it all back in place- but at that point the cost of the attack is well outside of the realm of sanity. It'd be easier to fake video of you carrying off the machine at that point. I don't think I have to go that far. I can probably subvert the OS through whatever the ultimate root account is, get the key from RAM and fiddle the HDD logs and then spam the flash log (multiple power events, or lots of something else that's audited). Or I can trojan the app that reads back the flash log. You could stop this with the BIOS, but then you can never legitimately upgrade your software. But yes, we're being silly. My main point is that we can now only trust the logs from this one tamper-proof machine. If it's supposed to be a hardened log collector then obviously I just mess with the input stream at the network end. The same goes for getting the logs _out_ of this box in a secure manner, probably. I'll believe it all when someone makes a firewall like that, though. ;) [...] Cheers, -- Ben Nagy Network Security Specialist Mb: TBA PGP Key ID: 0x1A86E304 ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
Re: firewall logging
On Wed, Jun 12, 2002 at 11:06:52AM +0200, Ben Nagy wrote:
I'm sure that your mechanism is smarter than that, but I'm still
asserting that it's just a bigger hurdle.
The idea is, to have the log server physically protected from insiders. It
is a log sink and not more. Administration of that machine could be done by
trusted third party, the controlling department or by 4-eye principle.
Greetings
Bernd
--
(OO) -- [EMAIL PROTECTED] --
( .. ) ecki@{inka.de,linux.de,debian.org} http://home.pages.de/~eckes/
o--o *plush* 2048/93600EFD eckes@irc +497257930613 BE5-RIPE
(OO) When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
___
Firewalls mailing list
[EMAIL PROTECTED]
For Account Management (unsubscribe, get/change password, etc) Please go to:
http://lists.gnac.net/mailman/listinfo/firewalls
Re: firewall logging
Mikael Olsson wrote: Bwhahaha! Da capo, da capo! :) Whoops. I meant for that to be off-list. Ohwell; now I get to bug all of you twice ;) ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
On Wed, 12 Jun 2002, Ben Nagy wrote: I don't think I have to go that far. I can probably subvert the OS through whatever the ultimate root account is, get the key from RAM and fiddle the HDD logs and then spam the flash log (multiple power events, Sorry, you don't get the ultimate administrative role- guess I omitted that- the implementation I was working on was for an under evaluation B2 (Red Book, not Orange) implementation. or lots of something else that's audited). Or I can trojan the app that reads back the flash log. You could stop this with the BIOS, but then you can never legitimately upgrade your software. But yes, we're being silly. I think I can stop that with MAC or roles or a combination. My main point is that we can now only trust the logs from this one tamper-proof machine. If it's supposed to be a hardened log collector then obviously I just mess with the input stream at the network end. The same goes for getting the logs _out_ of this box in a secure manner, probably. I'll believe it all when someone makes a firewall like that, though. ;) What would you pay for that? That's been the essence of my interest in RSBAC for the last ~3 years... Paul - Paul D. Robertson My statements in this message are personal opinions [EMAIL PROTECTED] which may have no basis whatsoever in fact. ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
I guess to try and get something half useful out of all this we should recap. There are three sets of problems. At the log generator(s): verification, log authenticity and log continuity. Ideally we want records that we can say are genuine, and haven't been added to or elided. We can't do that against an internal attacker without some sort of tamper evident solution, and I can't see how that can be accomplished purely in software. I'll cede Mr Robertson a point and say that with very specialised and expensive hardware it may be possible to provide a strong enough solution. If we assume only external attackers, we can probably do OK in software with mechanisms like the Cyberguard guy was describing, using capability-based MAC (B level) and a tamper-evident log auditor. [1] For other OS's - we need to have indelible log generation. Simply sending those messages out as they occur to a syslog server may be enough for some people, although we risk someone killing the syslog process as their first action. Some folks attach line printers to serial ports for this reason. Self contained logs on most general purpose OS's must obviously be taken with a pinch of salt, and ditto any system that uses batched or on-demand transfers. At the transport: These are our network problems, and we had a good talk about things like secure syslog (IETF style), syslog TCP over TLS, that sort of thing. Standard syslog has problems with reliable delivery, packet authentication, you name it. Attackers will mainly be trying to kill the wire (DoS) and inject false messages in a variety of ways. At the collector: The collector needs to be as secure as possible, obviously. I guess that would mean it should be single purpose. Denial of Service, which is often only an annoyance against normal systems can be a critical security issue against a log collector, so collectors need to be as robust as possible in that regard. Unfortunately the addition of crypto into protocols, especially with PKI, often opens up new doors for DoS. Third party admin, as Bernd suggests, may be good, but unless we're up to scratch on the other two fronts we still don't win against an internal attacker, and if it's only maintaining complete logs against an external attack that worries us then we probably don't need to go that far. Is there any value here to stealth collectors, which aren't IP addressable (they are basically sniffers with big disks)? Maybe, but the lack of interactivity may cause problems with some of our nice secure transport protocols. Unless we address all three of these issues we may be more exposed than we think, and protecting ourselves against our own employees is _much_ harder than it appears on the surface. And I _still_ say that this is not one of the nuts that is best turned by the PKI monkey-wrench. Cheers, [1] We can also build these free, if we want, using various linux / other distros which are designed for it. -- Ben Nagy Network Security Specialist Mb: TBA PGP Key ID: 0x1A86E304 The idea is, to have the log server physically protected from insiders. It is a log sink and not more. Administration of that machine could be done by trusted third party, the controlling department or by 4-eye principle. Greetings Bernd ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
Re: firewall logging
Ben Nagy wrote: I'll believe it all when someone makes a firewall like that, though. ;) You do realize that someone will now go put together a box that they'll sprinkle some orange book fairy dust(tm) over, certify according to RSSHYNARI-2002 [1], claim that it does exactly the above [2], and proceed to sell it to governament agencies and other organizations with equally rigid regulations at a price per unit roughly comparable to a BMW (and that's without the management station). -- Mikael Olsson, Clavister AB Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05 Fax: +46 (0)660 122 50 WWW: http://www.clavister.com [1] Ridiculous Standard So Huge You'll Never Actually Read It [2] Of course all the while being trivially r00table through a BIND bug from 1993, but never mind that -- it _is_ certified after all. ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
In response to Ben Nagy's 06/08/2002 message that asked: I see the need for evidence quality data, but I can't see how incorporating signatures in that way would go any way towards making data more courtworthy. To cheat, I just fake the logs on my firewall, sign them (because I have the private keys on the firewall) and send them to my collector. I might be missing something profound here, but I can't think of a way to solve that problem without a trusted third party acting in some manner. Is there one? My response: Baltimore Technologies plc has capabilities in both its SelectAccess and UniCERT products that will cryptographically time stamp and digitally sign each audit/log record as it is generated so that fake entries could not be added later. The capability is compliant with 21CFR 11 (The Code of Federal Regulations (CFR) Title 21 - Food and Drugs. Chapter 1 is prepared by the US Food and Drug Administration. Part 11 deals with electronic records and electronic signatures. The pharmaceutical industry is implementing solutions from the PKI vendors, including Baltimore, so that they can comply with 21CFR 11.) The question is, does Baltimore have an existing agent that will execute on the firewall? If not, the organization seeking such capability may have to fund the effort for one to be coded or get the firewall vendor to work with Baltimore to provide the capability as an optional feature. Marc Mandel ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
OK, I need to be more explicit. I assert that nobody can describe to me a system that I cannot subvert for providing signed logs for use as evidence _without_ using a trusted third party in some manner. All of the in-house PKI solutions seem to be trivially subverted by obtaining the private key from whatever piece of hardware is holding it. It is impossible to provide onsite hardware/software packages that cannot have the private keys extracted.[1] Protocols that use a third party seem to involve hideous back-channel connections which make them pretty much impractical. No offense, Marc, but I think you read a few too many brochures. UniCERT and SelectAccess seem to be unrelated to generic record signing/timestamping (according to the Baltimore brochureware). As usual, I'd love actual technical detail. Phrases like has capabilities don't do much for me - vendors assert all sorts of things. Yes, I'm sticking my neck out, as usual. Bring it on. ;) Cheers, [1] Some may find this contentious, and start talking about tamper-proof hardware tokens, etc. I claim that history is on my side, but I'm open to debate. -- Ben Nagy Network Security Specialist Mb: TBA PGP Key ID: 0x1A86E304 -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Marc E. Mandel Sent: Tuesday, June 11, 2002 6:12 PM To: [EMAIL PROTECTED] Subject: RE: firewall logging In response to Ben Nagy's 06/08/2002 message that asked: I see the need for evidence quality data, but I can't see how incorporating signatures in that way would go any way towards making data more courtworthy. To cheat, I just fake the logs on my firewall, sign them (because I have the private keys on the firewall) and send them to my collector. I might be missing something profound here, but I can't think of a way to solve that problem without a trusted third party acting in some manner. Is there one? My response: Baltimore Technologies plc has capabilities in both its SelectAccess and UniCERT products that will cryptographically time stamp and digitally sign each audit/log record as it is generated so that fake entries could not be added later. [...] Marc Mandel ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
On Tue, 11 Jun 2002, Marc E. Mandel wrote: In response to Ben Nagy's 06/08/2002 message that asked: I see the need for evidence quality data, but I can't see how incorporating signatures in that way would go any way towards making data more courtworthy. To cheat, I just fake the logs on my firewall, sign them (because I have the private keys on the firewall) and send them to my collector. I might be missing something profound here, but I can't think of a way to solve that problem without a trusted third party acting in some manner. Is there one? I think perhaps Ben was meaning, there's no verification his signed logs are any more trustworthy/courtworthy then the application/appliance you mention below would be. There's no 'verisign' as middleman to guarrentee his signature makes those logs, or the logs from SelectAccess which determines they are in fact something more then cheat signed. Unless I read you wrong here, even B T plc does not have this in place, or do they? Are they acting as a syslog CA? Thanks, Ron DuFresne My response: Baltimore Technologies plc has capabilities in both its SelectAccess and UniCERT products that will cryptographically time stamp and digitally sign each audit/log record as it is generated so that fake entries could not be added later. The capability is compliant with 21CFR 11 (The Code of Federal Regulations (CFR) Title 21 - Food and Drugs. Chapter 1 is prepared by the US Food and Drug Administration. Part 11 deals with electronic records and electronic signatures. The pharmaceutical industry is implementing solutions from the PKI vendors, including Baltimore, so that they can comply with 21CFR 11.) The question is, does Baltimore have an existing agent that will execute on the firewall? If not, the organization seeking such capability may have to fund the effort for one to be coded or get the firewall vendor to work with Baltimore to provide the capability as an optional feature. Marc Mandel ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls ~~ Cutting the space budget really restores my faith in humanity. It eliminates dreams, goals, and ideals and lets us get straight to the business of hate, debauchery, and self-annihilation. -- Johnny Hart ***testing, only testing, and damn good at it too!*** OK, so you're a Ph.D. Just don't touch anything. ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Paul Krumviede [...] I would have looked at using a simple HMAC with shared secrets (or at least offering it as an option) to make things shorter and easier on CPUs (but then I'm not an IETF s00perbrane - I'm sure they didn't for a reason.)[...] there has been discussion of wanting to use syslog data for evidentiary purposes, and that this would seem to require signing, rather than use of some form of (keyed) MAC. there is also the fun of key distribution for a keyed MAC. Sneakernet? 8) Seriously, if we're talking about a protocol we can use on routers and other pieces of active hardware, they'll need to be configured manually at some stage. Modifications of the same devices would presumably need to be done in some manner that meets security policy requirements, so shared-secret modifications can be done at that stage. Yes, it's always vulnerable to a guessing attack, but the payoff is that there's no PKI operation. but there was, and i believe still is, interest in use of a MAC as an alternative (but this is not (yet?) a working group item). I see the need for evidence quality data, but I can't see how incorporating signatures in that way would go any way towards making data more courtworthy. To cheat, I just fake the logs on my firewall, sign them (because I have the private keys on the firewall) and send them to my collector. I might be missing something profound here, but I can't think of a way to solve that problem without a trusted third party acting in some manner. Is there one? [...] If you want to get really simple, just run IPSec (or v6) between your firewall and log receiver, run AH only, [...] as a side comment: there has been discussion of deprecating AH (use ESP with authentication and one can use a null crypto-transform) on the IPsec working group mailing list... and NAT traversal may be possible. Good idea. AH has always been a crock, when you can just run ESP in tunnel mode. (Should have put it that way myself, but the AH only motif is easier to understand at a glance, and it was a throwaway point. Mea culpa 8) -paul Cheers, -- Ben Nagy Network Security Specialist Mb: TBA PGP Key ID: 0x1A86E304 ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
Re: firewall logging
Kevin Steves wrote: I'm tending to think TCP syslog over SSL/TLS would be a good thing to have. Yeah, I've sort of been thinking along the same lines myself. (Along with using a remote-only syslog receiver that doesn't need to bind the local domain sockets or whatever the OS flavour uses for local event delivery.) Are you aware of a syslog receiver that actually supports encrypted and authenticated logs? -- Mikael Olsson, Clavister AB Storgatan 12, Box 393, SE-891 28 ÖRNSKÖLDSVIK, Sweden Phone: +46 (0)660 29 92 00 Mobile: +46 (0)70 26 222 05 Fax: +46 (0)660 122 50 WWW: http://www.clavister.com ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
-Original Message- From: Mikael Olsson [mailto:[EMAIL PROTECTED]] [...] Kevin Steves wrote: I'm tending to think TCP syslog over SSL/TLS would be a good thing to have. Good, but expensive thing. Syslog over TCP over SSL would be much tougher on the CPU for smaller devices - I'm not an implementor, but I'm sure someone can also do the math on the longer TCP header, plus the SSL packet and CPU overhead. You'd have a nasty situation where people could DoS devices just by making them send many syslog messages. Fine for firewalls, which have big brains, but maybe not so good for things like routers (which are often also part of the firewall external security apparatus). Overall, I think that running a protocol that is better designed to deal with things like reliable delivery, message integrity, replay detection etc would be preferred. Yeah, I've sort of been thinking along the same lines myself. (Along with using a remote-only syslog receiver that doesn't need to bind the local domain sockets or whatever the OS flavour uses for local event delivery.) Are you aware of a syslog receiver that actually supports encrypted and authenticated logs? If you're aiming at secure syslog here then there's lots of work done already - the IETF even have a WG at: http://www.ietf.org/html.charters/syslog-charter.html Their current syslog-sign proposes a digital sig using PKI. Personally I would have looked at using a simple HMAC with shared secrets (or at least offering it as an option) to make things shorter and easier on CPUs (but then I'm not an IETF s00perbrane - I'm sure they didn't for a reason.)The reliable-delivery paper offers reliable delivery over UDP or TCP, with different degrees of frills on each. For firewalls, though, an SSH tunnel might be an even easier way to do it - SSH is designed to tunnel random sockets, so wouldn't even require that you hack the apps. If you want to get really simple, just run IPSec (or v6) between your firewall and log receiver, run AH only, and buy IPSec NICs - don't you get instant integrity and replay detection, then? I'd like to see every device on the Internal segments talking with AH IPSec anyway, for a variety of reasons. I guess it won't traverse NAT so well, so the SSH thing might be a better quick fix for sending stuff over the Internet. -- Mikael Olsson, Clavister AB It looks like Steve Bellovin is a key part of the IETF effort, so I've cc'ed him, in case he has some words of wisdom for us (he used to lurk here anyway). And those are my random thoughts. Cheers, -- Ben Nagy Network Security Specialist Mb: TBA PGP Key ID: 0x1A86E304 ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
RE: firewall logging
--On Friday, 07 June, 2002 10:26 +0200 Ben Nagy [EMAIL PROTECTED] wrote: -Original Message- From: Mikael Olsson [mailto:[EMAIL PROTECTED]] [...] Kevin Steves wrote: I'm tending to think TCP syslog over SSL/TLS would be a good thing to have. Yeah, I've sort of been thinking along the same lines myself. (Along with using a remote-only syslog receiver that doesn't need to bind the local domain sockets or whatever the OS flavour uses for local event delivery.) Are you aware of a syslog receiver that actually supports encrypted and authenticated logs? If you're aiming at secure syslog here then there's lots of work done already - the IETF even have a WG at: http://www.ietf.org/html.charters/syslog-charter.html Their current syslog-sign proposes a digital sig using PKI. Personally I would have looked at using a simple HMAC with shared secrets (or at least offering it as an option) to make things shorter and easier on CPUs (but then I'm not an IETF s00perbrane - I'm sure they didn't for a reason.)The reliable-delivery paper offers reliable delivery over UDP or TCP, with different degrees of frills on each. there has been discussion of wanting to use syslog data for evidentiary purposes, and that this would seem to require signing, rather than use of some form of (keyed) MAC. there is also the fun of key distribution for a keyed MAC. but there was, and i believe still is, interest in use of a MAC as an alternative (but this is not (yet?) a working group item). there seems to be an open source implementation of the reliable syslog delivery profile as part of a BEEP implementation. For firewalls, though, an SSH tunnel might be an even easier way to do it - SSH is designed to tunnel random sockets, so wouldn't even require that you hack the apps. If you want to get really simple, just run IPSec (or v6) between your firewall and log receiver, run AH only, and buy IPSec NICs - don't you get instant integrity and replay detection, then? I'd like to see every device on the Internal segments talking with AH IPSec anyway, for a variety of reasons. I guess it won't traverse NAT so well, so the SSH thing might be a better quick fix for sending stuff over the Internet. as a side comment: there has been discussion of deprecating AH (use ESP with authentication and one can use a null crypto-transform) on the IPsec working group mailing list... and NAT traversal may be possible. -paul ___ Firewalls mailing list [EMAIL PROTECTED] For Account Management (unsubscribe, get/change password, etc) Please go to: http://lists.gnac.net/mailman/listinfo/firewalls
Re: Firewall logging and Analyzing
I don't know if it suits you, but at my company we use a central syslog server and some free tools (some home made) to process logs and generate summary reports and exception traps. On Cisco, it's quite easy to forward all logs to a central syslog server. For fw-1, we use "fw log -ft | logger daemon.info" and it works great (well, on Solaris). I don't know about raptor, but I figure you there must me some way of doing it. As for attack patterns... that's something I would like to work on... Regards [EMAIL PROTECTED] wrote: I´m currently training myself in the Firewalls-Topic, and was wondering how you keep track of all the different logfiles... every vendor seems to make up their own format. Does anybody know a tool that can read different logfiles (like Checkpoint / Raptor / Cisco etc. ) and do a bit of analyzing to show trends, peaks etc.? It would seem useful for me for example to show a statistic based on Ports or adresses, to look for attack patterns. Plus, it would give IT-Management some presentations to show at meetings to justify the need for firewalls :-) (I know this shouldn´t be necessary in an ideal company, but who works in an ideal company where the beancounters don´t rule) -- Rui Pedro Bernardino / Av. Miguel Bombarda, 4, 8o / 1049-058 Lisboa / Portugal Love your enemies: they'll go crazy trying to figure out what you're up to. - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.]
Re: Firewall logging and Analyzing
Check out WebTrends. Carric Dooley COM2:Interactive Media http://www.com2usa.com On Wed, 23 Jun 1999 [EMAIL PROTECTED] wrote: Hi all! I´m currently training myself in the Firewalls-Topic, and was wondering how you keep track of all the different logfiles... every vendor seems to make up their own format. Does anybody know a tool that can read different logfiles (like Checkpoint / Raptor / Cisco etc. ) and do a bit of analyzing to show trends, peaks etc.? It would seem useful for me for example to show a statistic based on Ports or adresses, to look for attack patterns. Plus, it would give IT-Management some presentations to show at meetings to justify the need for firewalls :-) (I know this shouldn´t be necessary in an ideal company, but who works in an ideal company where the beancounters don´t rule) Mit freundlichen Gruessen - Yours sincerely Juergen Nieveler CompuNet Koeln System Engineering nternet: Juergen.Nieveler @ gecits-eu.com Disclaimer: Views are mine, not my employers´ - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.] - [To unsubscribe, send mail to [EMAIL PROTECTED] with "unsubscribe firewalls" in the body of the message.]
