Toon posts:

cisco ISDN ACL mcafee autoupdate werkt niet

Pagina: 1
Acties:
  • 219 views sinds 30-01-2008
  • Reageer

Verwijderd

Topicstarter
Ik heb in mijn ACL de ftp en ftp-data poorten open staan. Ook heb ik de udp poorten 20 en 21 open gezet, maar deze worden niet gebruikt. (sh access-list ) geeft geen hits.

Wanneer ik de autoupdate start wordt en ik bekijk mijn logs dan zie ik dat er keurig "interesting" traffic naar buiten gaat en er wordt keurig ingebeld met ISDN. Ik krijg diverse hits op de ftp en ftp-data acl regels, maar uiteindelijk werkt het niet.

De beide standaard methoden voor updaten van mcafee (ftp en http) werken niet. De HTTPS poort heb ik ook open gezet voor het geval die nodig zou zijn voor http uidaten maar dat werkt ook neit.

Hoe krijg ik het voor elkaar via een cisco ISDN router mijn mcafee te updaten?!? Ik heb veel gezocht op internet, maar ik kan er neit veel over vinden.

een aantal regels uit het updatevenster...

update wordt gestart,
bezig met initialiseren van de update,
controleren van catalog.z
bezig met downloaden van pkgcatalog.z
bezig emt starten van de update van DAT
Update DAT vooraf melden
virusscan heeft de huidige update verworpen
bijwerken naar 4.0.4393 is mislukt.
het bijwerken is voltooid.

Het lijkt dus of er een verbinding is, de updatefile wordt gevonden, maar hij wordt niet gedownload of iets dergelijks.

[ Voor 25% gewijzigd door Verwijderd op 20-09-2004 10:02 ]


Verwijderd

Mischieen eens een log op de laatste impliciete deny regel van je access list ?

Gebruike je cbac ?

mischien je config even posten, dat bespaart een boel vragen

[ Voor 25% gewijzigd door Verwijderd op 20-09-2004 10:10 ]


Verwijderd

Topicstarter
Verwijderd schreef op 20 september 2004 @ 10:09:
Mischieen eens een log op de laatste impliciete deny regel van je access list ?

Gebruike je cbac ?

mischien je config even posten, dat bespaart een boel vragen
cbac..geen idee wat dat inhoudt. Ik zal mijn config zo even posten.

Verwijderd

Topicstarter
ik maak via ISDN verbinding emt een proxybak op een andere lokatie. vandaaruit kan ik via een snelle verbinding naar buiten. Op die bak staat ftp open, gebruikers op die lokatie kunnen namelijk wel updaten.

Current configuration:
!
version 12.0
no service pad
service timestamps debug datetime localtime show-timezone
service timestamps log datetime localtime show-timezone
service password-encryption
service udp-small-servers
service tcp-small-servers
!
hostname routerb
!
enable secret 5 xx
!
username router password 7 xx
username wiel password 7 xx
!
!
!
!
clock timezone MET -1
clock summer-time MET recurring last Sun Mar 2:00 last Sun Oct 3:00

