-----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, March 08, 2002 12:20 AM To: [EMAIL PROTECTED] Subject: Firewalls digest, Vol 1 #581 - 10 msgs Send Firewalls mailing list submissions to [EMAIL PROTECTED] To subscribe or unsubscribe via the World Wide Web, visit http://lists.gnac.net/mailman/listinfo/firewalls or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than "Re: Contents of Firewalls digest..." Today's Topics: 1. RE: User AAA into a Secure Data Center (Ben Nagy) 2. RE: advice (Ben Nagy) 3. RE: User AAA into a Secure Data Center (Eric E. Bomarsi) 4. Re: Gauntlet NAT issues (Z.) 5. TACACS+ installation (Ashraf Hamed) 6. RE: Why netscreen instead of say sonicwall (Paul Evan) 7. Re: pix pdm question (dario_calia) 8. Re: pix pdm question (dario_calia) 9. connection refused with ipmasqadm portfw (Samy Abbes) 10. RE: How to hide IP's in Trace (Claussen, Ken) --__--__-- Message: 1 From: "Ben Nagy" <[EMAIL PROTECTED]> To: "'Eric E. Bomarsi'" <[EMAIL PROTECTED]>, "'Firewall-List'" <[EMAIL PROTECTED]> Subject: RE: User AAA into a Secure Data Center Date: Fri, 8 Mar 2002 11:05:37 +1030 I think it's clear that there's an evolution in the direction of ubiquitous IPSec - even leaving aside the fact that it's more or less built in to IPv6. The hardware is there to support it (NICs with crypto offload processors, single-task VPN gateways), the user-based authentication infrastructure has now come up to speed - the only thing that might not be out-of-the-box is a good accounting regime, but it should be easy to piece together out of RADIUS + bits and pieces. As we all know, Microsoft is now favouring IPSec throughout the LAN, using Kerberos for station-to-station auth and their own Beautiful Brand of user auth. Say what you will about their implementation of the two protocols, the paradigm is good and they have the market push to drive it into at least the frontal brains of all the sysadmins out there. As a user-based-auth technical aside, MS use L2TP over IPSec, which gets around the user auth problem at a higher level than the machine-level auth. Protocols like Cisco's Xauth (which is likely to remain in IETF draft form more or less forever) build user-based auth into the actual IKE part of IPSec itself, which is nice. Reading the initial working draft for IKEv2, one gets the impression that some user-auth stuff is likely to be folded into son-of-ike by the time it gets done. Other vendors may also have proprietary ways of folding in user based auth, but do be aware that it's not really part of "pure" IPSec in any way. Also, remember that you don't need to run the encrypted part of IPSec unless confidentiality is one of your concerns - you can quite happily run AH only and get strong authentication and session integrity. That may be quite enough for some people, and still leaves packets open for sniffing on the internal LAN, which is useful in many cases (internal IDS systems, HTTP accounting software, legit administrative hunter-seeker activity etc). In short, I think that IPSec is the best way to handle your problem, and that it will become the default way as time goes by. I've been advocating internal IPSec for years. Cheers, -- Ben Nagy Network Security Specialist Mb: +61 414 411 520 PGP Key ID: 0x1A86E304 > -----Original Message----- [...] > > > I am interesting in hearing from people who have implemented user > > > based AAA for internal access to > > a > > > secure data center or similar deployment.[...] --__--__-- Message: 2 From: "Ben Nagy" <[EMAIL PROTECTED]> To: "'Gary Ferrer'" <[EMAIL PROTECTED]>, "'Firewall list'" <[EMAIL PROTECTED]> Subject: RE: advice Date: Fri, 8 Mar 2002 11:32:54 +1030 Caveat: I am prepared to bet that this will suck and be slow. 1. Set up station-to-station VPN between the router and the firewall. IPSec or PPTP will be your best bet here. Test with ping between your remote clients and your SMB server. 1a. If that's all too hard or doesn't work, just set up PPTP on your SMB server, configure all the remote clients with a VPN dialup adapter, allow PPTP (TCP 1723, IP Prot 47 (GRE))in through your firewall and do the authentication and stuff on the internal server. Some might point out that this way isn't as secure - they're absolutely right, but if you use strong passwords it's not _all_ that abhorrent. Well, OK, it sort of is. But it will work. I'd do it, if I were desperate, and I'm not a _complete_ idiot. 2. Map drives on the clients, and make sure that the remote clients are in the same workgroup/domain as the server in Canada, and add their usernames to the Canadian domain, with permissions to access the shares. Done. 2a. You could also do this the "daring" way and tell all the clients to look in Canada for their WINS server, and they can then access all the shares and Canadian machines just by browsing the network. Better for maintainability, but entailing much peril, slowness and flakiness. 2b. If your users aren't computer morons, you can get them to access the shares via //ip.address.goes.here/sharename, and then supply user credentials - in which case you don't need to worry about making sure domains etc match. The downside to this approach is that most users are, in fact, computer morons. 3. Whether or not it all works, never tell anyone I gave you this advice. Cheers! -- Ben Nagy Network Security Specialist Mb: +61 414 411 520 PGP Key ID: 0x1A86E304 -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Gary Ferrer Sent: Friday, March 08, 2002 3:39 AM To: Firewall list Subject: advice Can someone give me some advice as to where to start with this project. I have an SMC Barricade Broadband router in Europe (SMC7004ABR) which supports VPN tunneling via L2TP, PPTP and IPSec pass through. There are Win XP and 98 clients behind this router only. On the other end (here in Canada), I have a Sunscreen lite 3.1 firewall on a Solaris 8 box. Sunscreen has a VPN feature. I want to be able to give the Win clients access to SMB shares behind the Solaris firewall via a VPN. How do I set this up? What software do I need to do this (if any)? Thanks. PS: If anybody can point me to a 'HOWTO' it would be appreciated. Gary Ferrer [EMAIL PROTECTED] --__--__-- Message: 3 Date: Thu, 7 Mar 2002 17:32:58 -0800 (PST) From: "Eric E. Bomarsi" <[EMAIL PROTECTED]> Subject: RE: User AAA into a Secure Data Center To: Ben Nagy <[EMAIL PROTECTED]>, 'Firewall-List' <[EMAIL PROTECTED]> Thanks Ben: Being an IPSec fan, I like this approach. When I last looked at this, it was slow and the deployment was difficult because it typically required client SW and deployment of client certs. The 100Mbps crypto NICs from Intel and 3Com are cheap, the OS's have native IPSec in the stack and it's easy to config, and the IPSec RA group is proposing solutions for IP client config and an alternative to client certs which would use legacy auth. > I've been > advocating internal IPSec for years. Has anyone deployed it? Any issues? Successes? > As we all know, Microsoft is now favouring IPSec > throughout the LAN, Do you have any pointers to MS info describing this? Thanks, Eric Bomarsi --- Ben Nagy <[EMAIL PROTECTED]> wrote: > I think it's clear that there's an evolution in the > direction of > ubiquitous IPSec - even leaving aside the fact that > it's more or less > built in to IPv6. The hardware is there to support > it (NICs with crypto > offload processors, single-task VPN gateways), the > user-based > authentication infrastructure has now come up to > speed - the only thing > that might not be out-of-the-box is a good > accounting regime, but it > should be easy to piece together out of RADIUS + > bits and pieces. > > As we all know, Microsoft is now favouring IPSec > throughout the LAN, > using Kerberos for station-to-station auth and their > own Beautiful Brand > of user auth. Say what you will about their > implementation of the two > protocols, the paradigm is good and they have the > market push to drive > it into at least the frontal brains of all the > sysadmins out there. > > As a user-based-auth technical aside, MS use L2TP > over IPSec, which gets > around the user auth problem at a higher level than > the machine-level > auth. Protocols like Cisco's Xauth (which is likely > to remain in IETF > draft form more or less forever) build user-based > auth into the actual > IKE part of IPSec itself, which is nice. Reading the > initial working > draft for IKEv2, one gets the impression that some > user-auth stuff is > likely to be folded into son-of-ike by the time it > gets done. Other > vendors may also have proprietary ways of folding in > user based auth, > but do be aware that it's not really part of "pure" > IPSec in any way. > > Also, remember that you don't need to run the > encrypted part of IPSec > unless confidentiality is one of your concerns - you > can quite happily > run AH only and get strong authentication and > session integrity. That > may be quite enough for some people, and still > leaves packets open for > sniffing on the internal LAN, which is useful in > many cases (internal > IDS systems, HTTP accounting software, legit > administrative > hunter-seeker activity etc). > > In short, I think that IPSec is the best way to > handle your problem, and > that it will become the default way as time goes by. > I've been > advocating internal IPSec for years. > > Cheers, > > -- > Ben Nagy > Network Security Specialist > Mb: +61 414 411 520 PGP Key ID: 0x1A86E304 > > > > -----Original Message----- > [...] > > > > I am interesting in hearing from people who > have implemented user > > > > based AAA for internal access to > > > a > > > > secure data center or similar deployment.[...] > __________________________________________________ Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! http://mail.yahoo.com/ --__--__-- Message: 4 Date: Tue, 05 Mar 2002 10:35:41 -0600 From: "Z." <[EMAIL PROTECTED]> Subject: Re: Gauntlet NAT issues To: Andrew Thomas <[EMAIL PROTECTED]>, [EMAIL PROTECTED] a couple of things: if the internal machine that you're trying to set up a static NAT rule for is also included in a subnet that currently has a dynamic rule set up for it, be sure that you bump the static rule above the dynamic NAT rules. also, you need to be sure that in the static NAT rule you are specifying a 32 bit netmask for the internal client address as well as for the global address. if that still doesn't do it post a snip of the message log from when the communication fails. also, of course, be sure that whatever type of traffic you're testing with is permitted in your untrusted policy. -Z ----- Original Message ----- From: "Andrew Thomas" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Tuesday, March 05, 2002 10:42 AM Subject: Gauntlet NAT issues > Hi, > > We are running Gauntlet 5.5 on Win NT 4.0 SP5+hotfixes coming out of > our ears. I am at present having issues setting up static NAT. > > Dynamic NAT runs 100%. The static rule we are using is local IP: > 192.168.x.151, global IP: x.x.x.105, with the global interface set to > external (untrusted). > > The .105 IP address is bound to correct card. I can ping the IP from a > remote (Internet side) machine, but when I try to connect to e.g. mail > service via telnet, it times out (ie no connection refused). > > If anyone can give any pointers on how to do further trouble shooting > on this, please let me know. > > Take care, > Andrew Thomas > -- > Andrew Thomas > _______________________________________________________________ > http://www.webmail.co.za the South-African free email service > _______________________________________________ > Firewalls mailing list > [EMAIL PROTECTED] > http://lists.gnac.net/mailman/listinfo/firewalls --__--__-- Message: 5 From: Ashraf Hamed <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: TACACS+ installation Date: Tue, 5 Mar 2002 16:42:44 +0200 This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C1C464.C63350B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Dear all; i would like to help me to install the TACACS+ in Linux redhat7.1, please send me the step for the installation thank you in advance for careful consideration regrads Ashraf Hamed ------=_NextPart_000_0005_01C1C464.C63350B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META content=3D"MSHTML 6.00.2600.0" name=3DGENERATOR> <STYLE></STYLE> </HEAD> <BODY bgColor=3D#ffffff> <DIV><FONT face=3DArial size=3D2>Dear all;</FONT></DIV> <DIV><FONT face=3DArial size=3D2>i would like to help me to install the = TACACS+ in=20 Linux redhat7.1, please send me the step for the = installation</FONT></DIV> <DIV><FONT face=3DArial size=3D2>thank you in advance for careful=20 consideration</FONT></DIV> <DIV><FONT face=3DArial size=3D2>regrads</FONT></DIV> <DIV><FONT face=3DArial size=3D2>Ashraf = Hamed</FONT></DIV></BODY></HTML> ------=_NextPart_000_0005_01C1C464.C63350B0-- --__--__-- Message: 6 Date: Tue, 5 Mar 2002 13:47:24 -0800 (PST) From: Paul Evan <[EMAIL PROTECTED]> Subject: RE: Why netscreen instead of say sonicwall To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] --0-1544979615-1015364844=:52020 Content-Type: text/plain; charset=us-ascii I think we are getting off track here - the main issue is not always whether you can use command line or GUI interface. It is what will secure your network and offer you the options your network requires. This could be throughput speed, VPN capability, content filtering, encryption, etc. I think that certain firewalls are appropriate for certain networks. Not one firewall is going to fit every environment. It is important to write the security requirements and budget (unfortunately this does come into play) for your company and then go from there.... PIX - good solid box but difficult for just anyone to configure - imagine that. Once it is installed correctly though I usually don't hear to many complaints - there are PIX 10000 Series still working out there without problems - too bad they are EOL. Usually best with companies that have their own IT staff or a Cisco engineer that is easy to reach. SonicWALL - the new product line is much better than the old one - increased speeds and concurrent connections. Some of the old SonicWALL's had issues. Not finding that as much but tech support leaves something to be desired. Better for small to medium corporations with not as complex of a network. Netscreen - Have heard good and bad things about this but experience is limited to others information. Checkpoint is a good firewall with those really large corps that have some money to spend since there is a lot more to set up then with a hardware based firewall. Also, since it is software based, the problem can lie with the O.S. or with the firewall. It is robust firewall though, with a lot of additional features that are nice. --------------------------------- Do You Yahoo!? Try FREE Yahoo! Mail - the world's greatest free email! --0-1544979615-1015364844=:52020 Content-Type: text/html; charset=us-ascii <FONT size=2> <P>I think we are getting off track here - the main issue is not always whether you can use command line or GUI interface. It is what will secure your network and offer you the options your network requires. This could be throughput speed, VPN capability, content filtering, encryption, etc. I think that certain firewalls are appropriate for certain networks. Not one firewall is going to fit every environment. It is important to write the security requirements and budget (unfortunately this does come into play) for your company and then go from there....</P> <P>PIX - good solid box but difficult for just anyone to configure - imagine that. Once it is installed correctly though I usually don't hear to many complaints - there are PIX 10000 Series still working out there without problems - too bad they are EOL. Usually best with companies that have their own IT staff or a Cisco engineer that is easy to reach.</P> <P>SonicWALL - the new product line is much better than the old one - increased speeds and concurrent connections. Some of the old SonicWALL's had issues. Not finding that as much but tech support leaves something to be desired. Better for small to medium corporations with not as complex of a network.</P> <P>Netscreen - Have heard good and bad things about this but experience is limited to others information.</P> <P>Checkpoint is a good firewall with those really large corps that have some money to spend since there is a lot more to set up then with a hardware based firewall. Also, since it is software based, the problem can lie with the O.S. or with the firewall. It is robust firewall though, with a lot of additional features that are nice.</P></FONT><p><br><hr size=1><b>Do You Yahoo!?</b><br> Try FREE <a href="$rd_url/tag/http://mail.yahoo.com/";>Yahoo! Mail</a> - the world's greatest free email! --0-1544979615-1015364844=:52020-- --__--__-- Message: 7 Date: Tue, 05 Mar 2002 23:04:29 -0000 From: "dario_calia" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: pix pdm question Hello, Forgot to reply to the group... Yu need to enable the PIX firewall HTTP sever and identify the clients that can access the PIX through the outside interface. http 16.152.1.11 255.255.255.255 outside http server anable Use your host's IP address instead of the ip address in the example above. thanks, Dario --- In [EMAIL PROTECTED], "pd" <[EMAIL PROTECTED]> wrote: > hi > > does anyboy know how to connecto to pix PDM by outside interface ? > > > thx > --- > piXi_MX3, mx3, 1600, 16V, 1995 > http://kapsel.topnet.pl > > > > > -- > > Okresl Swoje potrzeby - my znajdziemy oferte za Ciebie! > [ http://oferty.onet.pl ] --__--__-- Message: 8 Date: Wed, 06 Mar 2002 10:03:30 -0000 From: "dario_calia" <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: Re: pix pdm question Hello, Third try to send --- Hello, You will need to enable the http server and provide access to your client as follows. http 16.152.1.11 255.255.255.255 outside http server enable Replace the IP address above with your host's IP address that needs PDM access from the outside interface. Thanks, Dario --- In [EMAIL PROTECTED], "pd" <[EMAIL PROTECTED]> wrote: > hi > > does anyboy know how to connecto to pix PDM by outside interface ? > > > thx > --- > piXi_MX3, mx3, 1600, 16V, 1995 > http://kapsel.topnet.pl > > > > > -- > > Okresl Swoje potrzeby - my znajdziemy oferte za Ciebie! > [ http://oferty.onet.pl ] --__--__-- Message: 9 Date: Wed, 06 Mar 2002 15:19:36 +0000 From: Samy Abbes <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: connection refused with ipmasqadm portfw Hi everybody, I have an internal host (192.168.0.7) running Apache on port 80. I want to forward connections from outside to the host my_firewall, tcp port 80, to this internal Apache server. The firewall runs a 2.2.20 linux kernel, and I use the following commands which are accepted by my_firewall without any comment, and well listed with the command ipmasqadm portfw -l : ipmasqadm portfw -f ipmasqadm portfw -a -P tcp -L $extip 80 -R 192.168.0.7 80 (here $extip is the external IP adress of my_firewall). Now, when I try to connect to my_firewall through a browser by typing his IP adress $extip, it gives me the following message : "the connection was refused when attempting to contact $extip". I expected to be connected to 192.168.0.7 of course. I also tryed the ipmasqadm mfw tool, combined with an ipchains command according to the man ipmasqadm, with exactly the same result. And the echo "1">/proc/sys/net/ipv4/ip_forward does not change anything. I absolutly have no idea of the reason of this connection refused. Can you help me ? Thanks a lot, Samy --__--__-- Message: 10 Subject: RE: How to hide IP's in Trace Date: Wed, 6 Mar 2002 20:17:11 -0500 From: "Claussen, Ken" <[EMAIL PROTECTED]> To: "Laura A. Robinson" <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Correct me if I am wrong, but it sounds like this person is trying to block the people on the internal network from mapping it as they travel to Internet targets. To do this Cisco ACLs on the routers denying Time Exceeded in Transit (ICMP Type 11) packets should do the trick. The statements would be In the form, access-list access-list-number [dynamic dynamic-name [timeout minutes]] deny | permit} icmp source source-wildcard destination destination-wildcard [icmp-type [icmp-code] | icmp-message] [precedence precedence] [tos tos] [log]=20 IE,=20 access-list 106 deny icmp any 192.168.1.0 0.0.0.255 11 access-list 106 permit ip any any Apply this outbound on the internal interface with the command IE, Config t Interface Ethernet 1 access-group 106 out exit This assumes 192.168.1.0 0.0.0.255 is the internal network where the trace routes originate and that E1 on the cisco router is the interface on that subnet. This should block the reposnses to the trace routes so the internal users will not be able to map past the local router interface. http://www.cisco.com/univercd/cc/td/doc/product/software/ios113ed/cs/csp rtn1/csip.htm#xtocid273892 (Watch Wrap) http://www.erg.abdn.ac.uk/users/gorry/course/inet-pages/icmp-code.html=20 Ken Claussen MCSE CCNA CCA "In Theory it should work as you describe, but the difference between theory and reality is the truth! For this we all strive" -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Laura A. Robinson Sent: Wednesday, March 06, 2002 3:34 PM To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: How to hide IP's in Trace Well put! Laura ----- Original Message -----=20 From: <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Wednesday, March 06, 2002 3:21 PM Subject: Re: How to hide IP's in Trace > On 7 Mar 2002, at 0:25, Amarnath Gutta wrote: >=20 > > Hi All, > >=20 > > I have Private IP's address in my network which I want to conceal > > in traceroutes. Say a customer traces to any IP on internet he is > > able to map my private network also which I want to prevent. So how > > can I hide the private ip's in the traceroutes. I use cisco > > routers.=20 > >=20 > > Any suggestions are welcome. > >=20 > > Regards > >=20 > > Amar >=20 > It sounds like you don't want your firewall to allow ICMP replies.=20 >=20 > But even if your firewall allows ICMP replies from internal=20 > machines, then any servers for which you have static NAT mappings=20 > will respond -- and the responses, being NATted, will show the IPs=20 > that the servers map to and not the internal IP addresses of the=20 > actual machines. > Any internal clients relying on PAT will never see the ICMP=20 > requests, which will be addressed to the firewall. > If you have a NAT pool, then machines currently mapped into the=20 > pool may respond on their current mapped addresses -- but since those=20 > addresses are subject to change, this mapping is of limited use to an=20 > attacker. >=20 > So although you may be happier blocking ICMP replies -- if your=20 > firewall lets you choose that option -- I don't think the risk is as=20 > bad as you fear. If you have a firewall that doesn't let you block=20 > ICMP replies, I would not lose sleep over it. >=20 > David Gillett >=20 --__--__-- _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls End of Firewalls Digest ---------------------------------------------------------------------------- ----- Please make sure you are familiar with the NSTAR Electronic Communications System Policy. ********************************************************************** This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. ********************************************************************** _______________________________________________ Firewalls mailing list [EMAIL PROTECTED] http://lists.gnac.net/mailman/listinfo/firewalls
