On Mon, 2002-08-19 at 17:25, Jeff Newmiller wrote: > 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".
http://www.monkeynoodle.org/lrp/lrp-firewall-faq.html of course :-) However, I just looked for it under the leaf.sourceforge.net documents tree and cannot find it. I will see what I can do about fixing that tonight... > > > 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 > -- Jack Coates Monkeynoodle: A Scientific Venture... ------------------------------------------------------- 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