pots country NL
pots encoding alaw
pots tone-source local
pots disconnect-supervision osi
pots dialing-method overlap
pots line-type type1
pots ringing-freq 25Hz
pots distinctive-ring-guard-time 1000
pots silence-time 1
ip subnet-zero
!
ip host router 192.168.1.1
isdn switch-type basic-net3
isdn tei-negotiation first-call
!
call-history-mib retain-timer 500
call-history-mib max-size 500
!
process-max-time 200
!
interface Ethernet0
ip address 192.168.11.1 255.255.255.0
no ip directed-broadcast
!
interface BRI0
description Locatie x
no ip address
no ip directed-broadcast
encapsulation ppp
dialer pool-member 1
isdn switch-type basic-net3
ppp authentication chap
!
interface Dialer0
description Inbel verbinding Support
ip address 192.168.200.1 255.255.255.0
no ip directed-broadcast
encapsulation ppp
dialer remote-name wiel
dialer idle-timeout 3600
dialer pool 1
dialer-group 1
peer default ip address pool wiel
ppp authentication chap
!
interface Dialer1
description Verbinding naar xxx
ip unnumbered Ethernet0
no ip directed-broadcast
encapsulation ppp
ip tcp header-compression passive
no keepalive
dialer remote-name router
dialer idle-timeout 180
dialer string xxxxxx
dialer hold-queue 5
dialer pool 1
dialer-group 2
no cdp enable
ppp authentication chap
!
ip local pool wiel 192.168.200.2 192.168.200.10
no ip http server
ip classless
no ip forward-protocol udp domain
no ip forward-protocol udp time
no ip forward-protocol udp netbios-ns
no ip forward-protocol udp netbios-dgm
no ip forward-protocol udp tacacs
ip route 0.0.0.0 0.0.0.0 Dialer1 permanent
!
access-list 100 permit tcp any any
access-list 100 permit udp any any
access-list 100 permit icmp any any
access-list 100 deny ip any any log
access-list 110 permit tcp any any eq 1494
access-list 110 permit tcp any any eq 1604
access-list 110 permit udp any any eq 1604
access-list 199 permit tcp any any eq www
access-list 199 permit tcp any any eq ftp
access-list 199 permit tcp any any eq ftp-data
access-list 199 permit udp any any eq 20
access-list 199 permit udp any any eq 21
access-list 199 permit tcp any any eq 443
access-list 199 permit tcp any any eq telnet
access-list 199 permit tcp any any eq pop3
access-list 199 permit tcp any any eq smtp
access-list 199 permit tcp any any eq 1494
access-list 199 permit tcp any any eq 1604
access-list 199 permit udp any any eq 1604
access-list 199 permit tcp any any eq 5631
access-list 199 permit udp any any eq 5632
access-list 199 permit tcp any any established
priority-list 1 interface Ethernet0 medium
priority-list 1 interface Dialer1 medium
dialer-list 1 protocol ip list 100
dialer-list 2 protocol ip list 199
banner motd ^C

Waarschuwing !!!


xxxx


^C
!
line con 0
password 7 xxxx
login
transport input telnet
stopbits 1
line vty 0 4
password 7 xxxx
login
!
end

routerb#

Verwijderd

Topicstarter
de site van mcafee lijkt er nu uit te liggen..wellicht heeft het er iets mee te maken..het heeft echter nog niet eerder gewerkt dus er zit toch iets scheef...

Verwijderd

Topicstarter
Ik krijg nu de site werkt weer oa de volgende meldingen tijdens het updaten:


Er is een fout opgetreden bij het downloden van het bestand SiteStat.xml.
Update DAT vooraf melden.
Virusscan heeft de huidige update verworpen.
Het bijwerken naar versie 4.0.4393 is mislukt.
het bijwerken is voltooid.

Hij ziet de file, probeert te achterhalen waar hij hem vandaan kan halen middels sitestat.xml, dit bestand kan hij niet vinden en er wordt dus ook niet geupdate..
----
VirusScan Enterprise 7.0 uses the SITESTAT.XML file to determine the "health" of the site. If the file is present, VirusScan will continue with the update. If the file is not present, VirusScan will not update from the site.
----

[ Voor 90% gewijzigd door Verwijderd op 20-09-2004 15:09 ]


Verwijderd

Maak alsjeblieft gebruik van de edit-knop. Vier posts onder elkaar vind ik echt teveel van het goede.

Afbeeldingslocatie: http://gathering.tweakers.net/global/templates/got/images/icons/edit.gif <- dat is 'm.

Verwijderd

Je gebruikt geen cbac maar gewone access-list gekoppeld aan je dialer-list.

En als je nu eens

access-list 199 deny ip any any log

toevoegd en vervolgens even met vty (vergeet terminal monitor niet) gaat kijken op de pc waar le dan gaat updaten ?

[ Voor 55% gewijzigd door Verwijderd op 20-09-2004 15:57 ]


Verwijderd

Topicstarter
Verwijderd schreef op 20 september 2004 @ 15:53:
Je gebruikt geen cbac maar gewone access-list gekoppeld aan je dialer-list.

En als je nu eens

