Re: How to tell if a firewall alert is suspicious or not

From: Volker Birk (bumens_at_dingens.org)
Date: 09/16/05

  • Next message: Volker Birk: "Re: Disabling my Firewall" 
    Date: 16 Sep 2005 12:29:56 +0200

    Gerard Schroeder <Gshroeder22031@hotmail.com> wrote:
    > For example, when Adobe Acrobat 6.0 (Acrobat.exe) [206.13.31.12] contacts
    > me on local port 1880 (VSAT-CONTROL - Gilat VSAT Control), I can find the
    > name of the machine contacting me from www.dnsstuff.com as
    > "dns1.scrmca.sbcglobal.net" ... but that does not tell me anything about
    > WHY this SBCGlobal DNS server would be contacting Adobe Acrobat on port
    > 1880 (whatever that port is for).

    I think, you're misinterpreting this message completely. I assume, that
    the Acrobat program is running on your own host, and if you're reciting
    correctly, then 206.13.31.12 was your own IP address.

    Perhaps you first should try to understand what an IP address is, what
    a port is (it's not a "door" or even a "harbour", but only a maintainance
    number), and how sockets are working and what they're used for.

    Perhaps you could start with Craig Hunt's book, as I mentioned already.

    First you should understand, how classical operating systems work, like
    *NIX systems or Windows.

    They have to parts, a kernel and the userland, in which programs, which are
    running, are called "processes".

    The kernel is a program, which controlles anything which is going on,
    including the other programs, the processes.

    To make a stable system, code of processes may not influence memory
    of the other processes at all - this the kernel is asserting with a
    technic called "protection". This means, if code of a process tries
    to do any I/O itself, or tries to influence the memory of other processes,
    then the kernel just stops this process immediately - on Windows systems,
    "Dr. Watson" arrives ;-)

    But sometimes it's necessary, that two processes can communicate. For
    example, you want to have results of your spread*** in your wordprocessor.
    Technics, which are allowing this as exceptions from the protection,
    are called "Inter-Process Communication", IPC.

    (IPC has to be controlled by the kernel, BTW. It is a big design flaw
    in Windows, that uncontrolled IPC with Windows messages is possible
    between processes which open Windows on the same Desktop.)

    Sometimes, IPC has to be done through the network. For example, if the
    process, which represents/implements your webbrowser should show information
    from a webserver, which is represented by another process, perhaps on
    another machine, then this will be implemented with IPC also: IPC through
    the net.

    Usually, it's implemented with network protocols like TCP, and with an
    API like the BSD socket API (this is i.e. with Linux, BSDs and Windows,
    with commercial UNIXes you'll have XTI as an alternative to the socket
    API).

    With Internet Protocol and TCP it is so, that any network interface in the
    network has a unique number, the IP address. This is a 32bit number,
    unfortunately usually written in a very strange way (writing decimal
    numbers for each single octet, separated by dots like "206.13.31.12").

    TCP sockets are a technic to have a bidirectional communication connection
    from one process running on one machine to a second process running on
    the same machine or another one in the network.

    It is possible, that more than one process can communicate through one
    network interface with a TCP socket at one time; so we need a second
    maintainance number to identify one connection from one process to
    another.

    This is done by adding a port number. The protocol, TCP, the interface
    number, the IP address, and third the port number are identifying one
    endpoint of a TCP connection; two sets of those three numbers (also the
    protocols are numbered, TCP is number 6) identify one single connection.

    The port number is a 16bit number, which is not 0.

    With TCP, all communication is following the client/server pattern.
    That means, one process has the role of the server, and one process
    has the role of the client.

    For example, a webserver has the role of the server, and a webbrowser
    has the role of the client.

    To initiate a TCP connection, first the server has to "listen" on a port.
    That means, it opens one endpoint with the system call listen(), which
    means, that the process tells the kernel, that if there will be information
    arriving on this network interface (or any network interface, if the
    endpoint is opened for interface 0.0.0.0), which leads into initiating
    a TCP connection, then the kernel should send this information to the
    server process, which called listen() for this type of connection, say:
    for this port number.

    If a webbrowser now wants to open a TCP connection to our webserver (in
    this example), then it sends a speacial IP packet, which is called a
    SYN cookie, see RFC 793, together with the information, on which port
    it wants to send this information. To do this, also the webbrowser has
    to open an TCP endpoint first on it's own machine and on one interface
    there. It does this by using the system call connect(), which opens
    such an endpoint from the process, in which the webbrowser is running,
    to the network kernel, and second such a TCP syncookie is being sent
    to the other machine by the kernel (you remember, only the kernel code
    is allowed to do I/O ;-)

    If the other kernel is answering with SYN,ACK, then it want's to
    communicate and is trying to establish the TCP connection with it's
    webserver. The kernel with the webbrowser then answers with ACK, which
    means, that now all is clear, and the connection is established (see
    3.4 in RFC 793).

    Since then, when one of both processes is writing data to its endpoint
    of the TCP connection, its kernel is sending this in a reliable way to
    the other kernel, which is transmitting this data to the other process,
    which can read it and vice versa.

    This is how TCP works.

    Perhaps you now can start to interpret the message of your "Personal
    Firewall" ;-)

    Hint: you only know the names of the files, in which the programs are
    stored, which are building processes when run, like "acrobat.exe", for
    your own machine.

    About processes of other machines you know nothing like that. You only
    know, with what maintainance number - port number - their network
    connection to you is being managed by the kernel of the other machine.

    Yours,
    VB. 

    -- 
"Es kann nicht sein, dass die Frustrierten in Rom bestimmen, was in
deutschen Schlafzimmern passiert".
                                    Harald Schmidt zum "Weltjugendtag"
  • Next message: Volker Birk: "Re: Disabling my Firewall"