home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / protocol / tcpip / 3933 < prev    next >
Encoding:
Text File  |  1992-07-31  |  1.3 KB  |  30 lines
  1. Newsgroups: comp.protocols.tcp-ip
  2. Path: sparky!uunet!rosevax!medtron!rh0083b
  3. From: rh0083b@medtronic.COM (Roger-Hunen)
  4. Subject: Re: Stopping only incoming TCP connections (was: Firewall usage)
  5. Message-ID: <1992Jul31.074154.4081@medtron.medtronic.com>
  6. Sender: news@medtron.medtronic.com (USENET News Administration)
  7. Nntp-Posting-Host: tin.pace.medtronic.com
  8. Organization: Medtronic, Inc.
  9. References: <17011@ulysses.att.com> <1992Jul28.202211.14029@shearson.com> <chrisc.21.712446813@ramrod.lmt.mn.org>
  10. Date: Fri, 31 Jul 1992 07:41:54 GMT
  11. Lines: 17
  12.  
  13. In article <chrisc.21.712446813@ramrod.lmt.mn.org> chrisc@ramrod.lmt.mn.org (Chris Cox) writes:
  14. >>I was under the impression that if you filter all the SYN packets from
  15. >>one direction that aren't SYN ACKs, bingo, you can't initiate any
  16. >>incoming TCP connections.  Nice and stateless. The only flaw is that
  17. >>implementations that seperately ACK the initiating SYN and then send
  18. >>their own SYN won't be able to connect, but they are rare. Connections
  19. >
  20. >That would eliminate your users from starting ftp data sessions (wouldn't 
  21. >it?).
  22.  
  23. So what you really want is application level proxies in the firewall for
  24. TELNET, FTP, MAIL etc. Of course this defaults to the 'everything is
  25. forbidden unless permitted' approach.
  26.  
  27. Regards,
  28. -Roger
  29.  
  30.