access-list 199 deny ip any any log

toevoegd en vervolgens even met vty (vergeet terminal monitor niet) gaat kijken op de pc waar le dan gaat updaten ?
Heb die regel teogevoegd, term mon staat aan -> terminal allready monitors. Ik zie alleen niets voorbij komen als ik autoupdate start

[ Voor 32% gewijzigd door Verwijderd op 20-09-2004 16:18 ]


Verwijderd

Verwijderd schreef op 20 september 2004 @ 16:11:
[...]


Heb die regel teogevoegd, term mon staat aan -> terminal allready monitors. Ik zie alleen niets voorbij komen als ik autoupdate start
Laat hij dan ook geen hits zien met show ip access-lists ?

[ Voor 20% gewijzigd door Verwijderd op 20-09-2004 16:22 ]


Verwijderd

Topicstarter
ja, die router heeft een ip route over een dialer. Aan deze dialer hangt de onderstaand e list. Nu ik hem zo zie staan valt mij op dat de ftp en ftp data poorten hier niet in staan....volgens mij gaat er bij mij een lampje branden nu...

access-list 199 permit tcp any any eq 1604
access-list 199 permit tcp any any
access-list 199 permit tcp any any eq telnet
access-list 199 permit tcp any any eq pop3
access-list 199 permit tcp any any eq smtp
access-list 199 permit tcp any any eq 1494
access-list 199 permit udp any any eq 1604
access-list 199 permit tcp any any eq 5631
access-list 199 permit udp any any eq 5632
access-list 199 permit tcp any any established
access-list 199 permit icmp any any echo
access-list 199 permit icmp any any echo-reply
access-list 199 permit tcp any host 192.168.250.0 eq smtp


/ik zal deze keer op vriendelijk verzoek mijn post editen...
edit 1:

ik heb in de list op de andere router de ftp en ftp-data poort gepermit..maar geen resultaat. Ook geen hits op deze regels als ik de update start.

edit 2:
show ip access-l = show access-l 199 ...zelfde resultaat, beiden geen matches

edit 3:

even een voetnootje..een stuk hoger in de list staat permit tcp any any, dat verklaard waarom de ftp en ftp-data regel geen matches geven..denk ik.. :|

[ Voor 29% gewijzigd door Verwijderd op 20-09-2004 16:56 ]


Verwijderd

Topicstarter
nog iemand suggesties? Ik heb eens geprobeerd mij prive ftp server (eigen domein) te bereiken, maar daar kom ik niet op. ook downloaden van een ftp server van bv ipswitch werkt neit, terwijl dat met mijn adsl verbinding wel gewoon werkt. Echt bizar, hoe moeilijk kan zoiets nu zijn...

als iemand nog ideeeen heeft? Kan eventueel de config van de andere router posten, maar die is 13 pagina's lang dus dat lijkt me niet zo'n strak plan.

Verwijderd

voeg dan oom op die router eens een deny ip any any log toe als laatste en volg de eerder opgegeven methode.

Maar vanwaar access-listen aan twee kanten ?

Vertrouwen de 2 partijen elkaar echt niet ?

als je van x naar y poort 21 gaat moet je voor terug
y poort 21 naar x permitten ??

nu doe je daar ook y naar x 21 en dat is dus geen match.

ik denk dat je dus met in deze post eerstgenoemde procedures keurig de deny's gaat zien omdat je je acl niet inverteerd.

[ Voor 72% gewijzigd door Verwijderd op 21-09-2004 11:24 ]


Verwijderd

Topicstarter
access-list 199 permit tcp any any

die vangt dan toch ook tcp verkeer op poort 21 af? ik heb ftp en ftp-data zelf later nog toegevoegd, maar dat werkt niet..althans, ik krijg geen matches op die list aangezien alle hits vallen op bovengenoemde regel.

ik zal ook wel eits verkeerd doen met access-list 199 deny ip any any log, want er komt niets voorbij. Term mon staat aan.

/edit:

op de andere router kreeg ik nu het volgende:

