Firewall UTM

Moin,

also ich halte nicht viel davon, any->any-Regeln zu deklarieren. Dann kann man auch einfach ne Fritzbox installieren und das wars dann. Vielmehr sollte gut überlegt werden, welche Dienste freigeschaltet werden. Das sind ja meistens Standarddienste. Jedenfalls sollte so wenig wie möglich und soviel wie nötig in der Firewall freigegeben werden.

Eine 3xA Drop Regel ist nicht nötig, es existiert ja schon das implizierte deny.

ThorstenSult said:

Eine 3xA Drop Regel ist nicht nötig, es existiert ja schon das implizierte deny.

Das wäre ja die Default Drop Regel und soweit ich das verstanden habe landet alles was die droppt in den Violations. Und da soll so wenig wie möglich drin stehen.

Aha! Warum soll da nichts drin stehen?

Nichts wird schwierig, aber eben möglichst wenig. Einfach nur fürs Auge.

Naja, von mir aus!

Jedenfalls, um Deine Frage zu beantworten, ich setze so eine Drop-Regel nicht. Und ich kenne auch niemanden, der sowas macht.

Hoi,

ich arbeite und hab Privat ne UTM. Hab aber noch Erfahrungen mit der Dell Firewall gemacht. Was ich dewsegen an der UTM vermisse ist die Anzahl der "Hits" der einzenlen Regeln. Auf der Arbeit war es nämlich auch so das 75% der Regel meiner Meinung nach keinen Sinn ergeben haben und so eine Auswertung dann auch die Klarheit darüber gebracht hat. Hab nämlich die Logs der letzten Monate dann auf einen Linux gepackt und mit nem einfachen script die Sklavenarbeit machen lassen. Wenn mir dann noch eine Regel zu "offen" oder zu grob war, hab ich erst mal ne genauere Allow Regel ganz nach oben gepackt und dann den Traffic noch mal durch meinen Sklaven verarbeiten lassen. So ist mitlweile ein Schuh draus geworden.

Hallo Paul,

(Sorry, my German-speaking brain isn't creating thoughts at the moment. )

My approach is more like Thorsten's.  In fact, a drop rule at the bottom of the rule list causes less information to appear in the log even if you log the rule.  When analyzing an issue, the default drop can be seen to have been dropped from the INPUT, FORWARD or OUTPUT chain.

When first installing a new client, I make Firewall rules very specific like 'Internal (Network) -> DNS -> Internet IPv4 : Allow'.  I follow that with a logged rule 'Internal (Network) -> {1:65535->1:1023} -> Internet IPv4 : Allow'.  After a week or two, I run the following command (assuming I installed last month and that the logged rule is rule #30):

zgrep 'fwrule="30"' /var/log/packetfilter/2018/03/* |grep -oP 'dstport=".*?"' |sort -n |uniq -c |sort -n

I ask the customer if there's any reason any of those ports shouldn't be opened.  I then put them into a Group named "Company Services," make an Allow rule for the Group and I disable the logged rule.

Some devices use ports in 1024:49151, but usually, someone complains that xyz isn't working and the necessary ports are soon opened.  Obviously, we try to get those done in the beginning.

I don't think logging slows anything down as it's done simultaneously in another thread.

MfG - Bob (Bitte auf Deutsch weiterhin.)

Thanks for your thoughts bob.

Danke auch an die andern Kollegen, ist wohl alles eher ne Detailsache.

My thoughts:

1) I push all web traffic through the web proxies, not through the firewall.   This provides better logging information.   More details at my post from last month.

https://community.sophos.com/products/unified-threat-management/f/web-protection-web-filtering-application-visibility-control/101117/optimizing-web-proxy-lessons-learned

2) When investigating whether traffic should be allowed or not, I enable logging.    Once I identify some traffic that is necessary and repetitive, I drop logging.   An example is DNS traffic from my internal DNS servers.    (On the other hand, DNS from any other PC would be logged.  After investigation, it would probably be blocked.)   Similarly, I have started blocking UDP 443 because I don't want Google Chrome to operate in QUIC mode.    I block the packets without logging, because the volume is high and the packets are not a threat.

3) Next, I monitor the logs to understand my "normal" traffic profile.   I am looking for blocked traffic that needs to be allowed, and for allowed traffic that is unexplained or questionable.   Recently, I have been using the firewall logs to study UDP traffic.

Philosophy:

We block pretty aggressively.  My boss says that if the users are not complaining, blocked traffic must not be a significant problem for them.   He is right, but I still check the logs.

I did this mental exercise recently:   Assume only 1 in 10,000 web sites are hostile.   Also assume that UTM blocks all but 1 in 10,000 attacks.  That means my odds of a successful attack are 1  in 100,000,000.   That seems pretty good.   Then I counted how many web logs entries I have per day.   Depending on your user base and the amount of data that you log, you can reach 100,000,000 log entries pretty quickly.  For me, it is probably about 3 months.   If the goal is 0 infections, a penetration rate of 1 in 100,000,000 is not sufficient.

I think of my network traffic as falling into three categories:   essential, optional, and hostile.  In order to block all of the hostile traffic, a lot of the optional traffic has to be blocked as well.   That configuration is defensible, because what the organization requires to stay in business is only the essential traffic. 

Also, I do not read the log files directly.   I load the logs into a database and analyze the logs using database queries.   This log explained the general approach and provided sample code.

https://community.sophos.com/products/unified-threat-management/f/management-networking-logging-and-reporting/100770/how-to-using-a-sql-database-to-interpret-utm-log-files

Web proxy and reverse proxy (WAF) logs are more complicated.   I'll provide the details on request.