TCP (flags:AR)?

Discussion in 'other firewalls' started by taba, Aug 21, 2004.

Thread Status:
Not open for further replies.
  1. taba

    taba Registered Member

    Jul 27, 2002
    What does the following log file info mean? This particular entry is strange to me because of the AR (ack, reset?) flags, and because it's happened 20+ times in the last couple of hours. I seldom see that in my logs.

    Packet sent from (HTTP) to XX.XXX.XX.135 (TCP Port 176:cool: was blocked
    TCP (flags:AR)
    Source IP
    Destination IP XX.XXX.XX.135:1768
    Direction Incoming
    Action Taken Blocked
    Count 1
    Source DNS Loopback
    Destination DNS COMPUTERB

    I'm also seeing repeated entries from 3 different IP blocks. Have done thorough scan with AV and trojan scanner (nothing found), and used Port Explorer (not sure what to look for there but don't see any glaring concerns).
    Last edited by a moderator: Aug 23, 2004
  2. bigc73542

    bigc73542 Retired Moderator

    Sep 21, 2003
    SW. Oklahoma
    I am not a firewall expert but at least it blocked the incoming packet.
  3. dog

    dog Guest

    I'm no f/w expert either ...

    but it looks like a loopback being sent by your PC (packet sent from (HTTP) to ...) to your ISP's DSN server.

    or it could be a http pearl overflow or something your f/w's blocking internally.

    either way your OK ... it's blocked.
  4. Devinco

    Devinco Registered Member

    Jul 2, 2004
    Well I guess I will make it a trio of Non-Firewall experts!! :D

    On OutPost Pro 2.1, I have a tight rule set and I would get a similar message.

    I have an update program like TDS-3 Radius update (it does the same thing with other update utils).

    In the rules, I allow it
    Outbound on DNS port to only my DNS servers.
    I also allow outbound on on HTTP port 80.

    I had general rules that would block most other things.

    The inbound message would pop up sometimes when I would update (not every time).

    So I added another rule that blocks inbound UDP from my DNS servers IPs. The rule does not specify the port, because the port will change. It works. Now I just add this rule to those utilities that pop up this message. I don't know why it happens though.

    You should find out if the IPs are your legit DNS servers.
    Start/run/cmd. In dos window, type ipconfig /all.
    It will list your DNS servers. Call your ISP and verify that those IPs are owned by your ISP.

  5. dog

    dog Guest

    Well speaking on rules:

    General DNS rules:
    Allow, UDP, Inbound, remote service/port 53, remote Address [you ISP's DNS servers], local service/ports 1024-5000
    Allow, TCP/UDP, Outbound, remote service/port 53, remote Address [you ISP's DNS servers], local service/ports 1024-5000

    (then for regular programs) Allow, TCP, Outbound, remote service/port 80, remote Address any (you can create a list of IP's if desired), local service/ports 1024-5000

    (Browsers) Allow, TCP, Outbound, remote service/ports 80 and 443, remote Address any, local service/ports 1024-5000
  6. CrazyM

    CrazyM Firewall Expert

    Feb 9, 2002
    BC, Canada
    Hi taba

    When you see the source port associated with a common service, in this case HTTP, these types of entries will usually be the result of packets part of an established connection arriving late and being dropped by the firewall.

    These entries with localhost being the source, are they arriving on the WAN interface (from the Internet)? Or do you have loopback rules for your system that could be responsible these entries?

    What do these log entries relate to, rules associated with the entry?


  7. taba

    taba Registered Member

    Jul 27, 2002
    Thanks for all the replies, everyone. I'm not well today so am not up to coherent thought or writing, but will follow up soon. It's off to bed for me with a bucket by the side. :blink:
  8. martindijk

    martindijk Registered Member

    Jun 13, 2003
    Gorredijk - the Netherlands
    Hope you get well soon Taba.

  9. xmp

    xmp Guest

    Just do a whois on the IP address. It may have been legit DNS traffic. ACK is just acknowledging the packet, and RST resets the TCP session.

    Strange combinations of TCP flags on inbound traffic are a different matter.
Thread Status:
Not open for further replies.