list 199 denied udp 192.168.11.2(1582) -> 192.168.1.15(53), 1 packet99
1.15 is mijn dns server. 11.2 si mijn pc.

[ Voor 19% gewijzigd door Verwijderd op 21-09-2004 11:45 ]


Verwijderd

Verwijderd schreef op 21 september 2004 @ 11:41:
access-list 199 permit tcp any any

die vangt dan toch ook tcp verkeer op poort 21 af? ik heb ftp en ftp-data zelf later nog toegevoegd, maar dat werkt niet..althans, ik krijg geen matches op die list aangezien alle hits vallen op bovengenoemde regel.

ik zal ook wel eits verkeerd doen met access-list 199 deny ip any any log, want er komt niets voorbij. Term mon staat aan.
Idd, even vlot gekeken en daar overheen gekeken daar dat niet echt logisch is omadat alle tcp permits onder dat statement niet gebruikt worden.

maak gewoon even access-listen met een permit ip any any en hang deze aan de dialer-lists, als dit werkt weet je zeker dat het in je acl zit.

en vraag je ook even af of access-listen aan 2 kanten noodzakelijk zijn.

Verwijderd

Topicstarter
helaas zit ik in een live-situatie waarin ik moet uitkijken dat ik geen verbindingen verbreek. De "andere" router is een centrale router waar zo'n 15 andere routers verbinding mee maken.

over 2 access-lists, ik heb het niet opgezet en zoals je miss al hebt gemerkt is mijn kennis niet zodanig groot dat ik daar een goed oordeel over kan vellen. Ik zou liever de boel laten zo het is en het werkend krijgen. Misschien dat ik in de toekosmt de boel nog een keer wil herzien, maar voor nu vind ik die kluif een beetje te groot.

aan mijn kant kan ik wel een andere access-list neerzetten omdat dit een testrouter is. daar zal ik permit tcp any any en ip any any in zetten. Kijken wat dat doet.
Mijn acl ziet er nu uit als volgt:

Extended IP access list 100
permit tcp any any (136 matches)
permit udp any any (2 matches)
permit icmp any any (8 matches)
permit ip any any

Als ik verbinding probeer te maken met mijn ftpserver krijg ik een hele rij interesting traffic gevolgd door onderstaande meldingen:
*Mar 1 02:05:58 MET: BRI0 DDR: sending broadcast to default destination -- fail
ed, not connected
*Mar 1 02:05:58 MET: Dialer0 DDR: cdp, 286 bytes, outgoing uninteresting (no li
st matched)

aan de acl op de hoofdrouter heb ik
permit ip any any toegevoegd. Maar ik krijg geen matches.

[ Voor 90% gewijzigd door Verwijderd op 21-09-2004 13:33 ]


Verwijderd

Verwijderd schreef op 21 september 2004 @ 11:54:
helaas zit ik in een live-situatie waarin ik moet uitkijken dat ik geen verbindingen verbreek. De "andere" router is een centrale router waar zo'n 15 andere routers verbinding mee maken.

over 2 access-lists, ik heb het niet opgezet en zoals je miss al hebt gemerkt is mijn kennis niet zodanig groot dat ik daar een goed oordeel over kan vellen. Ik zou liever de boel laten zo het is en het werkend krijgen. Misschien dat ik in de toekosmt de boel nog een keer wil herzien, maar voor nu vind ik die kluif een beetje te groot.

aan mijn kant kan ik wel een andere access-list neerzetten omdat dit een testrouter is. daar zal ik permit tcp any any en ip any any in zetten. Kijken wat dat doet.
Mijn acl ziet er nu uit als volgt:

Extended IP access list 100
permit tcp any any (136 matches)
permit udp any any (2 matches)
permit icmp any any (8 matches)
permit ip any any

Als ik verbinding probeer te maken met mijn ftpserver krijg ik een hele rij interesting traffic gevolgd door onderstaande meldingen:
*Mar 1 02:05:58 MET: BRI0 DDR: sending broadcast to default destination -- fail
ed, not connected
*Mar 1 02:05:58 MET: Dialer0 DDR: cdp, 286 bytes, outgoing uninteresting (no li
st matched)

