Re: PIX Question [7:65095]
Was this NAT or PAT? If PAT, and the client kept on trying to open up new connections, the source port would probably be different for each, thus a new xlate in the translation table. Cheers1 -- Richard A. Deal Visit my home page at http://home.cfl.rr.com/dealgroup/ Author of Cisco PIX Firewalls, CCNA Secrets Revealed!, CCNP Remote Access Exam Prep, CCNP Switching Exam Cram, and CCNP Cisco LAN Switch Configuration Exam Cram Cisco Test Prep author for QuizWare, providing the most comprehensive Cisco exams on the market. John Neiberger wrote in message news:[EMAIL PROTECTED] I don't understand why the xlate table would grow. I can understand the connections table growing, sure, but did the PIX really re-translate the same internal address over 7000 times in just few minutes? John Scott Roberts 3/13/03 11:08:29 AM strange that it would create another translation instead of using the old one?? I suppose its more an error in the client software thinking it still has a valid server connection and tries to open a brand new one then. the only thing that comes to my mind would be to expire your translations faster, but I've never done this, so I don't even know if its possible. scott Manny wrote in message news:[EMAIL PROTECTED] I ran into a situation today where we had a machine that was trying to FTP through the firewall. We allow FTP outbound. The problem that came up was that the user had no idea that an FTP client was setup on his machine. The FTP client (spyware) kept trying to connect to a server (ispynow.com) using the incorrect user name and password. For every attempt an xlate entry was created. It created about 7000 entries in a matter of minutes. The firewall was paralyzed. I had to console in and look at the xlate table. Even through the console I had a hard time viewing the table. Is there any way to prevent this from happening again?This is the second time this year an incident of this nature with the xlate table has occurred. How can I monitor the xlate table for strange behavior? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65638t=65095 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
RE: PIX Question [7:65095]
New source port for each outbound FTP connection probably. Symon -Original Message- From: John Neiberger [mailto:[EMAIL PROTECTED] Sent: 13 March 2003 18:12 To: [EMAIL PROTECTED] Subject: Re: PIX Question [7:65095] I don't understand why the xlate table would grow. I can understand the connections table growing, sure, but did the PIX really re-translate the same internal address over 7000 times in just few minutes? John Scott Roberts 3/13/03 11:08:29 AM strange that it would create another translation instead of using the old one?? I suppose its more an error in the client software thinking it still has a valid server connection and tries to open a brand new one then. the only thing that comes to my mind would be to expire your translations faster, but I've never done this, so I don't even know if its possible. scott Manny wrote in message news:[EMAIL PROTECTED] I ran into a situation today where we had a machine that was trying to FTP through the firewall. We allow FTP outbound. The problem that came up was that the user had no idea that an FTP client was setup on his machine. The FTP client (spyware) kept trying to connect to a server (ispynow.com) using the incorrect user name and password. For every attempt an xlate entry was created. It created about 7000 entries in a matter of minutes. The firewall was paralyzed. I had to console in and look at the xlate table. Even through the console I had a hard time viewing the table. Is there any way to prevent this from happening again?This is the second time this year an incident of this nature with the xlate table has occurred. How can I monitor the xlate table for strange behavior? = This email has been content filtered and subject to spam filtering. If you consider this email is unsolicited please forward the email to [EMAIL PROTECTED] and request that the sender's domain be blocked from sending any further emails. = = Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65406t=65095 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PIX Question [7:65095]
Was this NAT or PAT? If PAT, and the client kept on trying to open up new connections, the source port would probably be different for each, thus a new xlate in the translation table. Cheers1 -- Richard A. Deal Visit my home page at http://home.cfl.rr.com/dealgroup/ Author of Cisco PIX Firewalls, CCNA Secrets Revealed!, CCNP Remote Access Exam Prep, CCNP Switching Exam Cram, and CCNP Cisco LAN Switch Configuration Exam Cram Cisco Test Prep author for QuizWare, providing the most comprehensive Cisco exams on the market. John Neiberger wrote in message news:[EMAIL PROTECTED] I don't understand why the xlate table would grow. I can understand the connections table growing, sure, but did the PIX really re-translate the same internal address over 7000 times in just few minutes? John Scott Roberts 3/13/03 11:08:29 AM strange that it would create another translation instead of using the old one?? I suppose its more an error in the client software thinking it still has a valid server connection and tries to open a brand new one then. the only thing that comes to my mind would be to expire your translations faster, but I've never done this, so I don't even know if its possible. scott Manny wrote in message news:[EMAIL PROTECTED] I ran into a situation today where we had a machine that was trying to FTP through the firewall. We allow FTP outbound. The problem that came up was that the user had no idea that an FTP client was setup on his machine. The FTP client (spyware) kept trying to connect to a server (ispynow.com) using the incorrect user name and password. For every attempt an xlate entry was created. It created about 7000 entries in a matter of minutes. The firewall was paralyzed. I had to console in and look at the xlate table. Even through the console I had a hard time viewing the table. Is there any way to prevent this from happening again?This is the second time this year an incident of this nature with the xlate table has occurred. How can I monitor the xlate table for strange behavior? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65380t=65095 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PIX Question [7:65095]
strange that it would create another translation instead of using the old one?? I suppose its more an error in the client software thinking it still has a valid server connection and tries to open a brand new one then. the only thing that comes to my mind would be to expire your translations faster, but I've never done this, so I don't even know if its possible. scott Manny wrote in message news:[EMAIL PROTECTED] I ran into a situation today where we had a machine that was trying to FTP through the firewall. We allow FTP outbound. The problem that came up was that the user had no idea that an FTP client was setup on his machine. The FTP client (spyware) kept trying to connect to a server (ispynow.com) using the incorrect user name and password. For every attempt an xlate entry was created. It created about 7000 entries in a matter of minutes. The firewall was paralyzed. I had to console in and look at the xlate table. Even through the console I had a hard time viewing the table. Is there any way to prevent this from happening again?This is the second time this year an incident of this nature with the xlate table has occurred. How can I monitor the xlate table for strange behavior? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65331t=65095 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PIX Question [7:65095]
I don't understand why the xlate table would grow. I can understand the connections table growing, sure, but did the PIX really re-translate the same internal address over 7000 times in just few minutes? John Scott Roberts 3/13/03 11:08:29 AM strange that it would create another translation instead of using the old one?? I suppose its more an error in the client software thinking it still has a valid server connection and tries to open a brand new one then. the only thing that comes to my mind would be to expire your translations faster, but I've never done this, so I don't even know if its possible. scott Manny wrote in message news:[EMAIL PROTECTED] I ran into a situation today where we had a machine that was trying to FTP through the firewall. We allow FTP outbound. The problem that came up was that the user had no idea that an FTP client was setup on his machine. The FTP client (spyware) kept trying to connect to a server (ispynow.com) using the incorrect user name and password. For every attempt an xlate entry was created. It created about 7000 entries in a matter of minutes. The firewall was paralyzed. I had to console in and look at the xlate table. Even through the console I had a hard time viewing the table. Is there any way to prevent this from happening again?This is the second time this year an incident of this nature with the xlate table has occurred. How can I monitor the xlate table for strange behavior? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65342t=65095 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PIX Question [7:65095]
Manny, Yes, you can limit the maximum number of connections to a device and the maximum number of half-open (embryonic) connections. This is done with the NAT command, at least in your case, since the connections are going from high-to-low security levels. The NAT command allows you to specify these two parameters. You'll need to be careful as to what you set them to, otherwise you might be preventing legitimate connections. By the way, the defaults for these values is the limit of your connection license, so as you have seen, an internal user could easily (purposefully or not) create a DoS attack and paralyze your network. Cheers! -- Richard A. Deal Visit my home page at http://home.cfl.rr.com/dealgroup/ Author of Cisco PIX Firewalls, CCNA Secrets Revealed!, CCNP Remote Access Exam Prep, CCNP Switching Exam Cram, and CCNP Cisco LAN Switch Configuration Exam Cram Cisco Test Prep author for QuizWare, providing the most comprehensive Cisco exams on the market. Manny wrote in message news:[EMAIL PROTECTED] I ran into a situation today where we had a machine that was trying to FTP through the firewall. We allow FTP outbound. The problem that came up was that the user had no idea that an FTP client was setup on his machine. The FTP client (spyware) kept trying to connect to a server (ispynow.com) using the incorrect user name and password. For every attempt an xlate entry was created. It created about 7000 entries in a matter of minutes. The firewall was paralyzed. I had to console in and look at the xlate table. Even through the console I had a hard time viewing the table. Is there any way to prevent this from happening again?This is the second time this year an incident of this nature with the xlate table has occurred. How can I monitor the xlate table for strange behavior? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65173t=65095 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PIX Question [7:65095]
Manny, A couple of thoughts, not necessarily in order of applicability: 1) Change the timeout values for idle connections for conn (connection slot) from 1 hr to 5-10 min and change the xlate timeout from 3 hrs to 5-10 minutes. These are idle timeouts and will probably work for most environments unless you have a lot of low traffic, long timeout connections. (uses the 'timeout' command) 2) Enable aaa authorization for at least ftp and http. Force users to authenticate before using those services. 3) Log PIX messages to a syslog server, monitor it for xlate problems with something like logsurfer. 4) Install an IDS system and monitor for failed FTP logins. Obviously, these are not mutually exclusive. HTH, Kent On Tue, 2003-03-11 at 16:04, Manny wrote: I ran into a situation today where we had a machine that was trying to FTP through the firewall. We allow FTP outbound. The problem that came up was that the user had no idea that an FTP client was setup on his machine. The FTP client (spyware) kept trying to connect to a server (ispynow.com) using the incorrect user name and password. For every attempt an xlate entry was created. It created about 7000 entries in a matter of minutes. The firewall was paralyzed. I had to console in and look at the xlate table. Even through the console I had a hard time viewing the table. Is there any way to prevent this from happening again?This is the second time this year an incident of this nature with the xlate table has occurred. How can I monitor the xlate table for strange behavior? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65180t=65095 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
PIX Question [7:65095]
I ran into a situation today where we had a machine that was trying to FTP through the firewall. We allow FTP outbound. The problem that came up was that the user had no idea that an FTP client was setup on his machine. The FTP client (spyware) kept trying to connect to a server (ispynow.com) using the incorrect user name and password. For every attempt an xlate entry was created. It created about 7000 entries in a matter of minutes. The firewall was paralyzed. I had to console in and look at the xlate table. Even through the console I had a hard time viewing the table. Is there any way to prevent this from happening again?This is the second time this year an incident of this nature with the xlate table has occurred. How can I monitor the xlate table for strange behavior? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65095t=65095 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
Re: PIX Question [7:65095]
I'm not sure of the exact metric, but you should enable syslog and have this sent to a syslog server. With syslog server you can have the system parse the syslog and react to particular entries. Of course that depends on what you use to manage the syslog db. Manny wrote in message news:[EMAIL PROTECTED] I ran into a situation today where we had a machine that was trying to FTP through the firewall. We allow FTP outbound. The problem that came up was that the user had no idea that an FTP client was setup on his machine. The FTP client (spyware) kept trying to connect to a server (ispynow.com) using the incorrect user name and password. For every attempt an xlate entry was created. It created about 7000 entries in a matter of minutes. The firewall was paralyzed. I had to console in and look at the xlate table. Even through the console I had a hard time viewing the table. Is there any way to prevent this from happening again?This is the second time this year an incident of this nature with the xlate table has occurred. How can I monitor the xlate table for strange behavior? Message Posted at: http://www.groupstudy.com/form/read.php?f=7i=65122t=65095 -- FAQ, list archives, and subscription info: http://www.groupstudy.com/list/cisco.html Report misconduct and Nondisclosure violations to [EMAIL PROTECTED]
