Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

? need opinion and help on outbound traffic/Virus's

Status
Not open for further replies.

quell

IS-IT--Management
Joined
Nov 8, 2002
Messages
363
Location
US
Couple things here I would like your opinion on. We have a pix 515 ver6.1(1)

1. I want to retrict all outbound (traffic with the exception of web traffic and maybe audio streaming lol:) from our LAN. To keep us from infecting others with viruses. I have no idea on how to do this.

2. Our network keeps getting hit by viruses. I realize that the pix closes all the ports on the outside interface by default but I do not know how these virus's keep getting inside. Granted a lot of them travel via email but we had a few that were hit with the msblast virus. We do have nortons installed on all pc's and servers and it stops it but I want to stop the worms, virus's etc. at the border. I'm not for sure if I should build a proxy/firewall pc or try and lock everything down with a the pix. I guess one of my questions is if teh pix has all ports closed on the outside int then how dows virus's still get in if not through email?
Your opinion on both these matters would be greatly appreciated.
Thanx
 
For restricting outbound traffic, check out my FAQ.

faq35-2881

As far as worms coming in, they shouldn't if the firewall is properly set up. You might have a static and an access-list or conduit allowing NetBIOS or HTTP to a computer that gets infected, and then spreads it's love. :-)

Of course there is always the floppies, emails, hax0r websites, roaming sales department w/ laptops.
 
Thank you baddos for your help. Would a access list like below deny all traffic except www? I'm new to this and probably way off here but I do appreciate your advice.

We roughly have around 90 pc's on our network all connected to a few switches and then to the pix for our firewall. I was thinking of either doing this with the pix or connect the pix directly to a firewall/proxy and connect that to the switchs. This would track internet usage better and hopefully block viruses tht are not set via email.


I read someplace that the order is important so here is what I came up with so far.

access-list 101 permit tcp any any eq www
access-list 101 permit ip any any eq www
access-list 101 permit udp any any eq www
access-list 101 deny tcp any any
access-list 101 deny ip any any
access-list 101 deny udp any any
access-group 101 in interface inside

If I'm way off here just let me know. I'm just starting read up on this. I'm new to this and this was my first stop to fix the problem.
 
Here is my config please let me know what else I can do to lock this down. I know 1 is to update the ios but will I lose my settings if I do this?

PIX Version 6.1(1)
nameif ethernet0 outside security0
nameif ethernet1 inside security100
enable password ----
passwd ----
hostname usipix
domain-name usi.com
fixup protocol ftp 21
fixup protocol http 80
fixup protocol h323 1720
fixup protocol rsh 514
fixup protocol rtsp 554
fixup protocol smtp 25
fixup protocol sqlnet 1521
fixup protocol sip 5060
fixup protocol skinny 2000
names
access-list nonat permit ip 192.168.0.0 255.255.255.0 192.168.123.0 255.255.255.
0
pager lines 24
logging on
logging timestamp
logging console alerts
logging trap errors
logging host inside 192.168.0.9 6/1468
interface ethernet0 auto
interface ethernet1 auto
icmp deny any outside
mtu outside 1500
mtu inside 1500
ip address outside 66.128.---.--- 255.255.255.248
ip address inside 192.168.0.253 255.255.255.0
ip audit info action alarm
ip audit attack action alarm
ip local pool usipool 192.168.123.1-192.168.123.10
pdm history enable
arp timeout 14400
global (outside) 1 66.128.---.--- netmask 255.255.255.255
nat (inside) 0 access-list nonat
nat (inside) 1 192.168.0.0 255.255.255.0 0 0
route outside 0.0.0.0 0.0.0.0 66.128.---.--- 1
timeout xlate 3:00:00
timeout conn 1:00:00 half-closed 0:10:00 udp 0:02:00 rpc 0:10:00 h323 0:05:00 si
p 0:30:00 sip_media 0:02:00
timeout uauth 0:05:00 absolute
aaa-server TACACS+ protocol tacacs+
aaa-server RADIUS protocol radius
aaa-server partneruath protocol radius
aaa-server partneruath (inside) host 192.168.0.7 EDGVPN timeout 5
no snmp-server location
no snmp-server contact
snmp-server community public
no snmp-server enable traps
floodguard enable
sysopt connection permit-ipsec
no sysopt route dnat
crypto ipsec transform-set steve esp-des esp-md5-hmac
crypto dynamic-map dyna-brett 10 set transform-set steve
crypto map larkin 99 ipsec-isakmp dynamic dyna-brett
crypto map larkin client configuration address initiate
crypto map larkin client configuration address respond
crypto map larkin client authentication partneruath
crypto map larkin interface outside
isakmp enable outside
isakmp identity address
isakmp policy 10 authentication pre-share
isakmp policy 10 encryption des
isakmp policy 10 hash md5
isakmp policy 10 group 2
isakmp policy 10 lifetime 86400
vpngroup usi address-pool usipool
vpngroup usi dns-server 192.168.0.7
vpngroup usi wins-server 192.168.0.7
vpngroup usi default-domain USI.com
vpngroup usi idle-time 1800
vpngroup usi password ----
telnet timeout 5
ssh timeout 5
terminal width 80
Cryptochecksum:----
: end
[OK]
 
access-list 101 permit tcp any any eq www
access-group 101 in interface inside

