On 19 Aug 2002, Jack Coates wrote: > I think it's already covered in the Firewall FAQ, but I agree that > Greg's coverage of sockets would be helpful. Perhaps a diff to the > firewall FAQ?
What FAQ? I am not familiar with this "Firewall FAQ". > Jack > > On Mon, 2002-08-19 at 11:45, guitarlynn wrote: > > This would make an excellent FAQ. > > If one of you would like to write it up and finish it, I would > > be more than willing to format it and submit it. I think there were a series of issues here, so there may be a series of FAQs. > > On Monday 19 August 2002 01:34, Jeff Newmiller wrote: > > > On Sun, 18 Aug 2002, Greg Morgan wrote: > > > > Manfred Schuler wrote: > > > > > Hi all, > > > > > > > > > > in the last few weeks I discovered some unknown traffic on my > > > > > firewall. I inserted a rule to log all traffic on the input and > > > > > output chains and found that the incoming packet is neither > > > > > rejected nor denied, but answered by the firewall. I am using a > > > > > stock eigerstein2beta firewall with no port redirection and no > > > > > additional ports opened. > > > > > > > > > > What I don't understand is why the packets are not denied and who > > > > > is responding to this packets. > > > > > > > > <snip> > > > > > > > > Manfred, > > > > > > > > I've never seen these ports before, but hey with 65K available port > > > > numbers, there are all kinds of services available. ;-) I was > > > > curious so I spent some time looking into your question. I may or > > > > may not have answered the question for you, but I guess it did give > > > > me a chance to get up on the soap box. >:-> (evil grin) > > > > > > Careful... it looks unsteady up there... don't use a weak > > > foundation... > > > > > > > A port is also called a service. > > > > > > Not correctly. A service is the program that responds when the port > > > is accessed. Q: What is a port? A: In the Transmission Control Protocol (TCP) and Unreliable Datagram Protocol (UDP) protocols commonly used within the Internet Protocol (IP), a port is a number used to help distinguish the origin and/or destinations of packets. Ports are related to IP addresses in a manner similar to the way apartment numbers are related to the address of the apartment building. Q: What is a service? A: A service is a program that responds when communication (one or more packets) arrives at the destination ip with a particular port number. For example, the Apache web server may be configured to respond to tcp packets that specify destination port 80. Alternatively, the "sh-httpd" web server may be used instead, with essentially similar results. More confusingly, the "sshd" Secure Shell Daemon may be configured to respond to port 80, though this will naturally yield very different results. This might be done by a LEAF user to let her get out of a particularly constrictive firewall at work that allows web browsing but denies outbound "ssh connections" to their typical port 22 destination. Whether this is a danger to the work network depends on what this user does with this connection. > > > > The services are defined in /etc/services. > > > > > > This file defines your mapping of services to ports. The fact that > > > we usually stick with the one provided is beside the point, and we > > > (and certainly the untrusted masses "out there") may choose to modify > > > it at any time, so all our interpolations from "ports" in the > > > firewall log is just overly-educated guesswork. :) Q: What is /etc/services? A: This file is used to define a mapping between tcp and udp port numbers, and short names for the services that typically respond at those ports. Note that this file does not indicate which services actually respond to those ports, since that is defined by starting the various programs that provide those services. Many programs refer to this file when you are expected to specify a port number, so that you can specify the text name of the service as a syntactic convenience rather than typing a number. > > > > A protocol, > > > > > > which you failed to define in context... tcp and udp are the most > > > common protocols in the Internet Protocol sense of the word, and if > > > you are only interested in vanilla internet activity it is easy to > > > forget that others exist that don't even include the concept of > > > "ports". Many people also regard "http" and "ftp" and "CIFS" as > > > protocols, but that is a confusingly different usage of the term than > > > the one you are referring to. The only way to be sure which > > > "protocols" help define a socket is to refer to the software > > > documentation for your networking stack, because sockets are not > > > limited even to the Internet Protocol... they can be used with > > > Appletalk, IPX, or even "internal" communications methods that are > > > not network related. Q: What is a protocol? A: In the context of firewalls, a protocol is an agreed "language" by which information may be exchanged. Typically, operating system software must peel off the packet wrapper information one layer at a time, keeping track of which protocol is wrapped using information found in the "wrapper" (header), and as necessary digging deeper into the packet based on knowing which protocols were wrapped up. There are "low level" protocols that define how data bits may be exchanged, and also "high level" protocols that define what sequences of bits are "legal" in a particular context. Low level protocols typically include a few well-defined bits at the beginning of a packet (the header), and a generic block of "data" bits after the header. High level protocols are more likely to emulate the kinds of typed exchanges that a patient programmer might type in, with "commands" sent and "responses" received. Some protocols operate at the hardware-dependent layer (very low level)... for purposes of Internet Protocol firewalls, these levesl may be neglected other than to note that they exist (Ethernet, Token Ring, serial point-to-point) and they generally distinguish IP packets from other kinds of packets (SNA,IPX,Vines). For Ethernet IEEE802, IP is marked as type number 6 in every packet (see http://www.wildpackets.com/compendium/REF/REF-SAP.html). A LEAF packet filtering firewall typically concerns itself only with the medium-level protocols that are variations built on IP such as UDP, TCP, GRE, ICMP and so forth. These IP packets are stuffed inside the low-level packet's data portion. These protocols are identified by a number set aside in every IP packet. (http://www.iana.org/assignments/protocol-numbers) Higher-level protocols such as FTP, HTTP, CIFS, and so forth are typically treated as generic data packaged inside the medium-level protocols. A full-service firewall would actually parse the high-level protocols as well to insure that the expected high-level protocols are in use. (This is to avoid allowing connections like tunnelling SSH connections through HTTP ports, which can support unapproved exchanges of information that the firewall is intended to prevent). Modern protocols like SOAP build on protocols like http to create very high level information exchange capabilites, that are now starting to create difficulties for firewalls where there is cooperation on the inside. Q: What is a byte? A: The smallest addressable unit of data for a specific computer architecture. Q: What is an octet? A: 8 bits. While in the majority of cases, this is the same as a "byte", for some computers a byte may not be 8 bits. Internet Protocol is defined in terms of "octets". Q: What is UDP? A: UDP is a medium level protocol that supports transfer from a source to a destination of a few tens or hundreds of octets of data. Each IP address stored in the generic IP header is augmented with a port number in the UDP header to allow multiple destinations for data at each destination computer/device. No guarantees are implied that a packet will arrive on time, before or after any other packet that was sent, or even that it will arrive at all. This lack of guarantee is sometimes acceptable when low-overhead (fast) updates of small amounts of information are desired. Q: What is TCP? A: TCP is a medium level protocol that forms a data channel capable of exchanging a continuous bidirectional stream of data bits. It does this using an elaborate algorithm for re-transmitting and verifying receipt of every packet sent. This is useful because an arbitrarily long block of data can be transferred through such a data channel without having packets delivered to the receiving program out of order. As with UDP, each ip address is augmented with a port number to allow multiple sources/destinations for data at each computer/device. Note that a TCP connection is uniquely defined by the source and destination ip addresses, and source and destination port numbers. Between any two ip addresses, only one connection with a particular combination of source and destination port numbers is allowed at any one time. Note that since each computer has many port numbers, many simultaneous TCP connections can be active at one time. In fact, it is very common to have multiple connections to, for example, port 80, from a single client, as a web browser constructs a page from multiple images in conjunction with the base html file. When reviewing firewall logs, it is worth knowing that the initial packets of a connection include a SYN flag, and that the closing packets of a connection include the FIN flag. A firewall log will usually record these flags, though not always in a decoded form (e.g. ipchains). Refer to RFC793 for the definitive explanation of the sequences of flags, their location in the packet header and sequence numbers that may occur in a tcp connection. Most high-level internet protocols are built on top of TCP. > > > > plus, a port number, and an ip address > > > > equals a socket that an application uses to talk to another > > > > application. > > > > > > Via tcp or udp. Other protocols may omit the port and still have > > > sockets. In fact, the "ports" defined by udp may be assigned to > > > completely different services than the "ports" defined by tcp, though > > > in the typical case for a given "port number" only the tcp or udp > > > version is actually used and the other is reserved to avoid > > > confusion. > > > > > > > All this information is supplied in case you didn't know > > > > this. > > > > > > The "socket" is a software construct that is not really necessary to > > > understand in order to read a firewall log. Nice background if you > > > know it, but not germane to any of the points you make after this, > > > regrettably confusing if described correctly, and unfortunately wrong > > > if presented too simplistically. Q: What is a socket? A: A socket is a software object that supports communication between independent programs. (http://nodevice.com/sections/ManIndex/man1507.html) Associated with sockets are methods that allow the program using them to send data or be notified when incoming data are available, potentially from numerous sources, so that generalized intercommunication between multiple sources and destinations of data can be built. The traditional "sockets" interface supports communication entirely within the host, with no networking involved at all (AF_UNIX), so sockets are not limited to networking only. In the context of internet firewalls, the most common forms of sockets are those attached to TCP and UDP ports. In particular, a TCP socket records the source IP address, destination IP address, source port number, and destination port number. With this information stored, the program need only "send" data and it will be packetized and transmitted, and any packets received can automatically be sorted into their original order and supplied to the program as they were sent. Because sockets are simply one possible means to keep track of communication control information that are already precisely defined in the protocols, understanding their operation is not critical in interpreting firewall logs. ---- I think of these definitions mostly as useful items to link to, rather than FAQs in and of themselves. If you can think of a good place to put them, go for it. --------------------------------------------------------------------------- Jeff Newmiller The ..... ..... Go Live... DCN:<[EMAIL PROTECTED]> Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/Batteries O.O#. #.O#. with /Software/Embedded Controllers) .OO#. .OO#. rocks...2k --------------------------------------------------------------------------- ------------------------------------------------------- This sf.net email is sponsored by: OSDN - Tired of that same old cell phone? Get a new here for FREE! https://www.inphonic.com/r.asp?r=sourceforge1&refcode1=vs3390 ------------------------------------------------------------------------ leaf-user mailing list: [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/leaf-user SR FAQ: http://leaf-project.org/pub/doc/docmanager/docid_1891.html
