Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Filtering a specific IP address
- Thread starter Narboule
- Start date
If you want to filter an specific address I would use the "host" option. For example:
Router(config)#access-list 101 deny tcp host 192.168.0.1 any eq 5190
Router(config)#access-list 101 deny udp host 192.168.0.1 any eq 5190
Router(config)#access-list 101 permit ip any any
Router(config)#access-list 101 deny tcp host 192.168.0.1 any eq 5190
Router(config)#access-list 101 deny udp host 192.168.0.1 any eq 5190
Router(config)#access-list 101 permit ip any any
- Thread starter
- #5
Thanks for your replies.
I installed the new filter, it shows up in the NVRAM configuration, but it doesn't block the traffic - the firewall on the computer I tested it on shows port 5190 being used to connect to AIM and I am able to use the AIM service.
Here's my complete access list. Maybe there's a problem with order or some other conflict. I'd like to block <IP1> both incoming and outgoing.
access-list 120 deny udp host <IP1> any eq 5190
access-list 120 permit udp any eq domain 195.134.160.0 0.0.15.255
access-list 120 permit udp any host <NS1> eq domain
access-list 120 permit udp any host <NS2> eq domain
access-list 120 permit udp any any eq ntp
access-list 120 permit udp any <IPaddress> 0.0.15.255 eq 407
access-list 120 permit udp any <IPaddress> 0.0.15.255 range 1417 1420
access-list 120 deny tcp any range 135 139 any
access-list 120 deny tcp any any range 135 139
access-list 120 deny tcp any any eq 445
access-list 120 deny tcp any any eq 548
access-list 120 deny tcp any any range 1025 1029
access-list 120 deny tcp any any eq 3372
access-list 120 deny tcp host <IP1> any eq 5190
access-list 120 permit tcp any <IPaddress> 0.0.15.255
access-list 120 permit icmp any <IPaddress> 0.0.15.255
access-list 120 permit ip any any
I installed the new filter, it shows up in the NVRAM configuration, but it doesn't block the traffic - the firewall on the computer I tested it on shows port 5190 being used to connect to AIM and I am able to use the AIM service.
Here's my complete access list. Maybe there's a problem with order or some other conflict. I'd like to block <IP1> both incoming and outgoing.
access-list 120 deny udp host <IP1> any eq 5190
access-list 120 permit udp any eq domain 195.134.160.0 0.0.15.255
access-list 120 permit udp any host <NS1> eq domain
access-list 120 permit udp any host <NS2> eq domain
access-list 120 permit udp any any eq ntp
access-list 120 permit udp any <IPaddress> 0.0.15.255 eq 407
access-list 120 permit udp any <IPaddress> 0.0.15.255 range 1417 1420
access-list 120 deny tcp any range 135 139 any
access-list 120 deny tcp any any range 135 139
access-list 120 deny tcp any any eq 445
access-list 120 deny tcp any any eq 548
access-list 120 deny tcp any any range 1025 1029
access-list 120 deny tcp any any eq 3372
access-list 120 deny tcp host <IP1> any eq 5190
access-list 120 permit tcp any <IPaddress> 0.0.15.255
access-list 120 permit icmp any <IPaddress> 0.0.15.255
access-list 120 permit ip any any
Change this specific access-list entry as follow:
access-list 120 deny udp host <IP1> any eq 5190 log
(please note the log at the end of the ACE).
Please, re-install the access-list.
If you are accessing the router using Telnet, enter "terminal monitor", and try to access the application.
You should receive some log messages.
Please, post these messages for us. Be careful if you are using any public address (private address does not matter).
To reset the Telnet session fromn receivig log messages enter "terminal no monitor".
access-list 120 deny udp host <IP1> any eq 5190 log
(please note the log at the end of the ACE).
Please, re-install the access-list.
If you are accessing the router using Telnet, enter "terminal monitor", and try to access the application.
You should receive some log messages.
Please, post these messages for us. Be careful if you are using any public address (private address does not matter).
To reset the Telnet session fromn receivig log messages enter "terminal no monitor".
- Thread starter
- #7
- Thread starter
- #10
Fmonteiro - Sorry, you have to bear with me. I have no training on routers and was shown how to carry out certain tasks. Beyond that, I need things spelled out. After typing "terminal monitor" at the "router#" command, I launched the service from the workstation whose port 5190 was supposed to be blocked and tried to monitor activity. Nothing showed up. What did I not do correctly?
Bob - I did apply the list to an interface. Here's part of the config info:
interface Serial0/0
description xxxxxx
ip address xxxxxx
ip access-group 120 in
Bob - I did apply the list to an interface. Here's part of the config info:
interface Serial0/0
description xxxxxx
ip address xxxxxx
ip access-group 120 in
We normally block the traffic as close as possible from the source. So, if we want to block a specific workstation from acessing a service in the external network (related to the router) we would block the traffic at the input to the router. I believe we must do a step back and try first to determine your topology and where to apply the access-list. Perhaps we could have two access-lists, one for input and another one for output. From the discussion above I am not sure I did not misunderstood your question, and I apologize for that.
- Thread starter
- #13
Thanks BuckWeet and fmonteiro.
Here's what I need: we've got a couple of workstations that are spending a lot of time doing instant messaging and I've been asked to try to block specific ports used by these services for the workstations in question. It would be wisest to block for both incoming and outgoing. An output list sounds necessary. You'll laugh, but I didn't know it existed. I thought the "in" was used to activate the filter, not to specify the direction of the activity to filter!
Here's what I need: we've got a couple of workstations that are spending a lot of time doing instant messaging and I've been asked to try to block specific ports used by these services for the workstations in question. It would be wisest to block for both incoming and outgoing. An output list sounds necessary. You'll laugh, but I didn't know it existed. I thought the "in" was used to activate the filter, not to specify the direction of the activity to filter!
Ahh. You are stuck doing the managers job. It is not easy with a router. Your access-lists are being done properly. You are just fighting a losing battle that is not yours. Put the monkey on the managers back, and give them supporting data--capture the packets via sniffers and firewall programs.
Best of luck.
bob
I just pulled this off the ISP Business website.
"If you block incoming ports above 1024, you will likely block a whole lot more than just ICQ. There is no effective way of blocking instant messenger services without a stateful packet inspection firewall. Blocking ports will not solve your problem, as there are ICQ servers out there that accept connections on any port."
"This isn't a technology problem, it's an administrative one. If people aren't allowed to use these services, enforcement via logs might be a better option. After a few folks are busted, others will simply stop."
[BL concurred] "You would be better advised to treat this as a staff policy issue rather than attempting to block it-unless they only want HTTP and mail, in which case it would be easier to simply block everything except the ports which those require. Don't forget, also, that many software packages have anti-firewall features which will allow them to be used on ports under 1024."
Best of luck.
bob
I just pulled this off the ISP Business website.
"If you block incoming ports above 1024, you will likely block a whole lot more than just ICQ. There is no effective way of blocking instant messenger services without a stateful packet inspection firewall. Blocking ports will not solve your problem, as there are ICQ servers out there that accept connections on any port."
"This isn't a technology problem, it's an administrative one. If people aren't allowed to use these services, enforcement via logs might be a better option. After a few folks are busted, others will simply stop."
[BL concurred] "You would be better advised to treat this as a staff policy issue rather than attempting to block it-unless they only want HTTP and mail, in which case it would be easier to simply block everything except the ports which those require. Don't forget, also, that many software packages have anti-firewall features which will allow them to be used on ports under 1024."
Create another access-list and assign it as input to the ethernet interface, for example:
access-list 1xx deny udp host <IP1> any eq 5190 log
access-list 1xx deny tcp host <IP1> any eq 5190 log
access-list 1xx permit ip any any
I am filtering udp and tcp just to make sure. The log option will log some messages for us.
Assign this access-list to the ethernet interface:
interface ethernet N
ip access-group 1xx in
Lets try this first then we could continue adding statements to the access-list as needed.
access-list 1xx deny udp host <IP1> any eq 5190 log
access-list 1xx deny tcp host <IP1> any eq 5190 log
access-list 1xx permit ip any any
I am filtering udp and tcp just to make sure. The log option will log some messages for us.
Assign this access-list to the ethernet interface:
interface ethernet N
ip access-group 1xx in
Lets try this first then we could continue adding statements to the access-list as needed.
- Thread starter
- #16
fmonteiro - Thanks, the access list works fine when assigned to the ethernet interface - I was unable to connect to AIM from the IP number used in the access list. However, I still don't see any activity when I type "terminal monitor" at the "router#" line. I did include the log option in the access list. Should I be doing something else?
Is there any point in creating an output list?
Bob - I know it's not easy with a router, but most products are Windows server and domain based : we've got both PCs and Macs. I know that some IM services even use port 80, which we obviously can't block. I'll block what I can. Also, we're not in the US. Employee "privacy" is very well protected here and employers do not have the right to spy on employee activity. We don't want to single anyone out, just sort of silently block their access to services that they shouldn't be using during worktime. They can't really come back to us and complain that they can no longer use their IM or P2P services.
Is there any point in creating an output list?
Bob - I know it's not easy with a router, but most products are Windows server and domain based : we've got both PCs and Macs. I know that some IM services even use port 80, which we obviously can't block. I'll block what I can. Also, we're not in the US. Employee "privacy" is very well protected here and employers do not have the right to spy on employee activity. We don't want to single anyone out, just sort of silently block their access to services that they shouldn't be using during worktime. They can't really come back to us and complain that they can no longer use their IM or P2P services.
About the log activity:
Do a "sh log" command. You should have a output like this one:
Router#sh log
Syslog logging: enabled (0 messages dropped, 668 flushes, 0 overruns)
Console logging: level debugging, 1662 messages logged
Monitor logging: level debugging, 0 messages logged
Buffer logging: disabled
Trap logging: level informational, 995 message lines logged
Router#
Check if the console logging is enable (it should appear as above).
If it is unable, enter in config mode and enter "logging console".
If it continues not working please post the "sh log" output.
Sorry I did not understand your last question (my fault) "Is there any point in creating an output list?". Could you be more specific?
Do a "sh log" command. You should have a output like this one:
Router#sh log
Syslog logging: enabled (0 messages dropped, 668 flushes, 0 overruns)
Console logging: level debugging, 1662 messages logged
Monitor logging: level debugging, 0 messages logged
Buffer logging: disabled
Trap logging: level informational, 995 message lines logged
Router#
Check if the console logging is enable (it should appear as above).
If it is unable, enter in config mode and enter "logging console".
If it continues not working please post the "sh log" output.
Sorry I did not understand your last question (my fault) "Is there any point in creating an output list?". Could you be more specific?
- Thread starter
- #18
Here's my output:
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 628 messages logged
Monitor logging: disabled
Trap logging: level informational, 632 message lines logged
About the output list, do I understand correctly that the input list only works on incoming packets? If so, do I need to block outgoing packets or is the incoming sufficient?
Syslog logging: enabled (0 messages dropped, 0 flushes, 0 overruns)
Console logging: level debugging, 628 messages logged
Monitor logging: disabled
Trap logging: level informational, 632 message lines logged
About the output list, do I understand correctly that the input list only works on incoming packets? If so, do I need to block outgoing packets or is the incoming sufficient?
When entering/exiting in config mode do you receive a %SYS-5-CONFIG_I message (as the example that follows)?
ras#ter monitor
ras#
ras#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ras(config)#
ras#
%SYS-5-CONFIG_I: Configured from console by cisco on vty0 (129.222.x.y)
ras#
About the incoming access-list it really depends on what you want to do. In this access-list we are working it is enough to block the incoming since, as I understood, the communication is only from the inside to the outside network. This is the idea: you need to determine in which direction you intend to block the traffic. For example, with www, you could permit only connections established from the inside to the Internet and you would block connections from the Internet (but you would permit responses for your own connections).
As you remember in our access-list we are blocking both tcp
and udp protocols. We still need the log messages to define which protocol we are using.
ras#ter monitor
ras#
ras#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ras(config)#
ras#
%SYS-5-CONFIG_I: Configured from console by cisco on vty0 (129.222.x.y)
ras#
About the incoming access-list it really depends on what you want to do. In this access-list we are working it is enough to block the incoming since, as I understood, the communication is only from the inside to the outside network. This is the idea: you need to determine in which direction you intend to block the traffic. For example, with www, you could permit only connections established from the inside to the Internet and you would block connections from the Internet (but you would permit responses for your own connections).
As you remember in our access-list we are blocking both tcp
and udp protocols. We still need the log messages to define which protocol we are using.
- Thread starter
- #20
No, I don't receive that message, nor do I recall ever having received it. Here's what I got:
ras#ter monitor
ras#
ras#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ras(config)#
ras(config)#^Z
ras#
The personal firewall on the workstation logs TCP Port 5190 when I access the service.
Before starting, does "in" in an access-group command signify incoming or inside? Since I'm trying to block messaging, which is two-way, I thought I might need to filter in both directions. I'll have to check what happens if someone outside sends a message when the recipient is not logged on to the IM service. I'd like to be sure the recipient does not receive notification of an incoming message, or the message itself, even if he can't return it.
ras#ter monitor
ras#
ras#conf t
Enter configuration commands, one per line. End with CNTL/Z.
ras(config)#
ras(config)#^Z
ras#
The personal firewall on the workstation logs TCP Port 5190 when I access the service.
Before starting, does "in" in an access-group command signify incoming or inside? Since I'm trying to block messaging, which is two-way, I thought I might need to filter in both directions. I'll have to check what happens if someone outside sends a message when the recipient is not logged on to the IM service. I'd like to be sure the recipient does not receive notification of an incoming message, or the message itself, even if he can't return it.
- Status
Similar threads
- Locked
- Question
