[Cisco] UDP lijkt ACLs te negeren

[Zoetjuh]

Al een tijd ben ik bezig om bij ons de ACL regels te optimaliseren. Ik heb twee omgevingen welke anders in elkaar zitten.

Op de ene omgeving (een internetverbinding connected via een dialer) lukt het me netjes om UDP verkeer te blocken. Op een andere omgeving, waar ik via BGP een verbinding met internet heb (en het subnet dat ik announce heb opgedeeld in VLANs) lukt me dit niet.

Ik test de firewall met nmap (nmap -sS -sU -T4 -A -v <host>)

Mjin ACL/config van de router waar het niet lukt, ziet er zo uit:

code:

interface Vlan2116
 ip address <GW IP> 255.255.255.240
 ip access-group 121 out
 no ip unreachables
 no ip route-cache cef
 no ip route-cache
 no ip mroute-cache
!

access-list 121 remark =B===========B=
access-list 121 permit tcp any any established
access-list 121 remark -----------------------------------------1
access-list 121 remark Protocol: Common (UDP)
access-list 121 permit udp host <FWD DNS SERVER> eq domain any gt 1024
access-list 121 permit udp any host <MY SERVER> eq domain
access-list 121 permit icmp host <FWD DNS SERVER> any fragments
access-list 121 deny   icmp any any fragments
access-list 121 permit icmp any any echo
access-list 121 permit icmp any any echo-reply
access-list 121 permit icmp any any host-unreachable
access-list 121 remark -----------------------------------------2
access-list 121 remark Protocol: VPN (TCP)
access-list 121 permit gre any any
access-list 121 permit tcp any host <MY SERVER> eq 1723
access-list 121 remark -----------------------------------------3
access-list 121 remark Protocol: RDP (TCP)
access-list 121 permit tcp any host <MY SERVER> eq 3389
access-list 121 remark -----------------------------------------4
access-list 121 remark Protocol: WEB (TCP)
access-list 121 permit tcp any host <MY SERVER> eq www
access-list 121 permit tcp any host <MY SERVER> eq 443
access-list 121 remark -----------------------------------------5
access-list 121 remark Protocol: SMTP (TCP)
access-list 121 permit tcp any host <MY SERVER> eq smtp
access-list 121 remark -----------------------------------------6
access-list 121 remark Protocol: FTP (TCP)
access-list 121 permit tcp host <SUPPLIER SRV> eq ftp-data any
access-list 121 permit tcp any host <MY SERVER> range 5001 5500
access-list 121 permit tcp any host <MY SERVER> eq ftp-data
access-list 121 permit tcp any host <MY SERVER> eq ftp
access-list 121 remark =E===========E=

Deze ACL lijkt me gewoon in orde; maar gek genoeg krijg ik onderstaande resultaten via nmap. Zoals gezegd, op een andere omgeving waar ik via een dialer connect (en geen VLANs gebruik) zijn onderstaande poorten wel gewoon "echt" dicht.

67/udp open|filtered dhcps
135/udp open|filtered msrpc
136/udp open|filtered profile
137/udp open|filtered netbios-ns
138/udp open|filtered netbios-dgm
139/udp open|filtered netbios-ssn
445/udp open|filtered microsoft-ds

De server(s) die ik scan zijn W2K3 servers.

Overigens, wanneer ik een VACL aanmaak, dan gaat het wel goed. Nu kan ik dat altijd als work-around gebruiken, echter werken VACLs ook op verkeer binnen het VLAN (en router ACLs niet). Het liefst heb ik dus een werkelijke router ACL. Als router/switch gebruik ik een C3750.

Heeft iemand ook maar enig idee wat hiervan de oorzaak kan zijn?

[Kabouterplop01]

wow interessant. Die ACL lijkt me ook in orde, hoewel ik denk dat er ook een ACL inbound moet staan. Echter waarom je überhaupt antwoord krijgt is apart!
wellicht moet er in zo'n ACL wel expliciet staan:

code:

access-list 121 remark =B===========B=
access-list 121 permit tcp any any established
access-list 121 remark -----------------------------------------1
access-list 121 remark Protocol: Common (UDP)
access-list 121 permit udp host <FWD DNS SERVER> eq domain any gt 1024
access-list 121 permit udp any host <MY SERVER> eq domain
access-list 121 deny udp any any log ! om even te monitoren!
etc.

Wat ik me niet kan voorstellen!!
Of ben je in hetzelfde VLAN aan het scannen?(Zit je in het zelfde vlan als de hosts?)

[ Voor 68% gewijzigd door Kabouterplop01 op 07-08-2011 23:23 ]

[CyBeR]

