Thread Info
  • State Not Answered
  • Locked Locked
  • Replies 8 replies
  • Subscribers 2 subscribers
  • Views 18314 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

Krycek
Hello,

for the last few weeks I noticed a significant increase in blocked packets on my asg320.
I used to have around 100.000 dropped packets every day.
This rose up to around 2 Million blocked packets on June 7th. When I look at the logs I constantly see a single IP address trying to access one of my public IPs:
2012:06:24-11:29:55 pluto ulogd[5032]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth7" mark="0x1000" srcmac="0:23:5e:e1:86:1e" dstmac="0:1a:8c:17:30[:D]7" srcip="190.85.41.18" dstip="78.x.x.x" proto="17" length="200" tos="0x00" prec="0x00" ttl="45" srcport="20852" dstport="10320" 
2012:06:24-11:29:55 pluto ulogd[5032]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth7" mark="0x1000" srcmac="0:23:5e:e1:86:1e" dstmac="0:1a:8c:17:30[:D]7" srcip="190.85.41.18" dstip="78.x.x.x" proto="17" length="200" tos="0x00" prec="0x00" ttl="45" srcport="20852" dstport="10320" 
2012:06:24-11:29:55 pluto ulogd[5032]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth7" mark="0x1000" srcmac="0:23:5e:e1:86:1e" dstmac="0:1a:8c:17:30[:D]7" srcip="190.85.41.18" dstip="78.x.x.x" proto="17" length="200" tos="0x00" prec="0x00" ttl="45" srcport="20852" dstport="10320" 
2012:06:24-11:29:55 pluto ulogd[5032]: id="2001" severity="info" sys="SecureNet" sub="packetfilter" name="Packet dropped" action="drop" fwrule="60001" initf="eth7" mark="0x1000" srcmac="0:23:5e:e1:86:1e" dstmac="0:1a:8c:17:30[:D]7" srcip="190.85.41.18" dstip="78.x.x.x" proto="17" length="200" tos="0x00" prec="0x00" ttl="45" srcport="20852" dstport="10320" 


Now I tried to block that completly by adding a drop rule to the packetfilter:

source: 190.85.41.18
port: udp 10.320
dst: 78.x.x.x

I activated logging to see if it would do anything but that didn't work. It was always blocked by the "default drop".
Then I checked my NATs if there were any automatic packet filter rules. I found one, but that only affected something else on port 80. Just to be sure I changed that and added a firewall rule for that service. So now i don't have any automatic packet filter rules left.

Still I can't block those "attacks" with the packetfilter. 

Then I added a blackhole NAT. That worked and I see the packets being redirected to a non-existent internal IP, however they are still blocked by "default drop".

So that didn't help much and I deleted the NAT again.

When I then added a new firewall rule "any --> any --> additional interface IP: 78.x.x.x --> drop" the firewall logging entries changed from udp packets to rtp: (see picture in attachment).

How do I block this crap? I dodn't want millions of entries clogging up my asg and logfiles... If I could at least get rid of the logging (that's why I tried to add a rule in the first place) it would be very helpful.

Cheers,
Chris


This thread was automatically locked due to age.
Parents
  • 0
    I think it's because the PacketFilter rules are only for the Forward Chain, whereas (I assume) these packets are just trying to hit your external address, which would be the Input Chain.

    This is something Alan Toews taught me:  In the traffic selector for a NAT or Firewall rule, the destination type determines whether the rule is applied to the INPUT or FORWARD chain.  If the destination object is bound to the interface (e.g., "External (Address)"), then the rule is evaluated for the INPUT chain.  If its a normal Host definition, the rule is evaluated for the FORWARD chain.

    This is something that Scott Klassen just recently made me realize consciously: In the INPUT chain, DNAT rules are evaluated first, then the "invisible" Firewall rules for VPNs and Proxies, and then finally, any manually-created Firewall rules for the INPUT chain.

    After that, FORWARD chain rules are evaluated, and that includes most all Firewall rules that people create.

    Cheers - Bob
    PS I'm no iptables guru, so if someone sees an error in the above, please set me straight!
     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • 0 in reply to BAlfson
    What a pain... astaro doesn't show the "attacks" anymore in the logs but they are still ongoing and an abuse email did virtually nothing. not even an automated response or anything.

    What I noticed is: The packets are not counted anymore either. So just because I deactivated logging means blocked packets will not be counted anymore in the statistics and I'm down to a couple of thousands a day again although that's not true.

    Can this be changed somehow? And do you guys have any other idea how to make this stop?
Reply
  • 0 in reply to BAlfson
    What a pain... astaro doesn't show the "attacks" anymore in the logs but they are still ongoing and an abuse email did virtually nothing. not even an automated response or anything.

    What I noticed is: The packets are not counted anymore either. So just because I deactivated logging means blocked packets will not be counted anymore in the statistics and I'm down to a couple of thousands a day again although that's not true.

    Can this be changed somehow? And do you guys have any other idea how to make this stop?
Children
  • 0 in reply to Krycek
    Hi Chris

    Instead of blocking specific networks / hosts with special rules to avoid logging, why not doing it using a generic rule ? Usually drops from external access attempts does not interest anyone (unless you don't have to troubleshoot external access issues) - why filling up firewall log with hundreds of MBytes with drop loglines ? The packet got dropped anyway and didn't harm anyone (in best case used little of your available bandwidth) [[;)]]

    I always recommend to anyone two last packetfilterrules at the end of the filterset.

    2nd last rule - reject ANY traffic with source from all internal networks to ANY and log it

    "Internal Networks" - ANY - ANY - REJECT w. Log

    Reason: It's nice to communicate to internal applications, that the connection was rejected, which gives the application the chance to pop up a error message, instead of running into a timeout or hammering the firewall with retries. Logging, because rejects appears yellow in the live log, and you can immediately distinguish rejected internal to somewhere communication by it's color, and easily find probably missing firewallrules, or suspicious internal hosts.

    Last rule - ANY - ANY - ANY - DROP w/o Log

    Reason: This rule replaces the default drop rule of the ASG, which also drops remaining packets without active rule, but ASG also logs per default all drops. This rule will not log such attempts. This will keep your firewall logfiles clean and small - Usually nobody is interested in drops from external access attempts, the packets didn't pass your firewall [[;)]]

    I'm happy with this since years, and I also implement those two rules on every ASG I get in touch and where I have to optimize things.

    If these two rules doesn't work in your scenario, there's probably still a NAT rule or internal ASG service listening on this port, but the traffic gets dropped for some other reason (Source IP restrictions or whatever)
Unfiltered HTML