aan de acl op de hoofdrouter heb ik
permit ip any any toegevoegd. Maar ik krijg geen matches.
Ik denk dat het beter is dat je eerst even de exacte werking van access-listen door krijgt dan kun je het voor je zelf makkelijker beredeneren.

het eerste statement van een access-list dat matched doet de voorgaande bewerking (permit of deny) vanuit deze beredenering moet je dus ook je access listen bekijken en dan zie je dat er zoizo al niet veel logica in de bestaande access-listen zit.

permit ip any any

is namelijk het zelfde als

permit tcp any any
permit udp any any

zowel broadcasten als cdp zijn datalink zaken en zijn inderdaad unontresting traffic omdat je dialer / access list alleen layer 3 verkeer definieert.

Ik zou zelf aan beide zeiden de intresting traffic ip definieren en dan nog eens kijken.

Als het dan nog fout gaat weet je dat het probleem niet op transport layer zit.

[ Voor 16% gewijzigd door Verwijderd op 22-09-2004 10:16 ]


Verwijderd

Topicstarter
ok huidige situatie:

Acl op eigen router:

Ik heb hier dus een nieuwe list gemaakt, gewoon om te testen. Ik begrijp dat het niet logisch is opgebouwd, maar hij is slechts om even te testen.

routerb#sh access-l 100
Extended IP access list 100
permit tcp any any (2022 matches)
permit udp any any (18 matches)
permit icmp any any (8 matches)
permit ip any any

Dit korte lijstje vervangt de originele lijst welk er nu als volgt uit ziet en dus NIET actief is nu:

Extended IP access list 199
permit tcp any any eq www (2818 matches)
permit tcp any any eq 443 (6 matches)
permit tcp any any eq pop3
permit tcp any any eq smtp
permit tcp any any eq 1494
permit tcp any any eq 1604
permit tcp any any eq 5631
permit tcp any any eq ftp (107 matches)
permit tcp any any eq ftp-data
permit tcp any any eq telnet (2702 matches)
permit udp any any eq 1604
permit udp any any eq 5632
permit tcp any any established
deny tcp any any log
deny ip any any log (43 matches)

accesslist op de hoofdrouter:

router#sh access-l 199
Extended IP access list 199
permit tcp any any eq 1604 (11 matches)
permit tcp any any (46102 matches) *geen idee wie dit verzonnen heeft..maar goed, niet zo belangrijk nu
permit tcp any any eq telnet
permit tcp any any eq pop3
permit tcp any any eq smtp
permit tcp any any eq 1494
permit udp any any eq 1604
permit tcp any any eq 5631
permit udp any any eq 5632
permit tcp any any established
permit icmp any any echo (11 matches)
permit icmp any any echo-reply (5 matches)
permit tcp any host 192.168.250.0 eq smtp
permit tcp any any eq ftp
permit tcp any any eq ftp-data
permit ip any any log (2 matches)

Hierop heb ik dus aan het eind de permit ip any any log toegevoegd, zoals was voorgesteld. Ik heb nu dus op beide routers permit ip any any staan. Nog kan ik geen ftpserver benaderen. Dit zou dus moeten betekenen dat het niet in de 3e (networklayer) laag zit, maar mogelijk een laag hoger in de transportlayer..?

Verwijderd

permit ip any any was wel voorgesteld maar bedoeld als losse access-list entry om gewoon al het ip verkeer toe te staan. icmp echter moet je daarnaast no separaat permitten

[ Voor 19% gewijzigd door Verwijderd op 22-09-2004 10:16 ]


Verwijderd

Topicstarter
Verwijderd schreef op 22 september 2004 @ 10:13:
permit ip any any was wel voorgesteld maar bedoeld als losse access-list entry om gewoon al het ip verkeer toe te staan. icmp echter moet je daarnaast no separaat permitten
ja logisch, maar aangezien er geen deny's in mijn lijst staan is dit volgens mij effectief hetzelfde. En op deze manier kan ik gelijk zien hoeveel packets er door de andere regels worden afgevangen. Alle overige packets die dus door de permit ip any any naar buiten gaan zijn dus packets die nog niet in de ACL zijn afgevangen.

