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
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
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
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
.
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.