How to disable logging packets marked with Martian source/ll header and DROP_CTINVALID. and charon
My messages file grows up to 200 MB per day and reduces firewall performance.
Go to the WUI menu - Firewall - Firewall Options and then change the entries in there that are labelled
- Log dropped packets classified as INVALID by connection tracking
- Log dropped spoofed packets and marsians
from on to off and then reboot.
Logging of those dropped packets will then be stopped.
See
https://www.ipfire.org/docs/configuration/firewall/options
Regarding the charon entries these are related to IPSec. What sort of log messages regarding charon are you seeing? What sort of IPSec traffic are you running?
3 Likes
Selected mentioned
options off and rebooted, but that packets logged anyway. 
Will charon leave it as it is for now.
BTW: Switching these log messages ( marsians esp. ) off doesn’t cure the problem.
These messages show up if some client in the network sends inapprobiate packets ( source IP is a APIPA IP for example ).
1 Like
Yes, if the martian packets are coming from the internal network then you probably want to investigate and find out which system or which user is sending spoofed IP traffic.
1 Like
Are your users using IPSec VPN tunnels? that is the only reason to have charon messages in the logs.
Yes, we have VPN tunnel.
We have more than 40 Mikrotik access points in our LAN, and every is logged with such packets to or from another Mikrotik device.
I have a similar issue, so access points might be causing this?
All sorts of things can cause it.
I have three switches and I have three vlans on them covering green, blue and orange and I get bogons/martians from blue and orange on the switch trying to go to the green nic on my IPFire.
The problem looks to be that the switches also have a default vlan which can be used for admin and on the switch versions I have that default vlan can not be turned off so it can end up trying to make contact on all other vlans.
The software on the switch has a bug causing this. The switch manufacturer has allowed the default vlan to be turned off but the firmware fix has not been made available for the hardware versions that I have got. So it looks like the only fix would be to buy three new switches, which currently I don’t intend to do. The martian traffic is being dropped anyway by IPFire.
I also have two wireless access points, also using the three vlans and I have no bogons/martians from them at all. So their firmware is able to not craete martian traffic across the vlans, so it can be done.
UPDATE EDIT:
The firmware fix has been released for the versions of my switches. I have been able to remove the default vlan1 from all of the network ports that are in use and are a member of one of the three used vlans that I have specified.
Previously I had around 400 to 600 bogons per day on each of my three switches. Yesterday I had 1
1 Like
So you have a lot of Bogon entries in your Firewall log.
How are you able to sort through the log and quickly find relevant events that need your attention?
The bogons are filtered out from the logs shown in the WUI menu Logs - Firewall Logs.
The bogons are shown in the Logs - Log Summary page. The only ones I have are all internal.
I also have the IP Blocklist Bogons Full activated but I don’t get any Bogon hits coming into red or trying to go out.
I have also turned off the logging for Dropped Input Packets so all the packets dropped trying to enter the red interface are not logged.
So the Logs - Firewall Logs page shows logs containing only the following types
- BLKLST_DSHIELD
- BLKLST_EMERGING_COMPROMISED
- DNAT
- FORWARDFW
- DROP_CTINVALID
- DROP_HOSTILE
- INPUTFW
The biggest entries are items 1. & 6.
I have the feeling that 1. is covering the same range as 6> so I might turn that IP Blocklist off in the future.
-
will disappear with the release of Core Update 184 as I will then turn off the logging of DROP_HOSTILE incoming.
-
& 4. are related to ports I have open for Lets Encrypt certificate update. Most of the stuff is from scanners trying to access a web server but they all come up to a dead end as there is no web server and the Lets Encrypt option is locked down only for the update process.
I may look at having the ports closed except when the Lets Encrypt update window opens for the certificates at 30 days.
The ones that are left - 2. 5. & 7. are quite low in terms of numbers of events.
I may not be a good example as I am a home user, where I am the only user and most things are locked down. Only ports 80 & 443 are open for the Lets Encrypt stuff. If I can close those most of the time then all incoming ports will be closed.
None of my DROP_HOSTILE have been for outgoing so no malware on my systems trying to call home thankfully. That would be my main thing that I would want to pick up on.
Thank you that’s interesting but I don’t quite understand. Do you have ports 80 and 443 open for outgoing? How does DROP_HOSTILE prevent malware (or other things) that are not blacklisted from phoning home? Are you using a proxy?
No. I have those ports open for Incoming with a Port Forward.
DROP_HOSTILE uses the IP blacklist mainly from Spamhaus DROP and a few other lists to block all incoming and outgoing to those IP’s.
Those IP’s are the ones that are used by criminal or other organisation that host the C&C (Command and Control) centres for a range of malware.
So it doesn’t detect the malware directly but it does detect if that malware is calling home to download any sensitive/valuable information that it has obtained.
Of course better to not get infected in the first place and if the malware is ransomeware then it could still have encrypted your data even before it tries to call home.
So DROP_HOSTILE is not a solution for everything but it is a good tool in the armoury and that IP List should never be getting accessed by normal users systems, or be allowed to access via a Port Forward.
On my Firewall Log, there were a few IP’s blocked by DROP_HOSTILE that were trying to access my open port 80 & 443 so good to be blocked and dropped.
Yes, I have the web proxy turned on for my green network but as most web sites I access are now https (encrypted) then I don’t use any of the filtering in the web proxy as that works only with http sites. I also don’t use the Update Accelerator as I download my Arch Linux updates from https sites and the Update Accelerator only works with http.
Even the web cache element of the web proxy only works with http, all https traffic has to be obtained afresh for each access so the benefit of a web proxy to myself is becoming less and less.
1 Like