Re: [leaf-user] Unknown traffic on firewall
My Friend Ben Ong says, "No good dead goes unpunished." I prefer a more positive bent on life like the glass is half full. Please be patient and read on for a moment. A firewall is half of the security battle. A person wants to keep the bad guys out of a home network so that one can Samba Share a printer or other fun things like frag one another in quake or other LAN games for example. The firewall is there for convenience to access web pages for school work and other important stuff. Businesses want a firewall to protect their operation. A business may need to conduct lots of contact work through email but still need other applications that are not secure. The firewall protects the insecure applications. You still have to worry about trust on the protected side of the firewall. What is your mate, children, or in the case of businesses, employees installing on your client computers? All the protection that a LEAF firewall provides can be nullified, if a trojan is installed on the safe side of the firewall. I think that my situation is the funniest thing there is for several reasons. I think I answered Manfred's question, but was corrected on several key points unrelated to the answer. Hey, a mailing list won't let you get to far adrift. ;-) Thanks Jeff. Here's the knee slapper. School started for the kids August 19, 2002. The week before my oldest son had a friend stay for an extended sleep over so they could play LAN games. My wife was sorry she let the fragging go on for that many days. Last weekend my middle son says Dad the big computer--full towercase--isn't working right. I asked what did you guys install? He said nothing. I was thinking it was some CD based game causing a conflict. So I finally get the computer to boot into MS Windows. I had no problems with the PC because I was dual booting into Red Hat Linux when I used the computer. I can say this now while rolling on the floor laughing but good old KaZaa was installed. I found some sort of CD game key generator and another downloaded file. So now I have to council my kids about the difference between downloading GPL software and when other software is considered intellectual property and can't be tampered with. Fortunately, they were unsuccessful in creating a copy of Warcraft III. I explained to my son, you lose or give away that key and your copy of Warcraft III is lost. Moreover, the company considers that stealing if try to create non archival copies of their CDs. I can't wait. He's a screenager. Someday the little wanker between his legs will wake up and then he'll be susceptible to social engineering. I can hear it now, "Hey dude. Here's a picture of Miss April. All you have to do is run this .exe file to view her." Anyhow, I whacked KaZaa right away. Little did I know that KaZaa was half the issue. I started receiving the error "Windows could not upgrade the file %1 from %2". This happened after rebooting and MS Windows has to install DLL files that are in memory. I am sure you know the drill. There was an extended reboot time with the hard drive light pegged. I suspect that I improperly uninstalled KaZaa. Google pointed me to darnit based on the %1 from %2 message above. I used add/remove programs to get rid of "SaveNow", "b3d", "CYBERWORLD Browser", "DownloadWare, and "Media Loads Installer". These are all the benefits you receive from KaZaa's version of free software. Just like Juno, KaZaa wants to use your unused CPU cycles to solve computing problems for other people__and_at_your_expense!__ Note: that darnit takes a while to load because it is a hugh mega page. http://and.doxdesk.com/parasite/DownloadWare.html http://209.68.48.119/inetexplorer/Darnit.htm#Kazaa "Some choice quotes: "...The EULA, when found, claims that it may clash with various other software and so if it finds any it will remove it. (!)..." http://209.68.48.119/inetexplorer/Darnit.htm The computer still is not sound after the uninstalls. CommonName may be installed too. Well it is easy to mess up a good Windows install, but KaZaa can really foul it up beyond all measure. Ah but there's that cup half full angle I was looking for. I guess we will have an install festival this weekend. I don't trust my computers after the sleep over. My son's friend had no knowledge of the trojans he was installing for us. Like he's going to read the EULA let alone understand it. We'll reinstall MS Windows and dual boot Red Hat on both computers. Maybe I'll even have time to setup and an iMap mail server. I think I can use this as an excuse to have my wife answer her email on Linux. Moreover she can use Ximian which looks like outlook. She uses outlook at work. What a funny story. I help answer a question on a mailing list and I find out days later that I have the same KaZaa thief in my house. Those scurvy dogs! Why does the MS Windows oriented world think they have to own and know everything about a person? GPL so
Re: [leaf-user] Unknown traffic on firewall
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. > > > > > > > > > > > > > > > > > > > > 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
Re: [leaf-user] Unknown traffic on firewall
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. > > > > > > > > > > > > > > > > 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
Re: [leaf-user] Unknown traffic on firewall
Whoops, sorry Jack sending to the list On Monday 19 August 2002 13:53, 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? Good idea! I'll look into it! -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- 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
Re: [leaf-user] Unknown traffic on firewall
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? 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. > > > 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. > > > > > > > > > > > > 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. > > > > > 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. :) > > > > > 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. > > > > > 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. > > > > > I'd say that you didn't realize that you are running some sort of > > > peer to peer file sharing service, or you are running one and > > > didn't know the mechanics of how it works. Perhaps you are > > > running Kazaa? > > > > I think you are on target from this point forward. > > > > [Very nice subsequent analysis based on ip addresses and ports > > omitted.] > > > > - > >-- Jeff NewmillerThe . . > > Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. > > ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research > > Engineer (Solar/BatteriesO.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
Re: [leaf-user] Unknown traffic on firewall
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. 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. > > > > > > > > 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. > > > 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. :) > > > 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. > > > 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. > > > I'd say that you didn't realize that you are running some sort of > > peer to peer file sharing service, or you are running one and > > didn't know the mechanics of how it works. Perhaps you are > > running Kazaa? > > I think you are on target from this point forward. > > [Very nice subsequent analysis based on ip addresses and ports > omitted.] > > - >-- Jeff NewmillerThe . . > Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. > ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research > Engineer (Solar/BatteriesO.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 -- ~Lynn Avants aka Guitarlynn guitarlynn at users.sourceforge.net http://leaf.sourceforge.net If linux isn't the answer, you've probably got the wrong question! --- This sf.net email is sponsored by: OSDN - Tired
Re: [leaf-user] Unknown traffic on firewall
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. > > > 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. > 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. :) > 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. > 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. > I'd say that you didn't realize that you are running some sort of peer > to peer file sharing service, or you are running one and didn't know the > mechanics of how it works. Perhaps you are running Kazaa? I think you are on target from this point forward. [Very nice subsequent analysis based on ip addresses and ports omitted.] --- Jeff NewmillerThe . . Go Live... DCN:<[EMAIL PROTECTED]>Basics: ##.#. ##.#. Live Go... Live: OO#.. Dead: OO#.. Playing Research Engineer (Solar/BatteriesO.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
Re: [leaf-user] Unknown traffic on firewall
Port 1214 is used by the filesharing application Kazaa. Recently a vulnerablitiy must have come up because I have been seeing regular scans on a daily basis from different ip's for about a month now. As David already replied you are not accepting nor deny'ing them but you are rejecting them. Only difference is that you do reply with a reset packet to close off the session. Well I guess you could say it is slightly more polite then not responding at all :-). Unfortunately it is also telling that your machine is up & is doing some filtering so you could consider it slightly less secure as well. Kim Oppalfens >> What I don't understand is why the packets are not denied and who is responding >to this >> packets. > >> tcpdump: >> >> 13:24:08.722724 213.168.220.62.2605 > 80.134.34.59.1214: S 229201904:229201904(0) >win 8192 >> (DF) >> 13:24:08.722724 80.134.34.59.1214 > 213.168.220.62.2605: R 0:0(0) ack 229201905 >win 0 >> 13:24:09.752724 213.168.220.62.2605 > 80.134.34.59.1214: S 229201904:229201904(0) >win 8192 >> (DF) >> 13:24:09.752724 80.134.34.59.1214 > 213.168.220.62.2605: R 0:0(0) ack 1 >win 0 >> 13:24:10.452724 213.168.220.62.2605 > 80.134.34.59.1214: S 229201904:229201904(0) >win 8192 >> (DF) >> 13:24:10.452724 80.134.34.59.1214 > 213.168.220.62.2605: R 0:0(0) ack 1 >win 0 >> 13:24:11.352724 213.168.220.62.2605 > 80.134.34.59.1214: S 229201904:229201904(0) >win 8192 >> (DF) >> 13:24:11.352724 80.134.34.59.1214 > 213.168.220.62.2605: R 0:0(0) ack 1 >win 0 > > >Looking at your output, they are sending you some sort of packet destined >for >port 1214 on your firewall (80.134.34.59) and your firewall IS rejecting >it, >using the TCP RST flag (ReSeT). Your firewall can send a RST, or ignore >the >packet entirely; in this case, it sends a RST. > >I don't know what port 1214 is supposed to be for, but port 2605 is BGP (a >routing >protocol) - surprise surprise... > > > >--- >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 --- 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
Re: [leaf-user] Unknown traffic on firewall
On Sun, Aug 18, 2002 at 11:30:55PM +0200, Manfred Schuler wrote: > 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. > tcpdump: > > 13:24:08.722724 213.168.220.62.2605 > 80.134.34.59.1214: S 229201904:229201904(0) >win 8192 > (DF) > 13:24:08.722724 80.134.34.59.1214 > 213.168.220.62.2605: R 0:0(0) ack 229201905 win 0 > 13:24:09.752724 213.168.220.62.2605 > 80.134.34.59.1214: S 229201904:229201904(0) >win 8192 > (DF) > 13:24:09.752724 80.134.34.59.1214 > 213.168.220.62.2605: R 0:0(0) ack 1 win 0 > 13:24:10.452724 213.168.220.62.2605 > 80.134.34.59.1214: S 229201904:229201904(0) >win 8192 > (DF) > 13:24:10.452724 80.134.34.59.1214 > 213.168.220.62.2605: R 0:0(0) ack 1 win 0 > 13:24:11.352724 213.168.220.62.2605 > 80.134.34.59.1214: S 229201904:229201904(0) >win 8192 > (DF) > 13:24:11.352724 80.134.34.59.1214 > 213.168.220.62.2605: R 0:0(0) ack 1 win 0 According to whois, the source is coming from (abridged output): inetnum: 213.168.220.0 - 213.168.220.255 netname: NORDCOM descr: nordCom descr: dynamic dialin for internet services country: DE admin-c: HNC-ORG tech-c: HNC-ORG status: ASSIGNED PA mnt-by: NORDCOM-MNT changed: [EMAIL PROTECTED] 20010427 source: RIPE route:213.168.192.0/19 descr:nordCom Routing origin: AS13247 notify: [EMAIL PROTECTED] mnt-by: NORDCOM-MNT changed: [EMAIL PROTECTED] 2703 source: RIPE role: Hostmaster Nordcom address: Nordcom address: Doetlinger Str. 6-8 address: D-28197 Bremen address: Germany e-mail: [EMAIL PROTECTED] Looking at your output, they are sending you some sort of packet destined for port 1214 on your firewall (80.134.34.59) and your firewall IS rejecting it, using the TCP RST flag (ReSeT). Your firewall can send a RST, or ignore the packet entirely; in this case, it sends a RST. I don't know what port 1214 is supposed to be for, but port 2605 is BGP (a routing protocol) - surprise surprise... --- 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
Re: [leaf-user] Unknown traffic on firewall
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. 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) A port is also called a service. The services are defined in /etc/services. A protocol, plus, a port number, and an ip address equals a socket that an application uses to talk to another application. All this information is supplied in case you didn't know this. I'd say that you didn't realize that you are running some sort of peer to peer file sharing service, or you are running one and didn't know the mechanics of how it works. Perhaps you are running Kazaa? > Aug 18 13:24:08 tunix kernel: Packet log: input - ppp0 PROTO=6 213.168.220.62:2605 >80.134.34.59:1214 L=48 S=0x00 I=29010 F=0x4000 T=114 SYN (#1) This is the first line you supplied from your log. 80.134.34.59 appears to be your current ip address supplied by your ISP. 1214 is the port number used by the application i.e. 80.134.34.59:1214. Notice too that this entry is from the input chain. google.com coughed up this with port showing Kazaa. http://www.ec11.dial.pipex.com/port-num1.shtml#1200 1214 Kazaa Morpheus or KaZaA peer to peer music/file sharing > Aug 18 13:24:08 tunix kernel: Packet log: output - ppp0 PROTO=6 80.134.34.59:1214 >213.168.220.62:2605 L=40 S=0x00 I=14602 F=0x T=255 (#1) This is the second line you supplied from your log. It is an output chain entry. Your firewall is responding back to ip address 213.168.220.62 and port 2605. The firewall is doing its job as NAT--network address translation. It translates the internal network address of your client PC to the firewall's IP address. There are a number of services that use ports 2600 through 2606. The name networksciences.net came up on one of the services list again supplied by google. If you look at the information I copied from their web site below, networksciences.net appears to supply tools to simplify the task a building a client sever application. I may be speculating wildly here, but perhaps Morpheus uses this tool in their application? seanecovel at attbi dot com supplied this sometime ago in the thread "Re: [leaf-user] Blocking protocols at certain times" http://documents.iss.net/whitepapers/X-Force_P2P.pdf I found it an interesting read. The angle of the document is how as a network admin do I reduce the risk of all these file and instant messaging systems? The issue in a business is one of trust. Do you really trust that these applications won't become a trojan, etc. The question for you as an individual is, if you are running Morpheus, do you want it serving data all the time? peer to peer applications still have a server component to them. If someone finds an exploitable hole in morpheus they can gain access to your client. This is why web servers are always being patched. Known holes must be patched or the web service will be "owned" by someone else. Please just be aware of the issues. You could become overly paranoid and not use any application. I think one of the most alarming concepts is how companies like Microsoft feel it is their right or duty to know about you. I not sure I'd trust aol any more on this one. MS Windows Media Player is supposed to send data about your media playing habits to a web site. How are you going to block that, if they are using port 80 that all web servers use? The firewall does not always block all ports. Some ports are used for other services and should be allowed out. I bring this up because the 260x port range appear to have some other useful ports. Here's the batch file I run on Windows ME every once in awhile to clear the MS media database, which includes the number of times you have played a song. The location is in a slightly differenct place on MS Windows 2000 and MS Windows XP. @echo off rem http://www.w2knews.com/index.cfm?id=352 Rem kill wmp database cd "C:\WINDOWS\All Users\Application Data\Microsoft\Media Index" attrib -r *.* del WMPLIBrary*.* I hope this helps, Greg P.S. here's the other port info and stuff on Network Sciences. http://www.mit.edu/afs/athena/system/rhlinux/config/9.1.10/etc/services # Ports numbered 2600 through 2606 are used by the zebra package without # being registered. The primary names are the registered names, and the # unregistered names
[leaf-user] Unknown traffic on firewall
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. If you need additional information, please ask for it. Log Entries: Aug 18 13:24:08 tunix kernel: Packet log: input - ppp0 PROTO=6 213.168.220.62:2605 80.134. 34.59:1214 L=48 S=0x00 I=29010 F=0x4000 T=114 SYN (#1) Aug 18 13:24:08 tunix kernel: Packet log: output - ppp0 PROTO=6 80.134.34.59:1214 213.168. 220.62:2605 L=40 S=0x00 I=14602 F=0x T=255 (#1) Aug 18 13:24:09 tunix kernel: Packet log: input - ppp0 PROTO=6 213.168.220.62:2605 80.134. 34.59:1214 L=48 S=0x00 I=33106 F=0x4000 T=114 SYN (#1) Aug 18 13:24:09 tunix kernel: Packet log: output - ppp0 PROTO=6 80.134.34.59:1214 213.168. 220.62:2605 L=40 S=0x00 I=14603 F=0x T=255 (#1) Aug 18 13:24:10 tunix kernel: Packet log: input - ppp0 PROTO=6 213.168.220.62:2605 80.134. 34.59:1214 L=48 S=0x00 I=35666 F=0x4000 T=114 SYN (#1) Aug 18 13:24:10 tunix kernel: Packet log: output - ppp0 PROTO=6 80.134.34.59:1214 213.168. 220.62:2605 L=40 S=0x00 I=14604 F=0x T=255 (#1) Aug 18 13:24:11 tunix kernel: Packet log: input - ppp0 PROTO=6 213.168.220.62:2605 80.134. 34.59:1214 L=48 S=0x00 I=38482 F=0x4000 T=114 SYN (#1) Aug 18 13:24:11 tunix kernel: Packet log: output - ppp0 PROTO=6 80.134.34.59:1214 213.168. 220.62:2605 L=40 S=0x00 I=14605 F=0x T=255 (#1) tcpdump: 13:24:08.722724 213.168.220.62.2605 > 80.134.34.59.1214: S 229201904:229201904(0) win 8192 (DF) 13:24:08.722724 80.134.34.59.1214 > 213.168.220.62.2605: R 0:0(0) ack 229201905 win 0 13:24:09.752724 213.168.220.62.2605 > 80.134.34.59.1214: S 229201904:229201904(0) win 8192 (DF) 13:24:09.752724 80.134.34.59.1214 > 213.168.220.62.2605: R 0:0(0) ack 1 win 0 13:24:10.452724 213.168.220.62.2605 > 80.134.34.59.1214: S 229201904:229201904(0) win 8192 (DF) 13:24:10.452724 80.134.34.59.1214 > 213.168.220.62.2605: R 0:0(0) ack 1 win 0 13:24:11.352724 213.168.220.62.2605 > 80.134.34.59.1214: S 229201904:229201904(0) win 8192 (DF) 13:24:11.352724 80.134.34.59.1214 > 213.168.220.62.2605: R 0:0(0) ack 1 win 0 -- Manfred Schuler E_Mail: mailto:[EMAIL PROTECTED] --- 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
