Penetration analysis?

Specifics background:

Windows 2000 server sp 4, McAfee Groupshield, McAfee Netshield, Exchange 2000 sp 3 - all
patched, I check it constantly. Cisco firewall, only port 25 mapped from outside. Mail server is not an open relay, some user gained access to a mail box and spammed, all mailbox passords have been changed and comply with Active Directory domain security policy that forces hard to guess passwords (letter, number, 8 characters, symbol)

CISCO Configs that matter in this case: I hand typed the running config so there may be typos, not syntaxt errors:::::

nameif ethernet0 outside security0
nameif ethernet1 inside security100
fixup protocol ftp21
fixup protocol http80
no fixup protocol smtp25
icmp deny any outside
conduit permit icmp any any echo-reply
(wonder if the conduit command over rides the Icmp deny command, will have to look)
conduit permit tcp host <mail public IP> eq smtp any
no snmp-server (apreviated snmp is OFF)


*thoughts right before posting - my intent is to block FTP at the firewall.
--------

Hi all, you may have read my mail server post issued a few days ago were someone got a relay on me. I have been working on it since learning Exchange for the better and
figuring out what happened. The mail sever continued to relay small amounts of messages I
considered were queued but that should have cleared by now. Last night I slipped ethereal
on the segment and saw FTP entries over and over, I wasn't even looking for them I was
looking for SMTP stuff.

I didn't set up this box but it looks like FTP was enabled on the IIS portion for (sigh) Anonymous login. IIS lockdown was just run, about 8 hours too late. I didn't build the box but it's mine so it's my ass for trusting someone else and not following up. I have antivirus set to check NAI constanlty. You see that going on then all of a sudden, FTP connections and transfers from outside connections especially one from a 63 address. I don't know IIS at all, and if I had made an effort to understand the interaction of IIS and exchange things would be different right now.

I thought I was just vulnerable to SMTP attacks and my intention on the firewall was set to block everything except port 25. I'll be scanning the firewall tonight from home to make sure but I only have 2 rules, deny all but port 25 and then only SMTP protocol on outside and pass any connection originated on the inside. I have web filters to attempt to block harmful connections initiated by a browser on the inside.

I haven't got to the firewall log yet but here is the Ethereal outputs. I am going to need to understand exactly how far he got and what he looked at. I am assuming that the IIS part
was set at whatever defaults are on service pack 3 and whatever MS put out for security
patches. I just ran IIS lockdown tool with the Exchange 2000 wizard. How effective is that?

Attached is a Ethereal output with about 20 of 30 packets that are not expanded, where 205.227.137.53 finished up and 63.218.7.141 started FTP sessions from hell and it goes on for a while. This isn't an active web site but I don't know IIS and don't know what is possible with basic settings:::::::

Here is one of the transfer packets:::::::

Frame 417859 (1434 bytes on wire, 1434 bytes captured)
Arrival Time: May 4, 2004 08:14:38.537429000
Time delta from previous packet: 0.019852000 seconds
Time since reference or first frame: 50017.420798000 seconds
Frame Number: 417859
Packet Length: 1434 bytes
Capture Length: 1434 bytes
Ethernet II, Src: 00:07:0e:99:e3:65, Dst: 00:30:48:54:38:b7
Destination: 00:30:48:54:38:b7 (150.0.3.45)
Source: 00:07:0e:99:e3:65 (150.0.0.31)
Type: IP (0x0800)
Internet Protocol, Src Addr: 63.218.7.141 (63.218.7.141), Dst Addr: 555.5.5.55 (555.5.5.55)
Version: 4
Header length: 20 bytes
Differentiated Services Field: 0x00 (DSCP 0x00: Default; ECN: 0x00)
0000 00.. = Differentiated Services Codepoint: Default (0x00)
.... ..0. = ECN-Capable Transport (ECT): 0
.... ...0 = ECN-CE: 0
Total Length: 1420
Identification: 0xedc5 (60869)
Flags: 0x04
0... = Reserved bit: Not set
.1.. = Don't fragment: Set
..0. = More fragments: Not set
Fragment offset: 0
Time to live: 53
Protocol: TCP (0x06)
Header checksum: 0x7212 (correct)
Source: 63.218.7.141 (63.218.7.141)
Destination: 555.5.5.55 (555.5.5.55)
Transmission Control Protocol, Src Port: 4411 (4411), Dst Port: 33585 (33585), Seq: 3082921,

Ack: 1, Len: 1380
Source port: 4411 (4411)
Destination port: 33585 (33585)
Sequence number: 3082921
Next sequence number: 3084301
Acknowledgement number: 1
Header length: 20 bytes
Flags: 0x0010 (ACK)
Window size: 5840
Checksum: 0x0707 (correct)
FTP Data
FTP Data:

\332\a\210\375\367\234a\321\323=\361\343\247U\204Z\340\177b\226\237\023\242\307w\323\217\275

\206\375\277t\306\317\v#\fK\025Q\263\360\377\027\334c@\322}L!\t\317\377\304\272\300\253\221A

^\311wd\276\260\377\237~,\364\026\372\037\232

did ur pix firewall was patched to lastest version? there is an attack against pix firewall
that is protecting FTP as u described. See the link bellow
http://www.cisco.com/warp/public/707/pixftp-pub.shtml
this flaw can open arbitrary ports at pix firewall

Thanks, my CISCO is patched to versions beyond the vulnerability. It does give me some info on variations to the fixup command I may try. Cheers.

if you handle your own dns you may find networks refusing your mail if they cannot do a reverse lookup.

Quote:

---

Transmission Control Protocol, Src Port: 4411 (4411), Dst Port: 33585 (33585), Seq: 3082921,

---

