Firewall log
Page 1 of 2 12 LastLast
Results 1 to 10 of 11

Thread: Firewall log

  1. #1
    Member
    Join Date
    Dec 2002
    Posts
    71

    Firewall log

    I am using the latest version of ZA and have an enormous amount of logs that I am not 100% sure of what is going on. I am on my university's network and the source IP is on the same network. It is a UDP packet from port 137 to my port 137. I know this is one of the netbios ports which doesn't concern me since its not installed and my firewall blocks those ports. I am just curious about what is causing this. I read the zone alarm info on the alert and gives several possible explanations like DNS, port scans, shares and what not. I was thinking it might be DNS but was wondering if you guys would know what it mostly likely is. Thanks

  2. #2
    Some Assembly Required ShagDevil's Avatar
    Join Date
    Nov 2002
    Location
    New Jersey
    Posts
    718
    coVert,
    Do you know if the source IP is the IP of your DNS server(s)? I think you can use ipconfig or winipcfg to find out what DNS servers you're using and what their related IP's are. Once you have these, you can compare them to your ZA firewall logs to see if they are simply legit DNS requests. Another thing, if I remember correctly, if the both the source and destination ports are 137, it's usually not malicious behavior but rather some kind of root process being called by the system. Although, there is also that Bugbear worm that was around hitting port 137 some time ago.

    *note- I'm no expert on the matter, just thought I'd share what I could remember about this stuff.
    The object of war is not to die for your country but to make the other bastard die for his - George Patton

  3. #3
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401
    A DNS server will only respond to port 137 IF and only IF the request came from that port. Since this port is being used by windows for file/printer sharing this is highly unlikely. Source ports on windows tend to be above 1030.

    I'm betting my money on a) a virus or worm, b) fellow students scanning the network.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  4. #4
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    Hi

    When you run ZA, I assume you are running WinXP or something similar.
    What you see might be typical for a SMB connection with WINS, which
    traditionally uses UDP 137 for name resolution, in a environment
    as you are in (university. Universities often use samba to share files and printers
    using windows- and linux-machines, without the need of some additional
    win2kx-server).

    Of course to be sure, you should capture one of these as an example, see [1]:

    "
    The tcpdump program (dump traffic on a network) can be used to view network traffic, and, if necessary, its output can be parsed do deduce the source of excess packets. You can get the tcpdump-smb program, an extension to tcpdump, from the Samba Website (www.samba.org). It's used to investigate SMB networking problems over NetBUI and TCP/IP. Typically, it must be run as root due to the hardware access level and the information it provides. The following examples shows a debugging session for Samba, but tcpdump can be used for any other networking problems.

    Capture all SMB packets to debug Name Resolution Problems (WINS)

    # tcpdump port 137

    tcpdump: listening on eth0
    15:33:15.437022 opal.netbios-ns > 193.247.121.207.netbios-ns:
    >>> NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    TrnID=0x3A4F
    OpCode=0
    NmFlags=0x11
    Rcode=0
    QueryCount=1
    AnswerCount=0
    AuthorityCount=0
    AddressRecCount=0
    QuestionRecords:
    Name=AKADIA NameType=0x1D (Master Browser)
    QuestionType=

    In the example above, the machine opal sends a broadcast request to the broadcast address 193.247.121.207 for the NetBIOS name resolution.
    "

    Using windows, you can do it with windump[2].

    Cheers

    [1] http://www.akadia.com/services/linux_tips.html
    [2] http://windump.polito.it/install/default.htm
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

  5. #5
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401
    Isn't ZA a statefull firewall? If it is, it should allow the responses back in.

    It wouldn't hurt to run a sniffer though. It's the only way to be sure of what it is.

    I can recommend ethereal.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  6. #6
    Member
    Join Date
    Dec 2002
    Posts
    71
    Thanks for the replies. I checked ipconfig and the dns servers don't match the ip's. Now that I look at it the source address is different each time in the log. I would really like to use a sniffer to find out more but it's not allowed in the acceptable use policy. They probably wouldn't notice but I can't take any chances when graduating in Dec. I don't think it is a virus but could be. Our university decided to have students ditch their current AV for the one the school provided (McAfee Enterprise) this fall semester which I think they can remotely update them. Any idea on why the source IP would constantly change?

  7. #7
    Some Assembly Required ShagDevil's Avatar
    Join Date
    Nov 2002
    Location
    New Jersey
    Posts
    718
    Isn't there also some fairly clear indications if the 137 traffic is malicious or not? I seem to remember that if the source port of the scan is 0-1023, it will most likely be legit. The Bugbear scans tend to be between source ports 1024-1033 (they can be on higher ports as well). Generally, anything higher than source port 1023 could be a fairly good indicator that it's a malicious scan? maybe a skiddie playing with NBTSTAT -A?
    The object of war is not to die for your country but to make the other bastard die for his - George Patton

  8. #8
    Just Another Geek
    Join Date
    Jul 2002
    Location
    Rotterdam, Netherlands
    Posts
    3,401
    What's the destination ip btw? If it's 255.255.255.255 it's probably regular windows traffic. Windows "broadcasts" it's presence on a regular basis. Then it could be one of your fellow students (without a firewall) just booting and running windows.
    Oliver's Law:
    Experience is something you don't get until just after you need it.

  9. #9
    Senior Member
    Join Date
    Mar 2004
    Posts
    557
    Hi

    coVert, you could also ask your network person in charge whether he detects
    the same traffic and/or ask him permission to use ethereal (excellent software),
    as suggested by SirDice.

    If "we" ( ) are right, then the traffic from 137 to 137
    is not malicious.

    You say, that the source-IP changes with each package?
    How does it change? How do the source-IP's look like? Always the same, let's
    say 100 IP's from your subnet, or do they look "random"? This would also be
    a good indicater, whether someone tries something on 137 while spoofing the
    IP, or, whether there is some legitimate WINS/Netbios/... "recognition" process
    under way.

    /edit: just read SirDice's post. A remark: SMB WINS broadcast is subnet.255:137, if
    I recall correctly eg 192.168.1.255:137 ... err ... right?. As much as I understood,
    the dest IP is his machine, eg. 192.168.1.17.
    If the only tool you have is a hammer, you tend to see every problem as a nail.
    (Abraham Maslow, Psychologist, 1908-70)

  10. #10
    Member
    Join Date
    Dec 2002
    Posts
    71
    I have included a screener of my ZA log so maybe you can get an idea of what I am talking about.
    Thanks for the help

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •