Prevent SPAM from Leaving the network. (ISP)

[Ezequiel Pineda]

Hi,

I am working for an ISP, and we are having a few issues, im not sure how to fix.

My Scenario:

We are an ISP with 4 uplink providers and BGP sessions to 3 of them. We get full tables from 2 of them and partial tables from 1 of them.

Our business is the rental of servers, and we have about 500 servers at the present moment.

Every single server is on its own vlan with something like a /27.

When i get a customer asking for more than a /27, or when they ask the many different c-class subnets, i KNOW they way to use the server as a mail server.

I have created an ACL that looks like the following:

++++++++++++++++++++++++++++++++++++++++++++++++++++++

EDGE01.PRIVATELAYER.CH#show access-lists SPAM

Extended IP access list SPAM

    9 permit icmp any any (787857 matches)

    10 deny tcp any any eq pop3 (8106 matches)

    11 deny tcp any any eq pop2 (38 matches)

    12 deny tcp any any eq 27 (65 matches)

    13 deny udp any any eq 27 (2369 matches)

    14 deny tcp any any eq 58 (243 matches)

    15 deny udp any any eq 58 (2365 matches)

    16 deny tcp any any eq 61 (13 matches)

    17 deny udp any any eq 61 (2352 matches)

    18 deny tcp any any eq 24 (7 matches)

    19 deny udp any any eq 24 (2306 matches)

    20 deny tcp any any eq 143 (1266 matches)

    21 deny tcp any any eq 174 (3 matches)

    22 deny udp any any eq 174 (2347 matches)

    23 deny tcp any any eq 209 (468 matches)

    24 deny udp any any eq 209 (2326 matches)

    25 deny tcp any any eq 220 (3 matches)

    26 deny udp any any eq 220 (2328 matches)

    27 deny tcp any any eq 3206 (42285 matches)

    28 deny udp any any eq 3206 (2463 matches)

    29 deny tcp any any eq 3332 (42816 matches)

    30 deny tcp any any eq smtp (238570513 matches)

    31 deny udp any any eq 3332 (2354 matches)

    32 deny tcp any any eq 1723 (43657 matches)

    33 deny udp any any eq 1723 (2345 matches)

    40 deny tcp any any eq 585 (18 matches)

    50 deny tcp any any eq 993 (820 matches)

    60 deny tcp any any eq 995 (1233 matches)

    70 deny tcp any any eq 8080 (2025630 matches)

    100 permit ip any any (7969222 matches)

EDGE01.PRIVATELAYER.CH#

++++++++++++++++++++++++++++++++++++++++++++++++++++++

To my knowledge, this ACL should be catching ALL email ports, and dropping those packets.

I then get an email from Spamhaus, telling me that this server is sending email (SPAM)

When i asked them, they said that the customer might be using GRE tunnels to the server or asymmetric routing.

Im not familiar with asymmetric routing, but after doing some research, i think that GRE tunnels are normally configured ion port 1723, which is blocked as well.

Can anyone point me to the best way to prevent email from leaving an Interface Vlan (SVI)

I am working on a 65095 Series Switch.

If i should add something to the EDGE ACL, or something else, please advise.

Best Regards,

Ezequiel Pineda

[Favaloro.]

Is this situation caused by only one server?

If you know what is the server that is doing all this, you can create a span session and take a look at the connections it is establishing externally.

A temporary action i would take, would be to create an Access-list on that server's vlan allowing only what needs to go out, denying the rest of the traffic.

[Ezequiel Pineda]

Hi,

We have had this issue with very few people.

It looks like they are part of the Rosko Spam operation, which is a big deal, and being spammers with a LOT of spamming experience, they somehow have found a way to avoid ACL's.

At the moment yes, this is the only server that was causing the issue, but i have killed the account already, and shut the vlan.

I did however, create another ACL with the following statement, to try seeing exactly what was going on but couldnt see much to be honest

# 1 permit tcp any any log-input

# 2 permit udp any any log-input

I tried this with the log and log-input options, but i dont see Session information, Only TCP-IP source and destination traffic.

Can you elaborate more on that span session you mentioned?

Thanks again,

Ezequiel Pineda

[Favaloro.]

Where did you place the Access-list you created?

The idea behind the SPAN session is to determine what traffic is flowing in/out of an interface, specifically what the server is sending.

This way you can understand its behavior and proceed accordingly, by adding more services to the list of denied ports on the SPAM Access-list or by checking the server itself and correcting its functionality if necessary.

[Ezequiel Pineda]

Hi,

I applied this on the Interface Vlan (logical int) of that server.

This is the interface that has the Ip address of the server and so forth.

I created a named ACL instead of a Numbered, dont think i can actually debug a named ACL.

If what you suggest is for me to create a numbered ACL, apply it to the Vlan interface and then debugging it, i might be able to do that.

I hate to do ACL debugging though, because this is a Core Switch, has LOTS of traffic and i dont like seeing the CPU sky-rocket!

Please let me know what your suggestions are.

Thanks again.

Ezequiel Pineda

[Favaloro.]

I'm suggesting you get a packet capture on the interface the server is connected to.

The way to do it is with a SPAN session.

Here's how you do it.

http://www.cisco.com/en/US/products/hw/switches/ps708/products_tech_note09186a008015c612.shtml

If that's not an option, you can get the capture from the server itself.

[Ezequiel Pineda]

So for anyone with the same issue, i have learned that you can block GRE as a whole on an extended ACL by adding:

deny gre any any

this solved my issue, hope it helps someone else having the same issue.