This line bothers me a lot...... Never mind the source..... The destination implies that your box is unfirewalled. Any normal firewall would block this inbound in the first place. If it is a shovelled connection, (from the inside out which it isn't because it's an ACK packet), then the port 4441 should have been blocked too. The implication is that high ports, (1025-65535), go unfiltered for ingress and egress.....

I would lock the firewall to only allow port 25 to the mail server from the public network. I would also apply port filtering to only allow connections to port 25 under the TCP/IP properties.

Yes sir, that is my intention. Apparently it failed. I am under the assumption that all but port 25 is blocked at the Cisco Pix. By seeting the outside interface to block everything first and then only permitting port 25 through a conduit. The box itself is not firewalled. Although that is possible with IPSec policies. I think I'll work on that.

Reverse DNS has never cause a problem but with my spam last week AOL has blocked me with a message stating the my lack of reverse DNS is an issue.

TS that packet shows a ftp session (data) and is PASV. If it is a PASV from either directions, both ports will be unprivileged. FTP Servers that accept PASV connection tends to use high number ports (a range of) to protect them. U r right. packets are passing thru, since that is an ACK to a previous packed "escaped".

im not sure about conduit statements (besides that is clear what is the syntax) because is kinda a old syntax. Nowadays we use access-list. Its that why ive asked about patches. I thought it was a unpatched old version.

I had access lists at one time but recently at the recomendation of CISCO installed conduits to tunnel the private mail address with the public or vis versa. The only way that could work on a virtual ip address is via conduit. Other methods require a hard IP assigned to a mac - that is at my level of understanding. I have since turned off the FTP server on this box. I think the IIS lock down tool did it and i checked it via control panel. I am now looking for any additional servers outside of windows that may be communicating.

This device is also connected to a domain internal to the organization. I am also considering a mail relay or gateway beyond this one to forward mail in from now on.

take a look at this page:
http://www.cisco.com/en/US/products/...08017278b.html
and see option strict. Doesn appear to be this, since u had blocked HTTP too, correct?
and u put no fixup for smtp due to Exchange misbehavior, right?

unfortunately my browser didn't like that page. HTTP is blocked from outside. Limited clients can access it from inside. SMTP no fixup was recomended because of exchange behavior, yes. Thanks you for the input.

unfortunately my browser didn't like that page. HTTP is blocked from outside. Limited clients can access it from inside. SMTP no fixup was recomended because of exchange behavior, yes. Thanks you for the input.

Not an expert in this area but the link does work if you remove the spaces (represented by %20) and the <br%20/>

I tried to post the fixed link here but AO destroyed it by inserting the spaces and html formating

Cheers,

-D

Not an expert in this area but the link does work if you remove the spaces (represented by %20) and the <br%20/>

I tried to post the fixed link here but AO destroyed it by inserting the spaces and html formating

Cheers,

-D

Yep , that does work. Cheers. Great article.

Yep , that does work. Cheers. Great article.

Why do you use fixup ftp and http if these ports aren't open?
Setup your ruleset like this:

Allow rule (conduit permit tcp x.x.x.x eq smtp host y.y.y.y)
deny everything else (conduit deny ip any any)

Why do you use fixup ftp and http if these ports aren't open?
Setup your ruleset like this:

Allow rule (conduit permit tcp x.x.x.x eq smtp host y.y.y.y)
deny everything else (conduit deny ip any any)

That's a damn good question, I guess it's there as a safety margine but it's not used so I'll take them out. I had considered the conduit command to deny everything. The initial startup command for the pix interface has it set to deny everything but an extra step would be beneficial to ensure unwanted packets are definitely denied. But I am thinking, if I go messing with the conduits I might as well conform to modern convention and switch to ACL controls. Of course just adding that deny line wouldn't hurt, so I did.

To update everyone, I had a very generous AO member (thanks T.S.) scan me last night and with the running config posted here there are no open ports reported back. Although I did turn off the FTP server that was running in IIS on the mail server.

//edit I think I spoke too soon on the fixup commands. They are enabled by default and if there are no vulnerabilities accociated with their use, would it make sense that if a packet did get through, you would want it to run through the fixup security engine for inspection? They are enabled by default and I know some recomend their removal if not used but I question the benefit of fixup exploits versus and active insepection of packets comming in that are orignated from inside, such as web browsing. Am i oversimplifying? The command is global affecting both inside and outside interfaces but I AM NOT a Cisco expert.

That's a damn good question, I guess it's there as a safety margine but it's not used so I'll take them out. I had considered the conduit command to deny everything. The initial startup command for the pix interface has it set to deny everything but an extra step would be beneficial to ensure unwanted packets are definitely denied. But I am thinking, if I go messing with the conduits I might as well conform to modern convention and switch to ACL controls. Of course just adding that deny line wouldn't hurt, so I did.

To update everyone, I had a very generous AO member (thanks T.S.) scan me last night and with the running config posted here there are no open ports reported back. Although I did turn off the FTP server that was running in IIS on the mail server.

//edit I think I spoke too soon on the fixup commands. They are enabled by default and if there are no vulnerabilities accociated with their use, would it make sense that if a packet did get through, you would want it to run through the fixup security engine for inspection? They are enabled by default and I know some recomend their removal if not used but I question the benefit of fixup exploits versus and active insepection of packets comming in that are orignated from inside, such as web browsing. Am i oversimplifying? The command is global affecting both inside and outside interfaces but I AM NOT a Cisco expert.

just finish my last observation, if http is open from inside to outside, you should take a look at "strict" parameters. That would avoid "embeded" ftp on http strings. Maybe this the origin from those ftp connections

just finish my last observation, if http is open from inside to outside, you should take a look at "strict" parameters. That would avoid "embeded" ftp on http strings. Maybe this the origin from those ftp connections