Anti Spoofing

I have an AIP-SSM-20 module that I am in the process of upgrading the system images and the signatures.
I was wondering if someone could guide me in the right direction on how to configure an anti-spoofing policy on the sensor.
If you have some sample configs that I could look at or even if you can explain to me how to do it through the GUI I would really appreciate it.

Carlos,
It depends on what type of attack you are attempting to protect against. RPF will help you when a host spoofs an address on an interface where it should not live. For instance, if your internal network is 192.168.1.0/24 and a packet arrives on the outside of your firewall with a source address of 192.168.1.2, the appliance can drop the packet due to the information in its routing table. However, SYN floods from the Internet are a different matter. There is a mechanism on the IPS that can help you with this. Please see the document below for the SYN Cookie functionality of IPS Signature 3050/0.
https://supportforums.cisco.com/docs/DOC-11874
Thank you,
Blayne Dreier
Cisco TAC IDS Team
**Please check out our Podcast**
TAC Security Show: http://www.cisco.com/go/tacsecuritypodcast

Similar Messages

  • How to create anti-spoof rules with exception

    Hello all,
    I'm a beginner with Ironport and I need to create rules for specific cases.
    I manage many mail domains and I want to create an anti-spoof rule with message filter. Easy to do with a dictionnary containing all my mail domains.
    But I have some mail addresses with external applications that need to be send with my mail domains.
    For example, I receive acknowledge mails sent with [email protected] address and example.com is an domain accepted and managed by my enterprise. So if I activate my anti-spoof rule, all external [email protected] mail will be dropped.
    For example I tried this rule with no success :
    Filter_AntiSpoofing: if (recv-listener == "IncomingMail") AND (mail-from-dictionary-match("My_Domains", 1)) AND (mail-from-dictionary-match("Bypass_Sender", 0)){
    drop();
    I tried this rule too :
    Filter_AntiSpoofing: if (recv-listener == "IncomingMail") AND (mail-from-dictionary-match("My_Domains", 1)) AND ((mail-from !="^[email protected]$") OR (mail-from !="^[email protected]$") OR (mail-from !="@ack.mydomain.com$")){
    drop();
    Have you got any tips or advice to answer my funny case ?

    Hello,
    We use the following message filter to ear-mark spoofed messages with an X-Header (which we later use for reporting since we told Ironport to log this specific header)
    Spoofed_Email_Filter: if (recv-listener == "IncomingMail") AND (mail-from-dictionary-match("dict_internaldomains", 1)) {
    insert-header("X-Spoofed", "from[$EnvelopeFrom]_To[$EnvelopeRecipients]_IP[$RemoteIP]_rep[$Reputation]");
    The one drawback is that we need to maintain the Dictionary "dict_internaldomains". If we forget to add a new domain to this list it will never be detected as spam.
    A good new message filter functionality would be to be able to do a "mail-from-rat-match" which would allow you to use the RAT tables(s) as dictionary.
    We plan to solve this by moving the RAT to LDAP and query that same LDAP as dictionary. (If only I had time to test it) :D
    Good luck,
    Steven

  • Anti spoof acl and cisco 7606

    Hi all,
    I have strange problem with anti spoof access-list which I would like to set up in cisco 7606 with 7600-PFC3CXL. So I made an access-list which is in [1.] and set up on interface Te1/1 like this [2.], but there are no match in output direction? Why? Well I made a test with [3.] but no matchs in access-list and ICMP was working than I made change [4.] and yeap icmp was not working and I have seen match in input direction good. It looks like that output direction in acl not working so I removed line 1 inc acl [4.] and icmp still not working and acl [3.] started matching icmp in line 1? Why? Can anybody help me? Thanks.
    Karel
    btw.> I tried solve this problem with this links:
    http://www.cisco.com/en/US/docs/routers/7600/ios/12.2SR/configuration/guide/acl.html
    http://www.cisco.com/web/about/security/intelligence/acl-logging.html
    [1.]
    Extended IP access list anti_spoof_Te1/1_input
    10 deny ip 10.0.0.0 0.255.255.255 any
    20 deny ip 172.16.0.0 0.15.255.255 any
    30 deny ip 192.168.0.0 0.0.255.255 any
    40 deny ip 127.0.0.0 0.255.255.255 any
    50 deny ip 194.79.52.0 0.0.3.255 any
    60 deny ip 0.0.0.0 0.255.255.255 any
    70 permit ip any OUR CIDR
    80 permit ip any host BGP Neighbor
    90 deny ip any any
    Extended IP access list anti_spoof_Te1/1_output
    10 deny ip any 10.0.0.0 0.255.255.255
    20 deny ip any 172.16.0.0 0.15.255.255
    30 deny ip any 192.168.0.0 0.0.255.255
    40 deny ip any 127.0.0.0 0.255.255.255
    50 deny ip any 0.0.0.0 0.255.255.255
    60 deny ip any OUR CIDR
    70 permit ip host BGP Neighbor any
    80 permit ip OUR CIDR any
    90 deny ip any any
    [2.]
    ip access-group anti_spoof_Te1/1_input in
    ip access-group anti_spoof_Te1/1_output out
    [3.]
    Extended IP access list anti_spoof_Te1/1_output
    1 deny icmp host from OUR CIDR host in INTERNET log-input
    10 deny ip any 10.0.0.0 0.255.255.255
    20 deny ip any 172.16.0.0 0.15.255.255
    30 deny ip any 192.168.0.0 0.0.255.255
    40 deny ip any 127.0.0.0 0.255.255.255
    50 deny ip any 0.0.0.0 0.255.255.255
    60 deny ip any OUR CIDR
    70 permit ip host BGP Neighbor any
    80 permit ip OUR CIDR any
    90 deny ip any any log-input
    [4.]
    Extended IP access list anti_spoof_Te1/1_input
    1 deny icmp host from INTERNET host from OUR CIDR
    10 deny ip 10.0.0.0 0.255.255.255 any
    20 deny ip 172.16.0.0 0.15.255.255 any
    30 deny ip 192.168.0.0 0.0.255.255 any
    40 deny ip 127.0.0.0 0.255.255.255 any
    50 deny ip 194.79.52.0 0.0.3.255 any
    60 deny ip 0.0.0.0 0.255.255.255 any
    70 permit ip any OUR CIDR
    80 permit ip any host BGP Neighbor
    90 deny ip any any

    Following links may help you
    http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801a1a55.shtml
    http://www.cisco.com/en/US/tech/tk648/tk361/technologies_tech_note09186a0080120f48.shtml

  • Increasing anti-spoofing rules

    What options are available on the C370's for implementing anti-spoofing controls in order to protect our company from the increasing number of phishing emails using spoofed addresses?  
    We already have an inbound rule to check the mailfrom: field and reject all messages that contain our domains

    Hello Anne,
    I hope that this tech-note may help:
    http://www.cisco.com/c/en/us/support/docs/security/email-security-appliance/117796-problemsolution-esa-00.html
    This is a technote to assist with tagging possibly spoofed emails.
    You can change the action to another action if you want it to be dropped or actions in some other manner.
    Regards,
    Matthew

  • Anti-spoofing rule

    I am trying to create a antispoofing rule using message filter feature.
    It is like
    if ( header("from") == "@*mydomain\\.com$" ) { apply anti-spoofing rules here; }
    But the rough part is to be able to whitelist certain hosts, e.g., our partners.
    For example:
    AND ( header("Received") != "whitelist1|whitelist2...." )
    Is there a better way to do this? My concern is that this will get very long and error prone over time.
    Thanks,
    Jack

    What if you add all your partner ip addresses/domains to a sendergroup called 'partner_whitelist'.
    Next, you can modify your existing filter to bypass spoofing checks from partner domains:
    if (( header("from") == "@*mydomain\\.com$" ) AND (sendergroup != 'partner_whitelist'))
    { apply anti-spoofing rules here; }

  • Cisco 1921 - Anti Spoofing?

    Hello there.
    I have a customer who has a service from "sharedband" which basically bonds two adsl lines. The DSL lines terminate to two netgear routers that talk to each other using the sharedband service. The two netgears present a single ip address to the LAN, which i have placed a router in the way to provide firewall services.
    I have configured s2s VPN, CBAC, ACLs and locked down the router pretty well. But havent configured any sort of anti spoofing.
    The support guy from sharedband say i need to "turn off" anti spoofing on the Cisco router. But i HAVENT configured it and am not aware its on by default. As you can imagine, when both netgears are switched on, packets get lost and the service goes really slow. When only one router is operational, it works like a dream albeit slow due to the line speed.
    Is their anything on by default, or can i configure anything to allow 2 mac addresses to be accepted for the same IP address. Its not like HSRP where it provides a virtual MAC address. IP CEF is switched ON, its running IOS version 15.0.
    The folks at shareband pointed my in the direction of a document they provide that states how to switch anti spoofing off, but thats on a draytek which we arnt using.
    Here is that link http://support.sharedband.com/index.php?act=article&code=view&id=3.
    Anyone know how to do this in IOS?

    Hi,
    I found this post Googling after problems with 1921 on Sharedband.  opened TAC case - no luck so far.
    However adding secondary IP in subnet of Sharedband physical IPs enables 1921 to "see" all the Sharedband routers and improves performance - same result as Sharedband "20 milliseconds of resequencing" workround
    ip address 192.168.3.254 255.255.255.0 secondary
    1921-BRSA-2CAMB#sh ip arp g0/1
    Protocol  Address          Age (min)  Hardware Addr   Type   Interface
    Internet  91.108.165.74           -   588d.0978.3f21  ARPA   GigabitEthernet0/1
    Internet  192.168.3.254           -   588d.0978.3f21  ARPA   GigabitEthernet0/1
    Internet  91.108.165.73           0   e894.f667.eff8  ARPA   GigabitEthernet0/1
    Internet  192.168.3.4             0   e894.f6bb.b990  ARPA   GigabitEthernet0/1
    Internet  192.168.3.1           137   e894.f667.eff8  ARPA   GigabitEthernet0/1
    Internet  192.168.3.2            94   e894.f6bb.bc76  ARPA   GigabitEthernet0/1
    Internet  192.168.3.3           113   e894.f6bb.b8f8  ARPA   GigabitEthernet0/1

  • GSS anti spoofing

    Hello.
    Anyone ever tried GSS DDOS license? I am worried about redirecting a DNS request over TCP. What if the D-proxy is a legitime one but is configured not to respond to tcp requests?  In this case I am going to block legitime requests (I know I can add trusted D-proxies to GSS)
    Anyone ever tried this feature?
    Best regards,
    Joao.

    I am afraid there may be toons of D-proxies not responding to tcp.
    Regards,
    Joao. 

  • ISE & Switch URL redirect not working

    Dear team,
    I'm setting up Guest portal for Wired user. Everything seems to be okay, the PC is get MAB authz success, ISE push URL redirect to switch. The only problem is when I open browser, it is not redirected.
    Here is some output from my 3560C:
    Cisco IOS Software, C3560C Software (C3560c405-UNIVERSALK9-M), Version 12.2(55)EX3
    SW3560C-LAB#sh auth sess int f0/3
                Interface:  FastEthernet0/3
              MAC Address:  f0de.f180.13b8
               IP Address:  10.0.93.202
                User-Name:  F0-DE-F1-80-13-B8
                   Status:  Authz Success
                   Domain:  DATA
          Security Policy:  Should Secure
          Security Status:  Unsecure
           Oper host mode:  multi-domain
         Oper control dir:  both
            Authorized By:  Authentication Server
               Vlan Group:  N/A
         URL Redirect ACL:  redirect
             URL Redirect:  https://BYODISE.byod.com:8443/guestportal/gateway?sessionId=0A005DF40000000D0010E23A&action=cwa
          Session timeout:  N/A
             Idle timeout:  N/A
        Common Session ID:  0A005DF40000000D0010E23A
          Acct Session ID:  0x00000011
                   Handle:  0xD700000D
    Runnable methods list:
           Method   State
           mab      Authc Success
    SW3560C-LAB#sh epm sess summary
    EPM Session Information
    Total sessions seen so far : 10
    Total active sessions      : 1
    Interface            IP Address   MAC Address       Audit Session Id:
    FastEthernet0/3       10.0.93.202  f0de.f180.13b8    0A005DF40000000D0010E23A
    Could you please help to explore the problem? Thank you very much.

    With switch IOS version later than 15.0 the default interface ACL is not required. For url redirection the dACL is not required as this ACL is part of traffic restrict for "guest" users.
    In my experiece some users can not get the redirect correctly because anti-spoof ACL on management Vlan or stateful firewall blocks the TCP syn ack.
    It is rare in campus network access layer switches have user SVI configured so the redirect traffic has to be sent from the netman SVI, but trickly the TCP SYN ACK from the HTTP server will be sent back from the netman Vlan without source IP changed. (The switch is spoofing the source IP in my understanding with changing only the MAC address of the packet). In most of the cases there should be a basic ACL resides on the netman SVI on the first hop router, where the TCP SYN ACK may be dropped by the ACL.
    tips:
    1. "debug epm redirect" can make sure your traffic matches the redirect url and will get intercepted by the switch
    2. It will be an ACL or firewall issue if you can see epm is redirecting your http request but can not see the SYN ACK from the requested server.
    Which can win the race: increasing bandwidth with new technologies VS QoS?

  • SPAM filter setting for CRES secure e-mail

    I am using Ironport strictly as an outgoing e-mail encryption engine. We use a different incoming spam filter (Barracuda). I would like to be able to go to the CRES site and send an encrypted message to our internal domain so users can establish their CRES credentials. However, the anti-spoofing rules on the Barracuda block the incoming mail because the domain it was from is our internal domain. I have whitelisted the mx-res.cisco.com address, 216.206.186.134, but I am still receiving block messages like below (I removed the actual e-mail address):
    Your message did not reach some or all of the intended recipients.
    Subject: Test 1
    Sent: 10/15/2009 7:36 AM
    The following recipient(s) cannot be reached:
    (removed) on 10/15/2009 7:36 AM
    The e-mail system was unable to deliver the message, but did not report a specific reason. Check the address and try again. If it still fails, contact your system administrator.
    mx1.res.cisco.com #5.0.0 smtp; 5.1.0 - Unknown address error 550-'Blocked\x00\x006' (delivery attempts: 0)
    First of all, are there other IP addresses I should be whitelisting for Cisco RES outbound e-mail mail servers? What else do I need to do? I don't want to turn of the anti-spoofing, due to the spam we would receive.

    With the recent CRES upgrade IP address range used for mail delivery has changed. Please refer the below posting.
    https://www.ironportnation.com/forums/viewtopic.php?t=1482
    Best,
    Kishore

  • ACL's on the Internet Edge Routers

    I have one query on ACL's on the internet edge routers. If we configure the ACL's as per the below weblink on the edge routers, we may not get all the logs on the firewall as the traffic is filtered at the router level and we donot enable logging on the router.
    http://www.cisco.com/en/US/tech/tk648/tk361/technologies_white_paper09186a00801afc76.shtml
    Unless we enable IDS on this segment there is no way of knowing any attacks towards the firewall or the router itself. I need some comments from security experts on this kind of implementation.
    Thank You very much,

    Hello Avil,
    You need to necessarily need to have an IPS on your segment to know all the attacks hitting your network !!!!! with the anti-spoof ACL applied, as given above, you are only blocking standard protocols or ports coming inside your network.. there can still be attacks on known ports that you are allowing.. if i had to capture that, i would either put an IPS on my network (or SSM card with ASA) or enable logging on devices and put a CS-MARS on my network.. MARS is an extremely useful device, focussed on increasing LAN security with real-time maps on attacks and it also will say how to stop the attack !!!! so, i guess only a couple of options here for you.... not sure if anyone else have any other options...
    Hope this helps.. all the best..
    Raj

  • How do you promote a static route over a directly connected?

    Hi all,
    I have a need for a static route to be used instead of a directly connected route. (Long story - involving firewalls and anti-spoofing.. but can go further if required)
    I am using a Cisco 3750 switch. I notice directly connected routes have a metric of 0, and the highest metric I can give a static route is 1.
    Therefore, how is it possible for me to make the switch use the static route and not the directly connected?
    Any help would be appreciated!
    Cheers,
    Ben

    Hi Rick,
    Thanks for your patience.
    Maybe I should start again.
    Initially we had 16 VLANs within the 10.0/16 address space. We have some Cisco 3750's connected by dark fibre accross a couple of kms and then lower access switches all hanging of these by some means. The network is flat.
    We have a checkpoint firewall hanging off one of the 3750s connected using a TRUNK port. The firewall has an IP address on all VLANs and is used to route traffic between VLANs based on its ruleset.
    So if I have a user in VLAN 10 who wants to talk to VLAN 20, they travel to the firewall, if a rule permits the access, the firewall routes the packet on to VLAN 2 and the switches deliver at Layer 2.
    The switches all have their default VLAN 1 disabled, and have an IP address on our management VLAN to allow us to manage the switches.
    Its quite important that this IP is on a secured management VLAN as we don't want just anyone being able to snoop switch logins etc..
    If we need to login to a switch, the firewall routes our traffic from whatever VLAN we are on to the Management VLAN.
    One of our VLANs (the Desktop VLAN) is quite large (approx 1300 hosts) and suffers a great deal from too much arp broadcast traffic.
    As we have a flat switched network across several kms, the cost of putting in routers to subnet this large VLAN is excessive.
    However, the 3750's we have are perfectly capable of routing between VLANs, so we decide to create a load of new VLANs instead of subnetting our large VLAN. We don't want to use the firewall to route between these new VLANs as thats just giving the firewall more to do, and previously all these hosts were on a single subnet, so we have no need for any strict security - at most we can use ACLs on the switches if we even need that!
    So far so good.
    With 1300 hosts, we obviously can't make sudden topology changes. Therefore we need to be able to route between the Desktop VLAN and the new VLANs.
    We therefore introduce the static routes between the firewall and the switches.
    So the firewall says:
    route 10.1.0.0/16 via Multilayer switch IP on 10.1.0.0/16
    The multilayer switch says:
    route 10.0.0.0/16 via Firewall IP on 10.1.0.0/16
    This allows routing perfectly between the Desktop VLAN and the new VLANs.
    However the moment we enable ip routing on the switches we break access between the desktop VLAN and the Management VLAN.
    A packet leaves the desktop VLAN through the default gateway on the firewall. This is then routed to the Management VLAN. The return packet doesn't use the Management VLAN default gateway (firewall), it follows the static route on the switch and ends up at the firewall on 10.1.0.0/16. This is subsequently dropped as the firewall knows the packet hasn't come from the 10.1.0.0/16 network, it originally came from the desktop VLAN on 10.0.0.0/16.
    It might seem we can define a route on the switch to say:
    route 10.0.50.0/24 (management VLAN) via 10.0.50.254 (firewall). However, this would result in all packets from 10.1.0.0/16 being dropped by the firewall.
    The other problem is that if we are on a new VLAN and want to talk to the management VLAN. The packet goes to its default gateway on the switch. The switch says - "I have an IP on the management VLAN, its directly connected" - therefore it ignores the static route, and passes the packet on its way. We have now bypassed the firewall, which is bad.
    Incidentally the return packets get routed through the firewall and dropped, as the original packet didn't come through the firewall, there is no entry in the state table for its return.
    I think if we turned off the management interface on the switch and managed it through the interface on 10.1.0.0/16, I assume everything would work. However, we don't want to do this for a whole load of other reasons I wont go into.
    Im sure there must be a fairly simple solution - I just don't have enough experience!
    Cheers,
    Ben

  • Source ip address for icmp messages not what is expected

    We have a router that has interfaces in multiple VRFs.  One interface sits on an interface that is routed on the Internet.  Other interface sits on a VRF that is in a private address space and is used for WAN connectivity.  The strange behavior that I'm seeing is related to icmp messages coming off the router.  It appears that scanners hitting the Internet-facing interface cause the router to generate icmp messages (type 3) that are source using the IP address of the WAN-facing interface and they are routed across the WAN, into our data center and dropped by our firewall due to anti-spoofing rules.  Is this normal behavior?  Doesn't seem normal to me. Is this behavior something that can be changed via configuration?

    probabaly some body attacking you
    you need inbound access-list in Internet-facing interface.
    and you need to filtr private source addresses classes  A, B, C 
    ip access-list extended InWorld
     deny   ip any 192.168.0.0 0.0.255.255
     deny   ip any 172.16.0.0 0.15.255.255
     deny   ip any 10.0.0.0 0.255.255.255
     permit ip any any
    interface FastEthernet0
     description Internet-facing interface
     ip address 9.2.3.6 255.255.255.252
     ip access-group InWorld in
    later you will see hit counts
    sh access-lis
    here is detailed explanation
    http://www.techrepublic.com/article/prevent-ip-spoofing-with-the-cisco-ios/
    they using more complicated acces-list
    In a typical IP address spoofing attempt, the attacker fakes the source of packets in order to appear as part of an internal network. David Davis tells you three ways you can make an attacker's life more difficult—and prevent IP address spoofing. 
    As you know, the Internet is rife with security threats, and one such threat is IP address spoofing. During a typical IP address spoofing attempt, the attacker simply fakes the source of packets in order to appear as part of an internal network. Let's discuss three ways you can protect your organization from this type of attack.
    Block IP addresses
    The first step in preventing spoofing is blocking IP addresses that pose a risk. While there can be a reason that an attacker might spoof any IP address, the most commonly spoofed IP addresses are private IP addresses (RFC 1918) and other types of shared/special IP addresses.
    Here's a list of IP addresses—and their subnet masks—that I would block from coming into my network from the Internet:
    10.0.0.0/8
    172.16.0.0/12
    192.168.0.0/16
    127.0.0.0/8
    224.0.0.0/3
    169.254.0.0/16
    All of the above are either private IP addresses that aren't routable on the Internet or used for other purposes and shouldn't be on the Internet at all. If traffic comes in with one of these IP addresses from the Internet, it must be fraudulent traffic.
    In addition, other commonly spoofed IP addresses are whatever internal IP addresses your organization uses. If you're using all private IP addresses, your range should already fall into those listed above. However, if you're using your own range of public IP addresses, you need to add them to the list.
    Implement ACLs
    The easiest way to prevent spoofing is using an ingress filter on all Internet traffic. The filter drops any traffic with a source falling into the range of one of the IP networks listed above. In other words, create an access control list (ACL) to drop all inbound traffic with a source IP in the ranges above.
    Here's a configuration example:
    Router# conf t
    Enter configuration commands, one per line.  End with CNTL/Z.
    Router(config)# ip access-list ext ingress-antispoof
    Router(config-ext-nacl)# deny ip 10.0.0.0 0.255.255.255 any
    Router(config-ext-nacl)# deny ip 172.16.0.0 0.15.255.255 any 
    Router(config-ext-nacl)# deny ip 192.168.0.0 0.0.255.255 any 
    Router(config-ext-nacl)# deny ip 127.0.0.0 0.255.255.255 any
    Router(config-ext-nacl)# deny ip 224.0.0.0 31.255.255.255 any
    Router(config-ext-nacl)# deny ip 169.254.0.0 0.0.255.255 any     
    Router(config-ext-nacl)# permit ip any any     
    Router(config-ext-nacl)# exit
    Router(config)#int s0/0
    Router(config-if)#ip access-group ingress-antispoof in
    Internet service providers (ISPs) must use filtering like this on their networks, as defined in RFC 2267. Notice how this ACL includes permit ip any any at the end. In the "real world," you would probably have a stateful firewall inside this router that protects your internal LAN.
    Of course, you could take this to the extreme and filter all inbound traffic from other subnets in your internal network to make sure that someone isn't on one subnet and spoofing traffic to another network. You could also implement egress ACLs to prevent users on your network from spoofing IP addresses from other networks. Keep in mind that this should be just one part of your overall network security strategy.
    Use reverse path forwarding (ip verify)
    Another way to protect your network from IP address spoofing is reverse path forwarding (RPF)—or ip verify. In the Cisco IOS, the commands for reverse path forwarding begin with ip verify.
    RPF works much like part of an anti-spam solution. That part receives inbound e-mail messages, takes the source e-mail address, and performs a recipient lookup on the sending server to determine if the sender really exists on the server the message came from. If the sender doesn't exist, the server drops the e-mail message because there's no way to reply to the message—and it's very likely spam.
    RPF does something similar with packets. It takes the source IP address of a packet received from the Internet and looks up to see if the router has a route in its routing table to reply to that packet. If there's no route in the routing table for a response to return to the source IP, then someone likely spoofed the packet, and the router drops the packet.
    Here's how to configure RPF on your router:
    Router(config)# ip cef
    Router(config)# int serial0/0
    Router(config-if)# ip verify unicast reverse-path
    Note that this won't work on a multi-homed network.
    It's important to protect your private network from attackers on the Internet. These three methods can go a long way toward protecting against IP address spoofing. For more information on IP address spoofing, read "IP Address Spoofing: An Introduction."
    Is IP address spoofing a major concern for your organization? What steps have you taken to protect the company? Have you used RPF? Share your experiences in this article's discussion.
    and dont forget to rate post

  • STB Sending ARP requests every 9 minutes

    IS there a particular reason that I keep getting ARP requests from the STB even though it has been assigned an IP?
    Solved!
    Go to Solution.

    So there is no way to route that correctly?
    I mean, I havent blocked any of that traffic.
    I used to use a different router with my old service and well you guys supply one.
    Since I have a new router now, I wanted to check how well the firewall was set up and if there was any automatic anti-spoofing on the router or if I had to set it up myself.
    So with feeling insecure I turned my personal Outpost firewall back on on my computer.
    Which is catching that as a spoofing attack of course.
    But now my question is, couldnt that traffic be routed appropriately?
    IT doesnt seem like a big deal, just a little messy.
    And this thread is easily applying to FIOS INTERNET more and more as we talk.
    Form what I get its the STB's looking for the DVR.
    What would happen if you blocked that info coming across the bridge or routed the info appropriately vs blocking it.
    Does it have to come across the bridge and if so why?
    Form the looks of things I could definitely keep that on the coax side of things vs having it run across the bridge.
    My comp recognizes it as spoofing but the router doesnt of course because its all behind the router.
    Maybe you could help me further or someone else in defining the design of that communication.
    Again its harmless and not a big deal its more curiosity than anything else at this point.

  • Router emails trigger error 553

    I sometimes want my Netgear ADSL router to email me it's log, but this now gives me Error 553. Netgear are baffled and so am I. Can anyone tell me what precisely causes the BTYahoo SMTP server to send 553? The router's email is effectively from me to me so it shouldn't trigger the anti-spoof trap.  Driving the BTYahoo SMTP server manually with TELNET seems to point to the MAIL FROM: command failing but I can't figure out why. If I manually send MAIL FROM: <me> and RCPT TO: <me> it succeeds, and I had assumed that is what the router does.  MAIL FROM: <someone_else> fails with 553 of course.  A friend who has the same router finds it works fine on another ISP, so BTYahoo are doing something odd.
    BT's helpline didn't understand my problem at all.  I hope someone here does!.
    regards
    Peter

    PeterMartinez wrote:
    IanC:
    I have to ASSUME that the router tries to send this email FROM me TO me, which should be perfectly acceptable to the SMTP server. I don't know if it does this because this email never gets sent forward and never gets sent back!  All I see (if I later access the router via its web interface) is the Error553 message in the log.  I asked a pal with the same router to try it. It worked with his ISP and the message HEADERS showed the To: and From: headers were [email protected] , but there's no way to see what the addresses were in the MAIL FROM: and RCPT TO: commands in the SMTP protocol (these are NOT the same as the "To:" and "From:" headers in the message body).  I haven't been able to get Netgear to tell me what addresses their router does use (should be [email protected]) so I am trying to work from the other end and find out what it is that the SMTP server at BTYahoo doesn't like when it throws a 553 at me.  I know it does this if I manually type MAIL FROM: [email protected] into TELNET.  I am certain this isn't a verification problem, it's a clash between the way BTYahoo's SMTP server is (now) behaving and the way the Netgear router is behaving.
    regards
    Peter  
    Hi Peter. Welcome to the forums.
    It is a verification problem, and the "From" email address should be enough to be honest, much like a normal email. What Netgear router is it ?
    Can you say for certain that you have provided one of your @btinternet.com email addresses and corresponding password to the netgear settings ? (sorry for the obvious question).
    Do you know if it has ever worked for you ? I expect there are other users of that router, so wonder if they have a similar problem.
    Are you getting any response emails at all (e.g. in your spam folder, typically only accessible via webmail) for this problem ?
    http://www.andyweb.co.uk/shortcuts
    http://www.andyweb.co.uk/pictures

  • Delayed inbound email between Sonicwall ES300 and Yosemite server

    I currently have a setup consisting of a Yosemite email server with a Sonicwall ES300 as a relay.
    Under moderate to heavy email traffic, I've been noticing that inbound emails (from the ES300 to the Yosemite server) begin to queue up on the ES300 with the message of ECONNRESET. This queue will sometimes rise as high as 200 emails and will eventually all clear out at once (sometimes after an hour or so). Email will flow correctly for a short period before the queue will begin to build again. This does not affect outbound or internal email. During times of low email usage (weekends), emails are rarely queued.
    I've experienced this issue as well with an older server running 10.6. I'm not sure wether this is something that needs to be corrected on the Yosemite server or the ES300.
    I'm curious if anyone has experienced similar issues. Is there something within main.cf or master.cf that could be rate limiting the IP of the ES300? If this is the case, it would have to be something in the default configuration since I haven't configured anything out of the ordinary. My other theory is that this could be due to high CPU usage on the ES300 causing connection issues.
    Any help or ideas would be greatly appreciated.
    Thanks!

    The web interface System Status page for the SonicWall will show CPU usage so you can see if it is running high. You can also on newer models go to the Diagnostics page and run the Multi-Core monitor to see a real time chart of CPU usage.
    Some systems will impose a delay on connections if they 'decide' that the connections are suspicious e.g. possible spam or hacking attacks. You could temporarily as a test try disabling any anti-spam or anti-spoofing features you may currently have enabled. Apple's OS X also has a software firewall which can do much the same thing. See the following.
    OS X Server: About the Firewall service - Apple Support
    OS X Server: How to enable the adaptive firewall - Apple Support
    Other than that, your SonicWall should be covered by a support/extended warranty agreement, this would allow you to contact SonicWall directly for support. They can then with your permission look at your SonicWall logs to provide you assistance.

Maybe you are looking for