FortiOS 5.2.1 is out

[Carl_Wallmark]

.

[netmin]

smb client daemon (per wiki), but diag commands like " diag debug application smbcd -1" doesn' t show anything here as well, not even during a vulnerability scan.

[BWiebe]

ORIGINAL: vanc I don' t even see smbcd process on my 100D. Do you have web cache or web proxy enabled? I don' t have these features enabled.

No web cache or web proxy enabled. Once the process settled out (over 8 hours and 4 reboots later), it no longer shows as a running process unless I do something like: diag sys top 20 99 And then I can see it on the bottom of the list.

[HA]

Hello, I really hope that people from Fortinet read this post ! Are people from Fortinet stupid ?? People using smaller FGT device really don' t care about logging traffic to the cloud. WE WANT logging to the DISK !! Once again, Fortinet decide to remove this feature in 5.2.1... HA

[Christopher_McMullan]

ORIGINAL: HA Hello, I really hope that people from Fortinet read this post ! Are people from Fortinet stupid ?? People using smaller FGT device really don' t care about logging traffic to the cloud. WE WANT logging to the DISK !! Once again, Fortinet decide to remove this feature in 5.2.1... HA

HA, let' s keep the language neutral here in the forums. In OS 5.0, at various points, logging to disk was toggled to be disabled by default and not recoverable, then later it was available, but only after accepting a disclaimer about compromised disk life. The flash drives on models roughly 300 and smaller were never meant for sustained logging; they were meant for OS and config storage. This is not a Fortinet limitation - the hardware manufacturers give a MTBF of about 3,000 R/W cycles before the physical media is degraded. This doesn' t just apply to log files that roll, where the disk is overwritten frequently. It also applies to configuration changes and OS upgrades. Beyond 3,000 R/W cycles, the disk has reached the end of its rated useful life. On a smaller FortiGate, the purpose of allowing logging to the disk at all was in order to troubleshoot an issue temporarily, determine the fix, then disable logging again. There were a number of cases where large numbers of FortiGates had to be replaced because the capability of logging to disk was abused or not fully understood, so that units were failing quite soon after they were deployed. Because of this, it was thought easiest just to completely remove the possibility of allowing the FortiGate to be ruined through local logging. I hope this helps clarify why the feature was blocked for smaller models. The bottom line is: if you want to shorten the life of the FortiGate for the sake of local logging, even though there is 1Gb of free cloud storage, aside from logging to any other remote destination, downgrade to OS 5.0 and log locally.

[ShrewLWD]

Hi Chris, I am one of those that got bit big time by 60Cs failing from too much logging. While I totally agree with you, I would humbly request you update either the marketing, or change the process itself, of this ' Free 1GB.' Those of us who have worked with it enough know its 1GB, NO ROLLOVER. That makes it hard to justify setting it up for a client, teaching them how to deep dive into the logs, only to find they' ve maxed out and now need to pay up to continue to use it. Combining that with the disabled local logging, its hard to not see it as a money-grab, IMO. Your products are already stellar, why lower yourselves to [insert favorite firewall punching bag] level?

[Christopher_McMullan]

I like the last part of your comment! It looks to me like the oldest logs are being overwritten. I' m periodically refreshing my view of the FortiCloud logs obtained from my main workplace FortiGate. The total usage is 1Gb, but the latest event is always incrementing. It looks as if the feature was changed in April, 2013 to allow for overwriting old logs automatically, from what I can see. Is that not happening for you?

[FGTuser]

@Christopher: I' m not going to fully repeat, what was already said here: link but shortly: 1) Forticloud is not reliable solution...we have lost some logs on the way to Forticloud. It' s UDP. 2) Why don' t Fortinet use SSD in small devices as well? It' s just few $ more...Or why there is no option for using our own SSD/CF/USB/whatever storage? When it breaks, we will replace it and that' s it. At least USB port is already there - no price increase.

[HA]

Hello, Keep in mind in some countries, it' s NOT ALLOWED to send informations (even logs) into the Cloud for compliance reason. So sending logs to Forticloud : NO !! We need logging to the disk !!! HA

[emnoc]

1) Forticloud is not reliable solution...we have lost some logs on the way to Forticloud. It' s UDP.

Are we sure about this? I could swear it' s over SSL tcp connections. Regardless forticloud is not an enterprise business logging solution. Is not even sold or offered like that from fortinet sales. It has a purpose tho, but if your not satisfied with logging into forticloud , over the could or just need logging locally, than you have other options; 1: RSYSLOG ( windows/linux/solaris/heck just about anything ) cheap easy can be redundant upto 3 servers, and reliable udp or tcp 2: fortianalyzer slightly more, gear and has hooks, whistles and bells, for analysis, also reliable delivery With the pure reason of hardware failures, and the need of logs retention by most organizations, the off appliance logging makes 100% sense. If you re-read Christopher brilliant post, this is more of a reason not to log locally imho. The firewall should be doing firewall stuff and logging is something external.

[FGTuser]

ORIGINAL: emnoc

1) Forticloud is not reliable solution...we have lost some logs on the way to Forticloud. It' s UDP.

Are we sure about this? I could swear it' s over SSL tcp connections.

Sorry fail - not sure. Is the mechanism of sending logs to forticloud documented somewhere? Believe me or not, we lost several messages during internet line congestion comparing to local logging. BTW. Do you think that plain syslog over TCP is the remedy for lost messages? Unfortunately not: link

ORIGINAL: emnoc Regardless forticloud is not an enterprise business logging solution. Is not even sold or offered like that from fortinet sales. It has a purpose tho, but if your not satisfied with logging into forticloud , over the could or just need logging locally, than you have other options; 1: RSYSLOG ( windows/linux/solaris/heck just about anything ) cheap easy can be redundant upto 3 servers, and reliable udp or tcp 2: fortianalyzer slightly more, gear and has hooks, whistles and bells, for analysis, also reliable delivery

PLEASE! Would you buy a Fortianalyzer or even build local syslog server for some branch office using FGT 60D or 40C? No log retention needed, just for troubleshooting - checking the logs few hours/days back when somebody calls/something happens.

ORIGINAL: emnoc With the pure reason of hardware failures, and the need of logs retention by most organizations, the off appliance logging makes 100% sense.

I agree on large sites with bigger boxes. What a pity that in that case you have possibility of local logging on SSD even if you don' t need it. And on small box, when it' s really feasible to have ALL IN ONE box, you don' t have. No sense at all. I' m not naive, that starting tomorrow Fortinet will add SSD to small boxes or permit user attached storage. But if enough people complain, maybe it will change something in the future. It' s not impossible at all - console port is back on 60D :) Company which is not listening to customers can' t be successful in long term. I like FGTs, perhaps not the best devices money can buy, but price/features/performance... is quite impressive. But I might look somewhere else and it can be even more impressive... with local logging :).