cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Anonymous
Not applicable

TA900 Firewall

Jump to solution

I am trying to configure the firewall to only communicate with my SIP Server but cannot get it to work properly it seems. . The TA9xx has a public IP and is only used to provide a PRI to a PBX. When I debug sip stack messages I still see invites getting in and being responded to. What am I doing wrong?

ip firewall

interface eth 0/1

  ip address  4.4.4.4  255.255.255.255

  no shutdown

  media-gateway ip primary

ip access-list standard Access

  permit host 2.2.2.2

  permit 192.168.x.0 0.0.0.255

!

ip access-list standard sip-allow-list

  permit host 3.3.3.3

!

ip policy-class SIP

  allow list sip-allow-list self

http ip access-class Access in

http ip secure-access-class Access in

line ssh 0 4

  login local-userlist

  no shutdown

  ip access-class Access in

Labels (2)
Tags (1)
0 Kudos
1 Solution

Accepted Solutions
jayh
Honored Contributor
Honored Contributor

Re: TA900 Firewall

Jump to solution

You've created an access-list and a policy, but haven't applied it to an interface.

However, doing it the way you have done may not be the best choice, as RTP from the outside may come from other sources than SIP, and you'll want to access the box for management, probably not from your SIP server. I'd suggest this:

ip access-list standard sip-allow-list

  permit host 3.3.3.3

sip access-class ip "sip-allow-list" in

This will restrict SIP connections to the device to the list regardless of interface, but won't affect RTP or other connections.

In addition, you might want to lock down the ability to access the device from telnet, ssh, or GUI. This will prevent brute-force attacks on the device. These connections will probably be coming from different ip ranges than your SIP server.

ip access-list standard mgmt-allow-list

  ! Trusted management subnets go here.

  permit host 10.10.10.10

  permit 172.16.0.0 0.0.255.255

 

http ip access-class mgmt-allow-list in

http ip secure-access-class mgmt-allow-list in

line telnet 0 4

ip access-class mgmt-allow-list in

line ssh 0 4

ip access-class mgmt-allow-list in

View solution in original post

0 Kudos
3 Replies
jayh
Honored Contributor
Honored Contributor

Re: TA900 Firewall

Jump to solution

You've created an access-list and a policy, but haven't applied it to an interface.

However, doing it the way you have done may not be the best choice, as RTP from the outside may come from other sources than SIP, and you'll want to access the box for management, probably not from your SIP server. I'd suggest this:

ip access-list standard sip-allow-list

  permit host 3.3.3.3

sip access-class ip "sip-allow-list" in

This will restrict SIP connections to the device to the list regardless of interface, but won't affect RTP or other connections.

In addition, you might want to lock down the ability to access the device from telnet, ssh, or GUI. This will prevent brute-force attacks on the device. These connections will probably be coming from different ip ranges than your SIP server.

ip access-list standard mgmt-allow-list

  ! Trusted management subnets go here.

  permit host 10.10.10.10

  permit 172.16.0.0 0.0.255.255

 

http ip access-class mgmt-allow-list in

http ip secure-access-class mgmt-allow-list in

line telnet 0 4

ip access-class mgmt-allow-list in

line ssh 0 4

ip access-class mgmt-allow-list in

0 Kudos
Anonymous
Not applicable

Re: TA900 Firewall

Jump to solution

Thank you, I updated based on your suggestion. I ran a debug ip firewall and I see the following. Not sure if the traffic is being blocked.

2017.05.21 21:38:35 FIREWALL Adding new associations to DB

2017.05.21 21:38:35 FIREWALL   Assoc Index = 33, Count (total, policy-class) = 3, 3

2017.05.21 21:38:35 FIREWALL   allow, flags = 0x00000000, 0x00000000, timeout = 20

2017.05.21 21:38:35 FIREWALL   Selector1: Dir=default, int=eth 0/1, Protocol=6  cookie-> Loopback

2017.05.21 21:38:35 FIREWALL     SrcIp: 158.69.210.255, DstIp: 10.10.10.10

2017.05.21 21:38:35 FIREWALL     SrcPort: 42720, DstPort: 4899

2017.05.21 21:38:35 FIREWALL   Selector2: Dir=SELF, int=Loopback, Protocol=6

2017.05.21 21:38:35 FIREWALL     SrcIp: 10.10.10.10, DstIp: 158.69.210.255

2017.05.21 21:38:35 FIREWALL     SrcPort: 4899, DstPort: 42720

2017.05.21 21:38:35 FIREWALL Updated Selector2's Cookie

2017.05.21 21:38:35 FIREWALL   Assoc Index = 33, Count (total, policy-class) = 3, 3

2017.05.21 21:38:35 FIREWALL   allow, flags = 0x00000000, 0x00000004, timeout = 20

2017.05.21 21:38:35 FIREWALL   Selector2: Dir=SELF, int=Loopback, Protocol=6  cookie-> eth 0/1

2017.05.21 21:38:35 FIREWALL     SrcIp: 10.10.10.10, DstIp: 158.69.210.255

2017.05.21 21:38:35 FIREWALL     SrcPort: 4899, DstPort: 42720

2017.05.21 21:38:54 FIREWALL Deleting Association

2017.05.21 21:38:54 FIREWALL   Assoc Index = 33, Count (total, policy-class) = 3, 3

2017.05.21 21:38:54 FIREWALL   allow, flags = 0x0000001D, 0x00000004, timeout = 6

2017.05.21 21:38:54 FIREWALL   Selector1: Dir=default, int=eth 0/1, Protocol=6  cookie-> Loopback

2017.05.21 21:38:54 FIREWALL     SrcIp: 158.69.210.255, DstIp: 10.10.10.10

2017.05.21 21:38:54 FIREWALL     SrcPort: 42720, DstPort: 4899

2017.05.21 21:38:54 FIREWALL   Selector2: Dir=SELF, int=Loopback, Protocol=6  cookie-> eth 0/1

2017.05.21 21:38:54 FIREWALL     SrcIp: 10.10.10.10, DstIp: 158.69.210.255

2017.05.21 21:38:54 FIREWALL     SrcPort: 4899, DstPort: 42720

.

jayh
Honored Contributor
Honored Contributor

Re: TA900 Firewall

Jump to solution

garabedy wrote:

2017.05.21 21:38:35 FIREWALL SrcIp: 158.69.210.255, DstIp: 10.10.10.10

2017.05.21 21:38:35 FIREWALL SrcPort: 42720, DstPort: 4899

The firewall itself isn't blocking it, but there isn't a socket listening on port 4899 so this isn't a problem.

Your goal is to filter traffic to the TA900 itself, not through it, so you're doing the right thing. The SIP ACL will take care of "friendly scanner" and other SIP attacks and the management ACL will block off-net attacks on the GUI and SSH/telnet interfaces.

Seeing random port-scanning noise like your example above is all too common these days. You could test from someone off-net to see if they can access SIP services or log in to the device. These attempts should fail, but you should be able to establish SIP connections to and from your trusted provider and administer the unit from trusted networks.