Dat lijstje poorten komt vrij precies overeen met een lijstje dat heel veel ISPs blokkeren. Weet je zeker jouw ISP dat ook niet doet?

[Zoetjuh]

Hmmm, de logging er maar eens bijgepakt. Ik heb vanmorgen vanaf mijn Ziggo kabeltje thuis (dus buiten bovengenoemd VLAN) nog een nmap gedaan (83.86.x.x). Dat was een reeks UDP packets vanaf poort 54835.

Interessant genoeg zijn er ook "anderen" die er af en toe UDP verkeer heen sturen; maar ook dat lijkt wel netjes door de filter tegengehouden.

001826: .Aug 8 07:26:31: %SEC-6-IPACCESSLOGP: list 121 denied udp 83.86.x.x(54835) -> <SERVER IP>(3457), 1 packet
002148: .Aug 8 07:36:20: %SEC-6-IPACCESSLOGP: list 121 denied udp 217.115.x.x(137) -> <ANDER SERER IP IN ZELFE SUBNET>(137), 1 packet

Wat ik alleen vreemd vindt, is dat nmap de UDP poorten op de 2003 server wel weergeeft als open|filtered; terwijl hij dat op een 2008R2 server niet doet (beide in het zelfde VLAN/subnet). Ook weet ik dat een tijdje terug iemand met een Metasploit op een vergelijkbare 2003 server er wel doorheen zou komen en een remote command zou hebben kunnen starten.

Edit: Ik zal straks vanaf hier ook nog een test doen en kijken wat daar uit komt.

[ Voor 4% gewijzigd door Zoetjuh op 08-08-2011 10:32 ]

[serkoon]

Voor UDP-poorten geldt dat Nmap kan achterhalen of de poort gesloten of open is door het verkrijgen van een packet. Een ICMP-packet zorgt ervoor dat Nmap zal zeggen 'closed', een UDP-packet 'open'. Krijgt nmap niks, dan is het 'open|filtered', hetgeen wil zeggen dat de poort ofwel open is, ofwel filtered.

Als je firewall dus inkomende UDP-packets dropt en er geen ICMP-packet voor terugstuurt, zal nmap voor alle poorten 'open|filtered' gaan roepen. Ik verwacht dus dat je rules gewoon werken.

[Zoetjuh]

Dat is nu precies het gene wat ik zo vreemd vindt. Wanneer de Cisco al het UDP verkeert blocked; moet het niet uit maken of er een machine achter zit, of dat daar een UDP-poort open staat of niet. Immers, in alle gevallen moet het resultaat het zelfde zijn wanneer al het verkeer daadwerkelijk wordt gefitlered.

Ik moet zeggen dat ik het daarom dus nog steeds niet vertrouw; want de resultaten van nmap zijn nu afhankelijk van de machine die er achter hangt..

[Eagle Creek]

want de resultaten van nmap zijn nu afhankelijk van de machine die er achter hangt..

Welke zijn dat dan? Closed?
Want dat kan ik zo niet uit je bericht opmaken.

[Zoetjuh]

Ik heb me vergist; ook op een 2008R2 server gaf hij de zelfde UDP poorten aan als open|filtered.

Echter, wanneer ik een VACL toepas, krijg ik wel volledige closed poorten (en is de UDP scan ook vrij snel klaar, namelijk in 15 seconden ipv 10 minuten). Enig idee waarom dit zo anders is / wel werkt?

[ Voor 9% gewijzigd door Zoetjuh op 09-08-2011 18:21 ]

[Kabouterplop01]

Volgens de wiki van VACL staat er:

VLAN Access Control Lists (VACLs) provide access control for all packets that are bridged within a VLAN or that are routed into or out of a VLAN. Unlike regular Cisco IOS access control lists that are configured on router interfaces and applied on routed packets only, VACLs apply to all packets.

Is dat een antwoord?
(Verklaart niet waarom je filtered/open melding krijgt, vanaf je "buiten" lijn waarmee je test, of toch juist wel?)
vreemd edoch interessant!

[zenith]

Wat serkoon zegt inderdaad en ik denk dat je 'no ip unreachables' nog moet configureren op je dialer/outside interface. Verder zou ik dit met een inbound acl blocken?

[ Voor 16% gewijzigd door zenith op 09-08-2011 22:06 ]

[Barreljan]

Zoals de rest zegt; inbound werkt een stuk beter, controleer wel of dan je source/dest. nog kloppen in de accesslist. Even simpel: INbound is het netwerk van vlan 2116 IN. Dus de source any kan Internet zijn en destination je server/services.

