Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 10 replies
  • Subscribers 29 subscribers
  • Views 8964 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Firewall UTM

Paul Brennecke

Hallo geschätzte Community,

mir geht es um folgendes: Bei dem Großteil unserer Kunden haben wir Sophos(e) im Einsatz. Konfiguriert werden die aber immer nur so, das der nötigste Traffic rausgeht und fertig, sprich Server -> Any -> Any als Beispiel.

Als neugieriger Lehrling der bei halben Sachen Plack bekommt versuche ich dann den Traffic so gut es geht auszuwerten und diese Regeln zu verfeinern.

Ich frage mich wie andere User es mit der Firewall halten? Wie viel Violations am Tag sind "ok" oder "egal"? Erstellt ihr am Bottom eurer Regeln eine 3xA Drop Regel damit der überflüssige Traffic nicht dokumentiert wird? Ich hab mich auch gefragt ob die Sophos dadurch etwas besser arbeitet.



This thread was automatically locked due to age.
Parents
  • 0

    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.)

Reply
  • 0

    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.)

Children