Re: Reverse http traffic

From: Just1n T1mberlake (hotpackets_at_hellokitty.com)
Date: 01/01/04

  • Next message: Russell J. Lahti: "Re: flood of SYN packets to port 110"
    To: "James C. Slora Jr." <Jim.Slora@phra.com>, "Daniel H. Renner" <dan@losangelescomputerhelp.com>
    Date: Thu, 01 Jan 2004 10:31:17 +0800
    
    

    Hi James, all,

    > Daniel H. Renner wrote Tuesday, December 30, 2003 6:09 PM
    >
    > > > > I checked the firewall logs and saw quite a few attempts from
    > > > > a Google IP address (whois-ed, but I'm not ignoring that it
    > > > > was possibly spoofed) that was sending IN traffic with a
    > > > > source port of 80 and a destination port in the temporary
    > > > > range (33xx) - eh???

    I think that this is worthy of investigation just in and of itself. The type of traffic you describe is highly irregular.

    > > > Which firewall logs and what time frame? The Linksys before the
    > switchout,
    > > > the Linux-based firewall after the switchout, or something else?
    >
    > > My appologies, since I never considered the Linksys/DLink/etc. routers
    > > to be firewalls I've not addressed them as such - but I see others do
    > > (remind self that other's terminologies must be used when talking to
    > > them... :)
    >
    > Linksys calls it a firewall feature, and it has logs - but not everyone
    > agrees to call it that. Thanks for clarifying.

    I have often found that these features can produce other interesting anomalies in your network analysis. It can often pose an interesting conundrum when analysing traces from multiple locations.

    > > The firewall in question is an IPCop machine (this is a fork of the
    > > Smoothwall firewall project - www.ipcop.org) with no DHCP server,
    > > port-forwarding or HTTP proxy running - just a plain brown box... The
    > > incomings I saw were within approx. a 1-minute timeframe.
    >
    > > Unfortunately I am still enough of a Linux newbie that I have not
    > > figured out how to add a sniffer into IPCop (I could install ntop
    > > though...) but according to the firewall logs the traffic was pointed to
    > > the external NIC on the IPCop computer specifically which is the only
    > > public IP address on the LAN. All others are behind the IPCop's
    > > internal/private IP addressed NIC, and there is no DMZ NIC on the
    > > system, nor is it setup software-wise for one at the moment.
    >
    > > Also, all 6 updates of IPCop had been performed on the machine before
    > > installation.
    >
    > > If what could cause this sort of traffic is "mostly benign" then I'll
    > > have my goose-pimples set to "chill" - if not, then I'm still in "Eh?"
    > > mode...

    I can understand your stance. In this time of constant global issues it is reasonable to be interested to investigate even what seems to be benign to most of us.
    It may be worthy to spend some time looking into other analysis tools, such as network visualisation aids etc.

     
    > It's probably best to stay in investigative mode and learn some more about
    > the traffic before judging either way. Check outbound logs to see if there
    > is any traffic that is obviously related to your mystery traffic by time or
    > address. Sniff full packets with tethereal or ntop or whatever from a
    > trusted machine. Obfuscate your IP address in a text copy of the packets
    > that concern you and post a few to the list. Check open ports on the suspect
    > PC with nMap or another scanner from a trusted box, and run FPort or TCPView
    > on the suspect machine itself to identify processes that have opened ports.
    > Delete or obfuscate information you do not wish to share, and post the
    > remainder to the list.

    Yes this is valuable information and has served me well in the past.
     
    > You could also Google the IP address that is the source of your unexplained
    > traffic to see if anyone else might have posted comments about it, and look
    > it up at http://www.dshield.org/ipinfo.php to see if other people have
    > reported problems from that IP. The packets themselves may contain Googlable
    > information - see if there is something in common between the packets other
    > than source and destination.

    Sometimes it may not be just the packet contents themselves that is interesting. Maybe the packets and their arrival on the network signifies more than a mere Googling can provide.
    Just some food for thought!

    just1n

    -----BEGIN GEEK CODE BLOCK-----
    Version: 3.1
    GED/J d-- s:++>: a-- C++(++++) ULU++ P+ L++ E---- W+(-) N+++ o+ K+++ w---
    O- M+ V-- PS++>$ PE++>$ Y++ PGP++ t- 5+++ X++ R+++>$ tv+ b+ DI+++ D+++
    G+++++ e++ h r-- y++**
    ------END GEEK CODE BLOCK------

    -- 
    ____________________________________________________
    Get your own Hello Kitty email @ www.sanriotown.com
    Powered by Outblaze
    ---------------------------------------------------------------------------
    ----------------------------------------------------------------------------
    

  • Next message: Russell J. Lahti: "Re: flood of SYN packets to port 110"

    Relevant Pages

    • Re: [opensuse] SuseFirewall IPv4 vs IPv6
      ... # network security threats. ... # Opening ports for LAN services in the external zone defeats the ... # this setting only works for packets destined for the local machine. ... # If the protocol is icmp then port is interpreted as icmp type ...
      (SuSE)
    • Re: Ethernet issue: works one way but not another
      ... packets transmitted, 5 packets received, 0% packet loss ... (This is when connected directly to internet through ... FBSD, I have been working with BSDI at the isp I work for for the last ... As for my network topology, I have an internal network that goes ...
      (freebsd-questions)
    • Re: IDSIPS that can handle one Gig
      ... especially with 64-byte UDP packets. ... There are plenty of network IPS's ... IDS/IPS devices through use of fragments. ... Find out quickly and easily by testing it with real-world attacks from ...
      (Focus-IDS)
    • Re: Update: UDP 770 Potential Worm
      ... > the network immediately after the 'attack', ... were no packets indicating some form of replication. ... I noticed that the UDP ... > of the UDP datagrams is the IP address of the proxy? ...
      (Incidents)
    • Re: iptables and dhcp
      ... > the same physical network segment as the firewall and the remote DHCP ... You used INPUT and not FORWARD chain ... # This target allows packets to be marked in the mangle table ...
      (comp.os.linux.networking)