offtopic:
waarom heb je CEF uitstaan ? Specifieke reden daartoe gehad? Cisco Express Forwarding brengt een hoop snelheid met zich mee. De router/l3 switch is ook minder druk als dit wel aanstaat.

even gauw kopipasta:
conf t:
ip cef
int vlan 2116
ip route-cache cef
ip route-cache

Uitzetten van CEF is vaak nadeliger.

[ Voor 27% gewijzigd door Barreljan op 10-08-2011 17:43 ]

[Zoetjuh]

Excuses voor de late reacite; maar de afgelopen week met wat andere dingen bezig geweest.
Ik ben even met jullie suggesties aan de slag gegaan:

@Cyber
Eens.. alleen wanneer ik de scan richting een andere host in een ander VLAN uitvoer (waar we een VACL gebruiken) dan geeft nmap niet aan dat de poorten open staan; dus ik *vermoed* ze niet door de ISP worden gefiltered

@Kabouterplop01
Dat is dus inderdaad het wazige. Ik heb ergens het vermoeden dat de packets niet allemaal gerouteerd worden op de C3750; anders moeten ze door de ACL heen; en dat lijken ze gewoon niet te doen. Bij het toepassen van een VACL worden ze wel geblocked; dus tja, zou de implementatie van BGP dit misschien veroorzaken..?

Om wat meer info te geven, de host die ik wil nmappen zit weer op een andere switch aangesloten als de C3750. Via een trunk wordt verkeer naar die andere switch geschopt. Verder staat op de C3750 ook het commando "ip route <subnet dat we via BGP announcen> Null0".
Zouden deze twee zaken er dan inderdaad voor zorgen dat het verkeer als switched verkeer wordt gezien ipv routed verkeer?

@dmdb en Barreljan
De ip cef zaken zijn bij deze ook ingeschakeld. De reden om ze uit te zetten was puur om potentiele oorzaken uit te sluiten (misschien dat dit er niets mee temaken zou kunnen hebben, maar toch).
Ik heb nu ook de volgende ACL-in op het VLAN geplaatst (ofwel voor verkeer van binnen naar buiten), maar krijg nog steeds de zelfde nmap restulaten:

code:

access-list 141 remark =B===========B=
access-list 141 permit tcp any any established
access-list 141 remark -----------------------------------------1
access-list 141 remark Protocol: Common (UDP)
access-list 141 permit udp any host <FWD DNS SERVER> eq domain
access-list 141 permit udp host <MY SERVER> eq domain any gt 1024
access-list 141 deny   udp any any log
access-list 141 permit icmp any host <FWD DNS SERVER> fragments
access-list 141 deny   icmp any any fragments
access-list 141 permit icmp any any echo
access-list 141 permit icmp any any echo-reply
access-list 141 permit icmp any any host-unreachable
access-list 141 remark -----------------------------------------2
access-list 141 remark Protocol: VPN (TCP)
access-list 141 permit gre any any
access-list 141 remark =E===========E=

[Kabouterplop01]

Om wat meer info te geven, de host die ik wil nmappen zit weer op een andere switch aangesloten als de C3750. Via een trunk wordt verkeer naar die andere switch geschopt. Verder staat op de C3750 ook het commando "ip route <subnet dat we via BGP announcen> Null0".
Zouden deze twee zaken er dan inderdaad voor zorgen dat het verkeer als switched verkeer wordt gezien ipv routed verkeer?

Dat lijkt me heel raar (BGP is TCP poortje 179 en laag 3) dat de BGP er iets mee te maken heeft, maar verkeer over de trunk is wel switched. However de VACL staat op de L3 interface (Hence laag 3) van het VLAN. Wellicht heeft Trailblazer hier een goede kijk op.. (Heb hem al een tijdje niet gezien)

en die ip route naar null0 lijkt me verkeer dat de bittenbak in wordt geduwd.(Die wordt ergens anders aamgesproken lijkt me, anders zou je verkeer kwijtraken)

[ Voor 31% gewijzigd door Kabouterplop01 op 14-08-2011 11:58 ]

[Kabouterplop01]

Barreljan schreef op woensdag 10 augustus 2011 @ 17:40:
Zoals de rest zegt; inbound werkt een stuk beter, controleer wel of dan je source/dest. nog kloppen in de accesslist. Even simpel: INbound is het netwerk van vlan 2116 IN. Dus de source any kan Internet zijn en destination je server/services.

even offtopic: Dit kun je heel makkelijk scheiden door alleen het subnet van je server services toegang te geven, dan sluit je internet uit.

[Zoetjuh]

Dank voor jullie ideëen/suggesties.

Ik blijf het vreemd vinden, maar ik denk dat ik maar gewoon de VACL's verder ga implementeren.