Still understanding logs is a big problem and mistery. Some reports are still missing. We expect to see into 18.5 a new log module

First of all, you need a Default drop rule to log non matching Traffic. 

https://community.sophos.com/kb/en-us/133310

That is still the case in V18 EAP1. The Default drop rule in firewall was the first step, but it does not enable the logging like such a firewall rule with "all" zones would enable. That is something for a version ongoing. 

If you have such a rule in place, XG will log all traffic, which does not match. Easy to stop a non matching Traffic in Logviewer (port). 

TLS / SSL Errors will be improved. Currently the Apps are categorized "wrong", so to speak most apps are FTP/443. If fixed, it should be easy to spot your Teams Apps to find, if this app is not able to be decrypted. 

Myself, i work with tcpdump, drppkt and conntrack quite easily - Simply because i work day / night with XG. I know i cannot expect this by everyone, but its possible. Having the SSH Key in mobaxterm and you are fast to go for troubleshooting. But thats my way to interact all the time (even on UTM and other vendor products). 

Just my two cents about this topic. Its not a solution, just a personal opinion in regards this. 

Thanks Luca for your personal opinion. XG logging, compared to other brand, is back 10 years (at least). People are waiting for a complete re-design/re-engineering of logging module.

If you want to really work on XG to understand what's going on, you need to keep open several ssh connection with several tail -f and with other ssh connection conntrack, drop-packet-caputre and tcpdump.

This is not acceptable. It is a waste of time. People needs to use cli only in certain cases. On XG, you can use the log viewer 20% of time, the rest of troubleshooting is under cli (70%) and the rest of 10% is opening cases at Sophos.

Not all people are so expert in troubleshooting via CLI. I do not even talk how the certain logs are spread into .log files. Terrible design!

I do not even talk about reporting...

UTM had so much nice and complete reporting/logging module that few competitors have.

I guess, it is how much you use the platform. I received couple of reports by partners, who likes the CLI approach in XG way more than UTM. Simply because they have some more powerful tools in XG. (Conntrack is more powerful, tcpdump is powerful, drppkt is new). 

I understand your concerns and agree with you guys, if you are not working with the product often, you want to avoid the way to the CLI. There are still stories for the future to improve and address such matters. 

I do not want to open up now the conversation / comparison between other brands / UTM and XG logging, to keep this thread clean. Just wanted to give some inputs, how i do it nowadays. 

LuCar Toni said:

I guess, it is how much you use the platform. I received couple of reports by partners, who likes the CLI approach in XG way more than UTM. Simply because they have some more powerful tools in XG. (Conntrack is more powerful, tcpdump is powerful, drppkt is new). 

I understand your concerns and agree with you guys, if you are not working with the product often, you want to avoid the way to the CLI. There are still stories for the future to improve and address such matters. 

I do not want to open up now the conversation / comparison between other brands / UTM and XG logging, to keep this thread clean. Just wanted to give some inputs, how i do it nowadays. 

 

Luca, againg thanks for your input. I am confident with CLI (I was born with Cisco, Cisco PIX where GUI did not even exist). The problem of XG is confusion and lack of visibility, always, always. A lot of confusion. Things are putted not in order even in the log. For web filtering, you need to open 3 .log files.

Nothing against conntrack. It is a tool available on Linux since many years ago. I cannot remember the year (maybe 2007/08) but not all people are confident with them.

Create a cli like Cisco does where menu makes sense. Exposing the linux OS is not safe too.

LuCar Toni: when I write on the forum, I write on behalf of other people and customers I know whom are not confident to write in English and they do not want to contribute to community as they do not have time to catch XG issue.

Many people I work with (I am a consultant) are still on UTM9 or moved away to other platforms because the first reason was XG logging, live connection tab which is there just to please customers.

Flow monitor was a wonderful tool. Both the graphic and the table it provides.

Sure you can understand and forward the message to the correct people. Before putting new "marketing" features, make sure logging in 18.5 is completely new (copy from UTM9 and see what you can improve from it).

With logging, will start to accost more and more customers! Trust me!

Hello LuCar Toni,

and if I could recommend something to your developers when they are still developing the wheel resp. the Drop ALL rule. Please replace the drop-in counters of received and sent bytes with the drop-in packet counter.

This is much more meaningful (for debugging definitely) than received and sent data, because they are discarded anyway.

And you don't have to pay me for my advice, I give it to you for free ....

Regards

alda

[;)]

LuCar Toni said:

I guess, it is how much you use the platform. I received couple of reports by partners, who likes the CLI approach in XG way more than UTM. Simply because they have some more powerful tools in XG. (Conntrack is more powerful, tcpdump is powerful, drppkt is new). 

I understand your concerns and agree with you guys, if you are not working with the product often, you want to avoid the way to the CLI.

This is a hail mary, Luca.

Remember the motto: "Security made simple". XG logging and monitoring is not part of it! As alda wrote, do not reinvent the wheel. You have internal knowledge to do it in the correct manner.

Appreciate your feedback, as always, i simply try to give you some points to work with the current version. 

Hello LuCar Toni,

could I give your developers one more advice (even if you've deleted my two previous posts again)?

If they could add the reset function of dropped packet counters while developing Drop ALL rules. Again, this would greatly simplify debugging.

And again my advice is free ...

Regards

alda

P.S. I hope that this post will not be again inappropriate and abusive.

He does have a good point, Sophos are always banging on about "Security made simple" - then we're expected to ssh into the box to work through simple web application unblocking.

He does have a good point, Sophos are always banging on about "Security made simple" - then we're expected to ssh into the box to work through simple web application unblocking.