[ Voor 25% gewijzigd door Verwijderd op 22-09-2004 13:12 ]


Verwijderd

Verwijderd schreef op 22 september 2004 @ 13:10:
[...]


ja logisch, maar aangezien er geen deny's in mijn lijst staan is dit volgens mij effectief hetzelfde. En op deze manier kan ik gelijk zien hoeveel packets er door de andere regels worden afgevangen. Alle overige packets die dus door de permit ip any any naar buiten gaan zijn dus packets die nog niet in de ACL zijn afgevangen.
Das waar. maar technisch kies ik vaker voor de aangegeven oplossing daar het screenen van een rule nu eenmaal sneller gaat dan twee.

Als je nu al het verkeer op de 2 routers prmit heb je dus gewoon een transparante verbinding voor ip. bestaat het probleem dan nog ?

Verwijderd

Topicstarter
beide acl's zijn nu voorzien van een permit ip any any log..maar ik kan nog altijd niet ftp-en. Er komen ook geen hits op deze regels. Nog niet opgelost dus..

het vreemde is dus dat het volgens mijn browser aan de proxyserver ligt:

De volgende map heeft het kenmerk Alleen-lezen omdat de proxyserver niet is ingesteld om volledige toegang te geven: ftp://mijndomein.nl.

Als u bestanden wilt verplaatsen, plakken, verwijderen of als u de bestandsnamen wilt wijzignen, dient u een andere proxyserver te gebruiken.


Dit zou volgens mij betekenen dat ik toch in ieder geval moet kunnen bladeren. Maar ik kan er dus helemaal niet op. Als ik vervolgens in het hoofdgebouw probeer een ftpserver te benaderen gaat dit wel. De pc's op de hoofdlocatie maken direct verbinding zonder dat eht verkeer over een router gaat, aangezien de proxyserver daar staat. Dit betekend dat de proxyserver wel degelijk ftpverkeer toestaat en dat eht probleem daar niet in zit.

[ Voor 7% gewijzigd door Verwijderd op 23-09-2004 17:04 ]


Verwijderd

Dus je access-list bestaat nu uit alleen permit ip any any ? en het werkt nog niet ?

[ Voor 91% gewijzigd door Verwijderd op 23-09-2004 20:29 ]


  • SambalBij
  • Registratie: September 2000
  • Laatst online: 21-02 20:33

SambalBij

We're all MAD here

Mcafee gebruikt waarschijnlijk active ftp, en daarvoor moet je router iets meer doen dan alleen maar poorten open zetten.

Bij passive ftp maakt je pc gewoon twee verbindingen naar buiten, eentje op poort 21 voor de control gegevens, en bij een transfer een tweede verbinding op poort 20 voor de data.

Bij active ftp geeft jouw pc aan de ftp server zijn ip adres door en de server gaat vervolgens daarheen een verbinding proberen op te zetten naar poort 20 op dat ip adres.
Als die pc nou achter een NAT verbinding zit dan zal hij dus zijn interne(!) ip adres doorgeven.
De router moet dus de ftp dataverbinding monitoren, het opzetten van die verbinding afvangen, en het interne ip wijzigen in het externe ip (en daarvoor gelijk ook een NAT translation aanmaken)

Bij Cisco IOS kun je daarvoor gebruik maken van CBAC (Content bases access control) mits je IOS versie dat ondersteund.

Probeer eens de volgende zaken op te nemen in je config:

code:
1
2
3
4
5
6
7
8
9
ip inspect name blah tcp
ip inspect name blah udp
ip inspect name blah ftp

interface Ethernet0
 ip inspect blah in

interface Dialer1
 ip inspect blah in

Sometimes you just have to sit back, relax, and let the train wreck itself


Verwijderd

Topicstarter
In welke router moet ik dit gaan doen? de hoofdrouter of mijn eigen router? Of beiden? En wat doet dit? Ik heb echt geen kennis van CBAC, dus voor ik iets ga aanpassen moet ik wel even duidelijk hebben wat ik doe. Bedankt alvast
Pagina: 1