False entryes in firewall Zywall logs

Options
alexey
alexey Posts: 188  Master Member
First Anniversary 10 Comments Friend Collector
in Security
Hi all.
We start logging our ZWs to syslog server.
Sometimes in log i see record like this:
src="172.20.15.15:161" dst="172.20.16.62:53270" msg="priority:56, from LAN1 to IPSec_VPN, UDP, service others, DROP"
from site A blocked connection to site B by rule 56.
But 172.20.15.15:161 is not request to 172.20.16.62, not new connection, it answer. Why it in logs?
172.20.16.62 - server, that monitor 172.20.15.0/24 net by snmp, around 100+ diff connections every minutes. But writes in log only 1 in 10-20 minutes. Other works good.
Same with DNS answer by 53/UDP port.
Why this happened?

All Replies

  • alexey
    alexey Posts: 188  Master Member
    First Anniversary 10 Comments Friend Collector
    Options
    Exemple with DNS
    src="172.20.0.2:53" dst="172.20.19.15:32899" msg="priority:56, from LAN1 to IPSec_VPN, UDP, service others, DROP"
    172.20.19.15 - client, 172.20.0.2 - DNS server. Answer from DNS server is blocked (or logged) by ZW.

  • Zyxel_Jeff
    Zyxel_Jeff Posts: 1,079  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    Options

    Could you provide the device config file to us via private message for a further check? We would like to find out the relationship between those log messages and the security policy rule#56?
  • alexey
    alexey Posts: 188  Master Member
    First Anniversary 10 Comments Friend Collector
    Options
    Hi.
    Security policy very simple - block all connections from local lan to ipSec.
    Send config via PM.
  • Zyxel_Jeff
    Zyxel_Jeff Posts: 1,079  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    Options

    After checking your config, we noticed that your security policy#56 will drop packets from LAN1 to IPsec_VPN with specific source/destination IP addresses. You can trace those devices which belong to the source IP addresses (172.20.0.0./20), why do they access the destination IP addresses, and what kind of behavior they conduct during that time period.

  • alexey
    alexey Posts: 188  Master Member
    First Anniversary 10 Comments Friend Collector
    Options
    Hi @Zyxel_Jeff

    src="172.20.15.15:161" dst="172.20.16.62:53270" msg="priority:56, from LAN1 to IPSec_VPN, UDP, service others, DROP"
    src="172.20.0.2:53" dst="172.20.19.15:32899" msg="priority:56, from LAN1 to IPSec_VPN, UDP, service others, DROP"
    This records from logs not for new connections.
    172.20.16.62 - monitoring server. It monitors 172.20.15.0/24 net by snmp (161 udp).
    It connects from random port to device port 161 (around 50 diff devices). In this example from 172.20.16.62:53270 to 172.20.15.15:161.
    172.20.0.2 - root DNS server for all our network with more than 1000+ clients. They all connect from random port to 53 udp port. In this example from 172.20.19.15:32899 to 172.20.0.2:53

    These records answers for estabilished connections from clients/server.
    Only some records write in log every 10-20 minutes.
    Why they were log? 

  • Zyxel_Jeff
    Zyxel_Jeff Posts: 1,079  Zyxel Employee
    First Anniversary 10 Comments Friend Collector First Answer
    Options

    Those logs were generated by security policy#56 deny_to_vpn, this security policy means that if the firewall detects source IPs(172.20.0.0/20) access to destination IP(172.20.0.0/16) from LAN1 to IPsec_VPN, the fireall will drop/deny this session. You can confirm if this security policy meets your security requirement.



  • alexey
    alexey Posts: 188  Master Member
    First Anniversary 10 Comments Friend Collector
    Options
    Yes, i know by what they were generated.
    But my question is why they were generated.
    src="172.20.0.2:53" dst="172.20.19.15:32899" msg="priority:56, from LAN1 to IPSec_VPN, UDP, service others, DROP"
    172.20.0.2 is root DNS server. It is not connected to any other device in lan. It answers on DNS request in estabilished session.
    We got more then 1000 devices.
    If this rule block all this requests, we got very big logs.
    But we have only 1 record every 10-20 minutes.
    Same thing with SNMP.
  • zyman2008
    zyman2008 Posts: 199  Master Member
    First Anniversary 10 Comments Friend Collector First Answer
    Options
    Not sure if that possible the UDP answer not reply in time or the UDP session kill for unknown reason. Or the IPSec VPN has another session table with limited number ?

    Maybe have a trial and error to increase the UDP session timeout.
  • alexey
    alexey Posts: 188  Master Member
    First Anniversary 10 Comments Friend Collector
    Options
    zyman2008 said:
    Not sure if that possible the UDP answer not reply in time or the UDP session kill for unknown reason. Or the IPSec VPN has another session table with limited number ?

    Maybe have a trial and error to increase the UDP session timeout.
    Hi @zyman2008
    I had same idea.
    I increased udp session timeout/deliver for 120 sec from 60. But it don't do nothing, except much more messages from session limit counter.

Categories

Security Highlight


Read more

Security Help Center

EnglishTiếng ViệtРусскийไทย中文（台灣）