Really... you only need the permit tcp any any eq www. You should probably add another line for SSL.

access-list 101 permit tcp any any eq 443

You don't need a line that explicitly denies traffic, because that will be done implicitly.
 
baddos is right, the rest of your access-list lines are both unnecessary and mostly wrong. The only line that would be of use is the first one (access-list 101 permit tcp any any eq www) and of course the application of the list to the interface (access-group 101 in interface inside)

with that and the SSL you are now only allowing web, but you are not allowing for DNS to work, or for streaming audio, or for email. That could be a problem. You would also want to have

access-list 101 permit tcp any any eq dns(domain)
access-list 101 permit tcp any any eq smtp
access-list 101 permit tcp any any eq pop3

plus FTP or anything else that might arise you will need to add those in too. You are possibly further ahead limiting the ports that you know are a problem. Such as

access-list 101 deny tcp any any range 135 139
access-list 101 deny udp any any range 135 139

then add in a
access-list 101 permit ip any any
to make sure that all other traffic goes out since as baddos pointed out there is an implicit deny any any at the end of every access-list whether you put it there or not.

Beyond this, there are plenty of ports to block, mainly above 1024 that are known backdoor ports, and keylogger ports and on and on and on. There are plety of site that will list out common ports and what they are used for. And the PIX can block ports by ranges, above certain ports, below certain port, or at certain ports. It is all a matter of how much you wish to close off the access.

Also please remember that all this is a band-aid for the problem. You really should use a sniffer, or an IDS package to see where those viruses are coming in from. Perhaps you are getting it not through your PIX at all, but through a VPN tunnel which is not filtered at all. Who knows, but that is what you really need to find out.

Very few of the PIX implementations I set up have outgoing ACLs and those that do have them on the VPNs too, and they are for paranoid IT managers who would rather not take any chances, who would rather stop alot of good stuff than to let one bad thing in.

Good luck,
Eddie Venus

"You're one of them fancy lads, ain't cha?" - Dave Letterman in Cabin Boy
 
Thank you both for your advice. By the way I am a paraniod IT :)

Eddie: what would you recommend for a sniffer or IDS?
 
HI.

> I guess one of my questions is if teh pix has all ports closed on the outside int then how dows virus's still get in if not through email?

As mentioned by other also - the system could be infected by VPN , open ports, or probably a laptop infected at home and then connected to internal network.

As a first aid for finding infected hosts, you can connect to the pix and issue the command:
show conn
repeat this every few seconds/minutes.
If you see a host initiating many outbound connections to different IP addresses on ports 80 or 135, you can now know where to go on.
You can also enable syslog messages (level 4) and block these ports (blocking tcp 80 will block also legitimic http traffic so only block this one for a short time just to collect more info, afterwards reopen it but still block other like 135).
Then you'll see in the syslog messages which hosts are hitting this access-list.

You can also use the PDM monitoring tab ("bit rate" on outside interface) to monitor bandwidth usage.
Infected hosts may utilize all outbound bandwidth, and when you block/shutdown these hosts you should expect outbound traffic to drop back to normal.

> I'm not for sure if I should build a proxy/firewall pc or try and lock everything down with a the pix
These are good ideas, I suggest both - implement a proxy server, and then allow only limitted outbound traffic (dns server, mail server, proxy server).
This is good because on the proxy server you can implement some kind of content filter to block EXE files for example.
Linux + Squid can be a low cost yet powerful and extendable solution.

However, the proxy is NOT the main issue here (it is a good idea for the near future to protect against other troubles).

As a starting outbound ACL you can start with something like:
access-list frominside permit udp any any eq domain
access-list frominside permit tcp any any eq smtp
access-list frominside permit tcp any any eq http
access-list frominside permit tcp any any eq https
access-list frominside permit tcp any any eq ftp
...
access-group frominside in interface inside

No need to block specific ports. Simply do not open them.

> You really should use a sniffer, or an IDS package
I agree. This is a good idea.
Some sniffing and IDS functionality can be done with the pix itself, for example:

* The pix has a limitted IDS built in, which can be enabled using PDM and/or "ip audit" commands from CLI.
More info here:
This is NOT a real IDS, but why not enable the feature if it is there...

* Instead or in addition to sniffer, you can collect a lot of info from pix syslog messages (in level 6). These can be collected and analysed with 3rd party software and/or custom self made scripts.

These (pix ids and syslog) are not replacement for good sniffer/ids, but I recommend using them wether you have something else or not.

Here is a nice stand-alone sniffer for Windows:
There are many other good utils, here you can find and try some free yet powerful tools:

Remember that if you implement a sniffer/ids box in a switching environment you need to enable port mirroring or to place a plain old HUB so that the box will see traffic going to the pix.
Here is one optional implementation:

LAN HOSTS
| | | | |
***SWITCH***
|
****HUB****
| |
PIX IDS/SNIFFER
|
ROUTER
|
ISP



Yizhar Hurwitz
 
I agree with yizhar completely. Mainly because most of what I know about PIXes I learned from reading what he said about PIXes.

That being said, I can say from experience that a good sniffer is Ethereal. At
it is good, easy to use, and best of all FREE and I like free, it makes me happy to know that good products can be free, like the info here on Tek-Tips.

And with that refer to what yizhar wrote, since most of what I was going to say is already there.

Eddie Venus
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top