From patchwork Sun Jan 21 11:45:47 2024 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Adolf Belka X-Patchwork-Id: 7473 Return-Path: Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) client-signature ECDSA (secp384r1)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by web04.haj.ipfire.org (Postfix) with ESMTPS id 4THs4g32dnz3wmD for ; Sun, 21 Jan 2024 11:46:11 +0000 (UTC) Received: from mail02.haj.ipfire.org (mail02.haj.ipfire.org [172.28.1.201]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) client-signature ECDSA (secp384r1)) (Client CN "mail02.haj.ipfire.org", Issuer "R3" (verified OK)) by mail01.ipfire.org (Postfix) with ESMTPS id 4THs4b0gJhzj5; Sun, 21 Jan 2024 11:46:07 +0000 (UTC) Received: from mail02.haj.ipfire.org (localhost [127.0.0.1]) by mail02.haj.ipfire.org (Postfix) with ESMTP id 4THs4Z745hz302j; Sun, 21 Jan 2024 11:46:06 +0000 (UTC) Received: from mail01.ipfire.org (mail01.haj.ipfire.org [172.28.1.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) client-signature ECDSA (secp384r1)) (Client CN "mail01.haj.ipfire.org", Issuer "R3" (verified OK)) by mail02.haj.ipfire.org (Postfix) with ESMTPS id 4THs4V6knmz300l for ; Sun, 21 Jan 2024 11:46:02 +0000 (UTC) Received: from [127.0.0.1] (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (secp384r1) server-digest SHA384) (No client certificate requested) by mail01.ipfire.org (Postfix) with ESMTPSA id 4THs4T5DHdzFD; Sun, 21 Jan 2024 11:46:01 +0000 (UTC) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003ed25519; t=1705837561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=iyIBd34WgdcLXQ16bQtfm/PK6ItOEPU8Uso3evqC5nM=; b=iCMC0Nq7RBQ654KdvO01sH1v4h+XwH/Ts8kQuWHiaX512UJgGMFsUv/xe3GlTiooJNGonh 8Mi2LjBd3UFPdjAA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ipfire.org; s=202003rsa; t=1705837561; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version: content-transfer-encoding:content-transfer-encoding; bh=iyIBd34WgdcLXQ16bQtfm/PK6ItOEPU8Uso3evqC5nM=; b=Zr/c2rm3/cCjF/BVQ/Nndv3Z+UYUK2oM36cHj1WaJ9ecougcsMNBGJjcVgdNfCjxeVRSAO UBfw4egSt8jYP2Jl/EfNfQ+LkdZv5s44vbwXUsU4ub61nNiLdz8OkIQFVkeSzxyrAbvS7w qpAMtLip5GOwiwpZ0p/2Br6elBR5sWOhUjVXQv6mF/lLGs6TxnkCHmdSQZHhJrP1l5WFrF uBje8aIsSxv1nS/GIqe1ZTE7Q6hBrDKqZfDVzt6BedSfdpKekEagqdR19B4CCVEuLhKLdE /SL3cEHtdOK8soSHf1CME3nJxY1btOcHS38xxM5RWNvgDkvXGQOB6f2X2d/Sdg== From: Adolf Belka To: development@lists.ipfire.org Subject: [PATCH v3 1/7] optionsfw.cgi: Fix bug12981 - Add option to log or not log dropped hostile traffic Date: Sun, 21 Jan 2024 12:45:47 +0100 Message-ID: <20240121114553.5182-1-adolf.belka@ipfire.org> MIME-Version: 1.0 Message-ID-Hash: QEIK6EAJ564E52AF2QC4ZDRCRPVITW4C X-Message-ID-Hash: QEIK6EAJ564E52AF2QC4ZDRCRPVITW4C X-MailFrom: adolf.belka@ipfire.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.8 Precedence: list List-Id: IPFire development talk Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: - This v3 version has split the logging choice for drop hostile to separate the logging of incoming drop hostile and outgoing drop hostile. - The bug originator had no port forwards so all hostile would be dropped normally anyway. However the logs were being swamped by the logging of drop hostile making analysis difficult. So incoming drop hostile was desired to not be logged. However logging of outgoing drop hostile was desired to identify if clients on the internal lan were infected with malware trying to reach home. - Added option with drop hostile section to decide if the dropped traffic should be logged or not. Fixes: bug12981 Tested-by: Adolf Belka Reviewed-by: Bernhard Bitsch Tested-by: Bernhard Bitsch --- html/cgi-bin/optionsfw.cgi | 26 ++++++++++++++++++++++++++ 1 file changed, 26 insertions(+) diff --git a/html/cgi-bin/optionsfw.cgi b/html/cgi-bin/optionsfw.cgi index fbff67b2f..52ac1b01e 100644 --- a/html/cgi-bin/optionsfw.cgi +++ b/html/cgi-bin/optionsfw.cgi @@ -94,6 +94,12 @@ if (!$settings{'DROPSPOOFEDMARTIAN'}) { if (!$settings{'DROPHOSTILE'}) { $settings{'DROPHOSTILE'} = 'off'; } +if (!$settings{'LOGDROPHOSTILEIN'}) { + $settings{'LOGDROPHOSTILEIN'} = 'on'; +} +if (!$settings{'LOGDROPHOSTILEOUT'}) { + $settings{'LOGDROPHOSTILEOUT'} = 'on'; +} if (!$settings{'LOGDROPCTINVALID'}) { $settings{'LOGDROPCTINVALID'} = 'on'; } @@ -125,6 +131,12 @@ $checked{'DROPSPOOFEDMARTIAN'}{$settings{'DROPSPOOFEDMARTIAN'}} = "checked='chec $checked{'DROPHOSTILE'}{'off'} = ''; $checked{'DROPHOSTILE'}{'on'} = ''; $checked{'DROPHOSTILE'}{$settings{'DROPHOSTILE'}} = "checked='checked'"; +$checked{'LOGDROPHOSTILEIN'}{'off'} = ''; +$checked{'LOGDROPHOSTILEIN'}{'on'} = ''; +$checked{'LOGDROPHOSTILEIN'}{$settings{'LOGDROPHOSTILEIN'}} = "checked='checked'"; +$checked{'LOGDROPHOSTILEOUT'}{'off'} = ''; +$checked{'LOGDROPHOSTILEOUT'}{'on'} = ''; +$checked{'LOGDROPHOSTILEOUT'}{$settings{'LOGDROPHOSTILEOUT'}} = "checked='checked'"; $checked{'LOGDROPCTINVALID'}{'off'} = ''; $checked{'LOGDROPCTINVALID'}{'on'} = ''; $checked{'LOGDROPCTINVALID'}{$settings{'LOGDROPCTINVALID'}} = "checked='checked'"; @@ -279,6 +291,20 @@ END $Lang::tr{'off'} + + $Lang::tr{'log drop hostile in'} + + $Lang::tr{'on'} / + $Lang::tr{'off'} + + + + $Lang::tr{'log drop hostile out'} + + $Lang::tr{'on'} / + $Lang::tr{'off'} + +