pacnog November 2004

pacnog@pacnog.org

11 participants
7 discussions

by Joseph Riona

Your help is required I have an existing 128 K Permanent Internet Access (PIA) customer who has configured his network Internet access using a Cisco 1600 Series Router. Network Address Translation is configured on the Cisco 1600 router so that all PC's in their LAN can access to the Internet. His local network address is in the range of 192.168.0.X. The customer has decided to change their internet subscription to Docsis - Wireless Internet Access; this set up requires the use of Cisco 828 HDSL routers. My query is how do we configure Cisco 828 HDSL to be able to do NAT so that there is no change made to their LAN? Cheers Jrio

17 years, 7 months

FW: [SANOG] anycast stability experiment (fwd)

by Save Vocea

Hi ISP folks, Thought I'd fwd this seeking your contribution to the experiment. Randy Bush is also co-chair of APNIC routing SIG. Rgds, Save ---------- Forwarded message ---------- Date: Tue, 16 Nov 2004 16:27:46 -0800 From: Randy Bush <randy(a)psg.com> To: ops sheep willing to be censored by a non-op <nanog(a)nanog.org>, apops(a)apops.net, sig-routing(a)apnic.net, routing-wg(a)ripe.net, afnog(a)afnog.org, sanog(a)sanog.org Subject: [SANOG] anycast stability experiment Resent-Date: Wed, 17 Nov 2004 07:46:04 -0800 Resent-From: randy(a)psg.com Resent-To: sanog(a)sanog.org the verisign gang gave a good presentation of "Life and Times of J-Root" at the recent nanog meeting' see <http://www.nanog.org/mtg-0410/pdf/kosters.pdf>. on foils 27 to 29, they reported non-trivial routing jitter and therefore suggested "DO NOT RUN anycast with stateful transport." on the other hand, for almost a decade, there have been reports of successfully delivery of stateful services over anycast. so one wonders if their measurement was from an abnormal vantage point, or if there are other interesting things going on. as we are curious and inclined to test conjectures by experiment, scientific method and all that, we devised a small experiment in which we would very much appreciate your participation. we wish to collect data on the stability of which actual anycast root server(s) you contact from many points on or near the net's edges, i.e.. your home, datacenter, .... to do this, peter boothe, of university of oregon, has written a script which queries those roots which are known to be widely anycast every few seconds using dig [options] @<foo>.root-servers.net. hostname.bind chaos txt to record which actual unicast-named server was reached. these probes are recorded in a file that looks like, for example 42.666.7.11 Sat Nov 13 01:29:29 UTC 2004 f UDP pao1e.f.root-servers.org Sat Nov 13 01:29:29 UTC 2004 i UDP s1.lnx Sat Nov 13 01:29:30 UTC 2004 j UDP jns4-kgtld.j.root-servers.net Sat Nov 13 01:29:30 UTC 2004 k UDP k1.linx Sat Nov 13 01:29:30 UTC 2004 m UDP M-d3 Sat Nov 13 01:29:30 UTC 2004 c TCP lax1a.c.root-servers.org Sat Nov 13 01:29:31 UTC 2004 f TCP pao1c.f.root-servers.org Sat Nov 13 01:29:31 UTC 2004 i TCP s1.lnx Sat Nov 13 01:29:31 UTC 2004 j TCP jns1-kgtld.j.root-servers.net Sat Nov 13 01:29:32 UTC 2004 k TCP k1.linx Sat Nov 13 01:29:33 UTC 2004 m TCP M-d3 Sat Nov 13 01:29:35 UTC 2004 c UDP lax1a.c.root-servers.org Sat Nov 13 01:29:35 UTC 2004 f UDP pao1e.f.root-servers.org Sat Nov 13 01:29:35 UTC 2004 i UDP s1.lnx Sat Nov 13 01:29:35 UTC 2004 j UDP jns3-kgtld.j.root-servers.net Sat Nov 13 01:29:36 UTC 2004 k UDP k1.linx Sat Nov 13 01:29:36 UTC 2004 m UDP M-d3 which is mailed off to peter's collector once a day. note that your public ip address is the first thing in the file. this is learned by wget (or telnet to port 80, in case you do not have wget installed) to peter's server at oregon, which responds with the public ip address from which you came. this serves two purposes: o we may want to know from where measurements were taken so we can look at routing data to see why anomalies or normalities occurred. o we are concerned about overloading the root servers against which this experiment is running. therefore, the script will not actually perform the probes unless peter's server responds to the ip address query. this allows peter to throttle or disable the experiment should 10,000 people decide to run it. it might also be used to select probers to concentrate on 'interesting' probe locales in the internet topology. it's just a short shell script, so you should be able to easily feel comfortable that it will not make you vulnerable to anthing other than possible expulsion from the nanog mailing list :-). as it probes only a select list of anycast root servers, and does so every two seconds, this should not place any significant load on the servers or your machine. as our conjecture involves verisign's implication of stateful, e.g., tcp, connections, early reviewers of the experimental setup pushed us to test tcp as well as udp queries. as a tcp query is estimated to have many more packets than a udp query, the current code does one tcp probe every ten udp queries, i.e., around once every 20 seconds. we would really appreciate it if you would run this for a day or three. a tarball with the script and a readme can be found at <http://rip.psg.com/~randy/anycast_gatherer-1.4.tar.gz> [ fyi, my personal bet is that it's usually pretty stable except for sites in strangely unstable routing environments. but i am under my quota of wrong for the week. ] thanks! and many thanks to the early reviewers of the experiment. randy, peter, and friends

17 years, 7 months

[Fwd: RE: TCP bandwidth usage was: Yahoo is not using ESMTP]

by Franck Martin

Picked this one on IETF... If you think we start to have broadband in the Pacific, Think again... Cheers -------- Original Message -------- Subject: RE: TCP bandwidth usage was: Yahoo is not using ESMTP Date: Tue, 16 Nov 2004 21:14:13 -0800 From: Michel Py <michel(a)arneill-py.sacramento.ca.us> To: Paul Hoffman / VPNC <paul.hoffman(a)vpnc.org>, <ietf(a)ietf.org> > Paul Hoffman / VPNC wrote: > What Michael said. This is probably below the radar for now > because, so far, BitTorrent trading of large files (regular TV > shows and pirated movies) is more popular in Asia and Europe > than in the US. Indeed, I made that very point on Nanog a couple months ago. But it will arrive in America sooner or later and I don't see anything stopping that freight train. Plenty of overseas torrent sites (such as www.torrentbits.org, located in the NL) are in English, no language barrier here. > Even on the well-known BitTorrent ports, there is a *huge* > amount of trading going on. Approaching a petabyte per day (that's right, 1K terabytes) me thinks. And it might get worse soon: double-layer DVD burners are out (I bought one for $79 last week), in a short while we will see blank double-layer DVDs at the current DVD-R prices ($0.40 a pop) and images that are 8.7 GBytes instead of 4.7 GBytes. Christmas 2005: blue ray DVDs :-( $DEITY help ISPs. <conspiracy theory> Cisco is supporting 10+ Gbyte file swap to sell more CRS-1s. Juniper is supporting 10+ Gbyte file swap to sell more T-640s. </conspiracy theory> > To make things more difficult for the law, a good chunk of > that trading is completely legitimate, allowed-use music > trading of artists who actively encourage trading of live > show recordings. And some that encourage distributing software and/or software updates that way. I foresee small players publishing a torrent instead of having their FTP site, and seed it only with a few low-bandwidth machines. BitTorrent was not originally designed to swap illegal content. Technically speaking, hard to take it down too. Last week, I successfully tested resuming multiple downloads with re-published torrents pointing to a different tracker than the original one that was taken down. No problem. And it's not such a big deal to run a big site, apparently: > TorrentBits.org is situated on a dedicated server in the Netherlands. > For the moment we have monthly running costs of approximately € 213. Private torrent site for 100,000 users.... Michel. -- Franck Martin ICT Specialist franck(a)sopac.org SOPAC, Fiji GPG Key fingerprint = 44A4 8AE4 392A 3B92 FDF9 D9C6 BE79 9E60 81D9 1320 "Toute connaissance est une reponse a une question" G.Bachelard _______________________________________________ Ietf mailing list Ietf(a)ietf.org https://www1.ietf.org/mailman/listinfo/ietf

17 years, 7 months

protecting static ip address

by Sam Kava

Hi All, Can someone give me some hints on how to protect static ip address from being used by unauthorized users. Appreciate any help. Malo Sam Kava Internet Section Tonga Communications Corporation Salote Rd Private Bag 4 Nuku'alofa Tonga Ph: 676 20059, 676 23807 email: samkava(a)kalianet.to --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.789 / Virus Database: 534 - Release Date: 7/11/2004

17 years, 7 months

Fwd: Cisco Security Advisory: Cisco IOS DHCP Blocked Interface Denial-of-Service

by Philip Smith

FYI. In addition to the advisory below, it might be a good idea to configure "no service dhcp" on all your Cisco routers (apart from those which are providing a DHCP service of course). philip -- >From: Cisco Systems Product Security Incident Response Team <psirt(a)cisco.com> >To: nanog(a)merit.edu >Cc: psirt(a)cisco.com >Subject: Cisco Security Advisory: Cisco IOS DHCP Blocked Interface >Denial-of-Service >Date: Wed, 10 Nov 2004 09:00:00 -0800 > > >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > >Cisco Security Advisory: Cisco IOS DHCP Blocked Interface Denial-of-Service >=============================================================================== > >Revision 1.0 > >For Public Release 2004 November 10 1700 UTC (GMT) > >- >------------------------------------------------------------------------------- > >Contents > > Summary > Affected Products > Details > Impact > Software Versions and Fixes > Obtaining Fixed Software > Workarounds > Exploitation and Public Announcements > Status of This Notice: FINAL > Distribution > Revision History > Cisco Security Procedures > >- >------------------------------------------------------------------------------- > >Summary >======= > >Cisco IOS devices running branches of Cisco IOS version 12.2S that have >Dynamic Host Configuration Protocol (DHCP) server or relay agent enabled, even >if not configured, are vulnerable to a denial of service where the input queue >becomes blocked when receiving specifically crafted DHCP packets. Cisco is >providing free fixed software to address this issue. There are also >workarounds >to mitigate this vulnerability. This issue was introduced by the fix included >in CSCdx46180 and is being tracked by Cisco Bug ID CSCee50294 ( registered >customers only) . > >This advisory is available at >http://www.cisco.com/warp/public/707/cisco-sa-20041110-dhcp.shtml. > >Affected Products >================= > >This vulnerability was introduced by the fix for CSCdx46180, and was >integrated >in Cisco IOS 12.2(14)SZ and 12.2(18)S. > >The following Cisco products running Cisco IOS version 12.2(14)SZ, or a >variant >of Cisco IOS 12.2(18)S (as listed in the following section) and higher are >affected by this vulnerability. > > * Cisco 7200, 7300, 7500 platforms > * Cisco 2650, 2651, 2650XM, 2651XM Multiservice platform > * Cisco ONS15530, ONS15540 > * Cisco Catalyst 4000, Sup2plus, Sup3, Sup4 and Sup5 modules > * Cisco Catalyst 4500, Sup2Plus TS > * Cisco Catalyst 4948, 2970, 3560, and 3750 > * Cisco Catalyst 6000, Sup2/MSFC2 and Sup720/MSFC3 > * Cisco 7600 Sup2/MSFC2 and Sup720/MSFC3 > >Vulnerable Products >- ------------------- > >This issue affects only Cisco devices running affected Cisco IOS versions 12.2 >(18)EW, 12.2(18)EWA, 12.2(14)SZ, 12.2(18)S, 12.2(18)SE, 12.2(18)SV, 12.2(18)SW >and higher that do not have the configuration command no service dhcp. It is >not necessary for DHCP server or relay agent to be configured in order for >this >vulnerability to be present and exploited; "service dhcp" is enabled by >default >in IOS and is the only setting necessary (in addition to interface addresses) >for exploitation of this vulnerability. This includes routers as well as >switches and line cards which run Cisco IOS software. Cisco devices which do >not run Cisco IOS software are not affected. Cisco devices running affected >Cisco IOS software with the command no service dhcp enabled are not affected. > >To determine the software running on a Cisco product, log in to the device and >issue the show version command to display the system banner. Cisco IOS >software >will identify itself as "Internetwork Operating System Software" or simply >"IOS." On the next line of output, the image name will be displayed between >parentheses, followed by "Version" and the IOS release name. Other Cisco >devices will not have the show version command or will give different output. > >The following example identifies a Cisco product running IOS release 12.0(3) >with an installed image name of C2500-IS-L: > > Cisco Internetwork Operating System Software IOS (TM) > 2500 Software (C2500-IS-L), Version 12.0(3), RELEASE SOFTWARE > >The release train label is "12.0." > >The next example shows a product running Cisco IOS release 12.0(2a)T1 with an >image name of C2600-JS-MZ: > > Cisco Internetwork Operating System Software IOS (tm) > C2600 Software (C2600-JS-MZ), Version 12.0(2a)T1, RELEASE SOFTWARE (fc1) > >Additional information about Cisco IOS release naming can be found at >http://www.cisco.com/warp/public/620/1.html. > >Products Confirmed Not Vulnerable >- --------------------------------- > >Cisco devices running affected Cisco IOS software with the command no service >dhcp enabled are not affected. > >Cisco products that run any versions of IOS not listed in the Software >Versions >and Fixes table below, are not affected. > >Cisco products that do not run Cisco IOS software and are not affected by this >vulnerability include, but are not limited to: > > * 700 series dialup routers (750, 760, and 770 series) are not affected. > * WAN switching products such as the IGX, BPX and MGX lines are not > affected. > * No host-based software is affected. > * The Cisco PIX Firewall is not affected > * The Cisco LocalDirector is not affected. > * The Cisco Content Engine and ACNS is not affected. > * The Catalyst 2901/2902, 2948G, 2980G, 4000, 5000, and 6000 switches > running > CatOS. > * Cisco Network Registrar is not affected. > * Cisco VPN 3000 series is not affected > * Cisco IOS-XR platform is not affected. > * Cisco MDS 9000 family is not affected. > >Details >======= > >DHCP services allow devices to request and receive basic host configuration >information from the DHCP server via the network. Cisco routers can be >configured to both provide dynamic host configuration information (termed DHCP >server function), and forward DHCP and BootP packets across separate broadcast >domains (termed DHCP relay agent function). Cisco routers are configured to >process and accept DHCP packets by default, therefore the command "service >dhcp" >does not appear in the running configuration display, and only the command for >the disabled feature, no service dhcp, will appear in the running >configuration >display when the feature is disabled. The vulnerability is present, regardless >if the DHCP server or relay agent configurations are present on an affected >product. The only required configuration for this vulnerability in affected >versions is the lack of the no service dhcp command. Certain crafted DHCP >packets may be undeliverable, but will remain in the queue instead of being >dropped. If a number of packets are sent that equal the size of the input >queue, no more traffic will be accepted on that interface. > >On a blocked Ethernet interface, Address Resolution Protocol (ARP) times out >after a default time of four hours, and no inbound or outbound traffic can be >processed, including both IP and non-IP traffic such as IPX. The device >must be >rebooted to clear the input queue on the interface, and will not reload >without >user intervention. The attack may be repeated on all interfaces, causing the >router to be remotely inaccessible, excluding the console port where DHCP >packets are not processed by default and which can be used for out-of-band >management and configured for remote access. Workarounds are available, >and are >documented in the Workarounds section below. Other types of interfaces, >including but not limited to ATM, Serial and POS interfaces, are affected, but >ARP is not a factor. > >To identify a blocked input interface, use the show interfaces command and >look >for the Input Queue line. The size of the input queue may keep increasing. If >the current size (in this case, 76) is larger than the maximum size (75), the >input queue is blocked. > > Router#show interface ethernet 0/0 > Ethernet0/0 is up, line protocol is up > Hardware is AmdP2, address is 0050.500e.f1e0 (bia 0050.500e.f1e0) > Internet address is 172.16.1.9/24 > MTU 1500 bytes, BW 10000 Kbit, DLY 1000 usec, rely 255/255, load 1/255 > Encapsulation ARPA, loopback not set, keepalive set (10 sec) > ARP type: ARPA, ARP Timeout 04:00:00 > Last input 00:00:41, output 00:00:07, output hang never > Last clearing of "show interface" counters 00:07:18 > Input queue: 76/75/1091/0 (size/max/drops/flushes); Total output > drops: 0 > > > !--- The 76/75 shows that this is blocked > > >Impact >====== > >A device receiving these specifically crafted DHCP packets will force the >inbound interface to stop processing traffic. The device may stop processing >packets destined to the router, including routing protocol packets and ARP >packets. No alarms will be triggered, nor will the router reload to correct >itself. This vulnerability may be exercised repeatedly resulting in loss of >availability until a workaround has been applied or the device has been >upgraded to a fixed version of code. > >The effects of this vulnerability can be monitored by the same methods >outlined >in the white paper entitled Uses of Network Management for Monitoring the "IP >Packet Blocks Input Queue" PSIRT Advisory which details methods to identify >impacted devices via SNMP, RMON, and Network Management products. > >Software Versions and Fixes >=========================== > >Each row of the Cisco IOS software table below describes a release train and >the platforms or products for which it is intended. If a given release >train is >vulnerable, then the earliest possible releases that contain the fix (the >"First Fixed Release") and the anticipated date of availability for each are >listed in the "Rebuild" and "Maintenance" columns. A device running a release >in the given train that is earlier than the release in a specific column (less >than the First Fixed Release) is known to be vulnerable. The release should be >upgraded at least to the indicated release or a later version (greater than or >equal to the First Fixed Release label). When selecting a release, keep in >mind >the following definitions: > > * Maintenance: Most heavily tested, stable, and highly recommended > release of > a release train in any given row of the table. > * Rebuild: Constructed from the previous maintenance or major release > in the > same train, it contains the fix for a specific defect. Although it > receives > less testing, it contains only the minimal changes necessary to > repair the > vulnerability. > >In all cases, customers should exercise caution to confirm that the devices to >be upgraded contain sufficient memory and that current hardware and software >configurations will continue to be supported properly by the new software >release. If the information is not clear, contact the Cisco TAC for assistance >as shown in the Obtaining Fixed Software section below. > >More information on Cisco IOS software release names and abbreviations is >available at http://www.cisco.com/warp/public/620/1.html. > >The fixes will be available at the Software Center located at >http://www.cisco.com/tacpage/sw-center/. > >For software installation and upgrade procedures, see >http://www.cisco.com/warp/public/130/upgrade_index.shtml. > >For a current view of all posted and repaired images for Cisco IOS, please >check the listing available to registered Cisco.com users at: >http://www.cisco.com/tacpage/sw-center/sw-ios.shtml. > >+---------------------------------------------+ >| Major Release | Availability of Repaired | >| | Releases | >|----------------+----------------------------| >| Affected | | | >| 12.2-Based | Rebuild | Maintenance | >| Release | | | >|----------------+--------------+-------------| >| 12.2(18)EW | 12.2(18)EW2 | | >|----------------+--------------+-------------| >| 12.2(18)EWA | | 12.2(20)EWA | >|----------------+--------------+-------------| >| | 12.2(18)S6 | | >| |--------------+-------------| >| | 12.2(20)S4 | | >|12.2(18)S |--------------+-------------| >| | 12.2(22)S2 | | >| |--------------+-------------| >| | | 12.2(25)S | >|----------------+--------------+-------------| >| 12.2(18)SE | 12.2(20)SE3 | | >|----------------+--------------+-------------| >| 12.2(18)SV | | 12.2(24)SV | >|----------------+--------------+-------------| >| 12.2(18)SW | | 12.2(25)SW | >|----------------+----------------------------| >| 12.2(18)SXD | Not impacted | >|----------------+----------------------------| >| 12.2(14)SZ | Migrates to | | >| | 12.2(20)S4 | | >+---------------------------------------------+ > >Obtaining Fixed Software >======================== > >Customers with Service Contracts >- -------------------------------- > >Customers with contracts should obtain upgraded software through their regular >update channels. For most customers, this means that upgrades should be >obtained through the Software Center on Cisco's worldwide website at http:// >www.cisco.com. > >Customers using Third-party Support Organizations >- ------------------------------------------------- > >Customers whose Cisco products are provided or maintained through prior or >existing agreement with third-party support organizations such as Cisco >Partners, authorized resellers, or service providers should contact that >support organization for assistance with the upgrade, which should be free of >charge. > >Customers without Service Contracts >- ----------------------------------- > >Customers who purchase direct from Cisco but who do not hold a Cisco service >contract and customers who purchase through third-party vendors but are >unsuccessful at obtaining fixed software through their point of sale >should get >their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC >contacts are as follows. > > * +1 800 553 2447 (toll free from within North America) > * +1 408 526 7209 (toll call from anywhere in the world) > * e-mail: tac(a)cisco.com > >Please have your product serial number available and give the URL of this >notice as evidence of your entitlement to a free upgrade. Free upgrades for >non-contract customers must be requested through the TAC. > >Please do not contact either "psirt(a)cisco.com" or "security-alert(a)cisco.com" >for software upgrades. > >See http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional >TAC contact information, including special localized telephone numbers and >instructions and e-mail addresses for use in various languages. > >Customers may only install and expect support for the feature sets they have >purchased. By installing, downloading, accessing or otherwise using such >software upgrades, customers agree to be bound by the terms of Cisco's >software >license terms found at http://www.cisco.com/public/sw-license-agreement.html, >or as otherwise set forth at Cisco.com Downloads at >http://www.cisco.com/public/sw-center/sw-usingswc.shtml. > >Workarounds >=========== > >There are four possible workarounds for this vulnerability: > > * Disabling the dhcp service > * Control Plane Policing > * Two versions of Access Control Lists > >Disabling the DHCP Service >- -------------------------- > >This vulnerability can be mitigated by utilizing the command: > > no service dhcp > >However, this workaround will disable all DHCP processing on the device, >including the DHCP helper functionality that may be necessary in some network >configurations. > >Control Plane Policing Feature >- ------------------------------ > >The Control Plane Policy feature may be used to mitigate this >vulnerability, as >in the following example: > > access-list 140 deny udp host 192.168.13.1 any eq bootps > access-list 140 deny udp any host 192.168.13.1 eq bootps > access-list 140 deny udp any host 255.255.255.255 eq bootps > access-list 140 permit udp any any eq bootps > > class-map match-all bootps-class > match access-group 140 > > policy-map control-plane-policy > class bootps-class > > police 8000 1500 1500 conform-action drop exceed-action drop > > control-plane > service-policy input control-plane-policy > >For this example 192.168.13.1 is a legitimate DHCP server. > >Additional information on the configuration and use of the CPP feature can be >found at this link: > >http://www.cisco.com/en/US/partner/products/sw/iosswrel/ps1838/ >products_feature_guide09186a00801afad4.html. > >This workaround is only applicable to Cisco IOS 12.2S, as this feature is only >available in Cisco IOS versions 12.2S and 12.3T. Cisco IOS 12.3T is not >impacted by this advisory. > >Access Lists - Two Methods >- -------------------------- > >Access lists can be applied to block DHCP/BootP traffic destined to any router >interface addresses, as in the following example: > >In this example, the IP address 192.168.13.1 represents a legitimate DHCP >server, the addresses 10.89.236.147 and 192.168.13.2 represent router >interface >addresses, and 192.168.61.1 represents a loopback interface on the router. > >In this example, any bootp/dhcp packets destined to the router interface >addresses are blocked. > > access-list 100 remark permit bootps from the DHCP server > access-list 100 permit udp host 192.168.13.1 any eq bootps > access-list 100 remark deny bootps from any to router f1/0 > access-list 100 deny udp any host 10.89.236.147 eq bootps > access-list 100 remark deny bootps from any to router f0/0 > access-list 100 deny udp any host 192.168.13.2 eq bootps > access-list 100 remark deny bootps from any to router loopback1 > access-list 100 deny udp any host 192.168.61.1 eq bootps > access-list 100 remark permit all other traffic > access-list 100 permit ip any any > >access-list 100 is applied to f0/0 and f1/0 physical interfaces. > > interface FastEthernet0/0 > ip address 192.168.13.2 255.255.255.0 > ip access-group 100 in > interface FastEthernet1/0 > ip address 10.89.236.147 255.255.255.240 > ip access-group 100 in > ip helper-address 192.168.13.1 > >An alternate configuration for the interface access-list workaround. > >This example would also need to be applied to all physical interfaces, but >deny >statements for all of the IP addresses configured on the router are not >necessary in this approach. In this example, the address 192.168.13.1 >represents a legitimate DHCP server. > > access-list 100 permit udp host 192.168.13.1 any eq bootps > access-list 100 permit udp any host 192.168.13.1 eq bootps > access-list 100 permit udp any host 255.255.255.255 eq bootps > access-list 100 deny udp any any eq bootps > > interface FastEthernet0/0 > ip address 192.168.13.2 255.255.255.0 > ip access-group 100 in > interface FastEthernet1/0 > ip address 10.89.236.147 255.255.255.240 > ip access-group 100 in > ip helper-address 192.168.13.1 > >Note: These workarounds will not prevent spoofed IP packets with the source IP >address set to that of the DHCP server > >For more information on anti-spoofing refer to >http://www.cisco.com/en/US/tech/ >tk648/tk361/technologies_tech_note09186a0080120f 48.shtml#sec_ip and >http://www.ietf.org/rfc/rfc2827.txt. > >The Unicast Reverse Path Forwarding (Unicast RPF) feature helps to mitigate >problems that are caused by spoofed IP source addresses. For further details, >please refer to >http://www.cisco.com/univercd/cc/td/doc/product/software/ios122 >/122cgcr/fsecur_c/fothersf/scfrpf.htm. > >Exploitation and Public Announcements >===================================== > >The Cisco PSIRT is not aware of any public announcements or malicious use of >the vulnerability described in this advisory. This vulnerability was >reported >to Cisco by a customer. > >Status of This Notice: FINAL >============================ > >THIS ADVISORY IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF >GUARANTEE OR WARRANTY. YOUR USE OF THE INFORMATION ON THE ADVISORY OR >MATERIALS >LINKED FROM THE ADVISORY IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO >CHANGE OR UPDATE THIS NOTICE AT ANY TIME. > >Distribution > >This advisory will be posted on Cisco's worldwide website at >http://www.cisco.com/warp/public/707/cisco-sa-20041110-dhcp.shtml. > >In addition to worldwide web posting, a text version of this notice is >clear-signed with the Cisco PSIRT PGP key and is posted to the following >e-mail >and Usenet news recipients. > > * cust-security-announce(a)cisco.com > * first-teams(a)first.org (includes CERT/CC) > * bugtraq(a)securityfocus.com > * vulnwatch(a)vulnwatch.org > * cisco(a)spot.colorado.edu > * cisco-nsp(a)puck.nether.net > * full-disclosure(a)lists.netsys.com > * comp.dcom.sys.cisco(a)newsgate.cisco.com > >Future updates of this advisory, if any, will be placed on Cisco's worldwide >website, but may or may not be actively announced on mailing lists or >newsgroups. Users concerned about this problem are encouraged to check the >above URL for any updates. > >Revision History > >+---------------------------------------------+ >| Revision | | Initial | >| 1.0 | 2004-November-10 | public | >| | | release. | >+---------------------------------------------+ > >Cisco Security Procedures > >Complete information on reporting security vulnerabilities in Cisco products, >obtaining assistance with security incidents, and registering to receive >security information from Cisco, is available on Cisco's worldwide website at >http://www.cisco.com/en/US/products/products_security_vulnerability_policy.…. >This includes instructions for press inquiries regarding Cisco security >notices. All Cisco security advisories are available at >http://www.cisco.com/go/psirt. > >- >------------------------------------------------------------------------------- > >All contents are Copyright © 1992-2004 Cisco Systems, Inc. All rights >reserved. >Important Notices and Privacy Statement. > >-----BEGIN PGP SIGNATURE----- >Version: PGP 7.0 > >iQA/AwUBQZJN63sxqM8ytrWQEQIT9gCg1F3Il3xJrvye98FMPwMAP8/WlfkAoOx3 >+61bikQKb5rc/PFvzelpZfuP >=XQ2O >-----END PGP SIGNATURE-----

17 years, 7 months

reserting root password

by Joseph Riona

Does anyone knows how to reset the root password on Redhat 9.0 Cheers jrio

17 years, 8 months

Re: [pacnog] reserting root password

by Alain Cocconi

Hello, If it is because you've lost the root passwd here is the procedure : - boot with the RH CD in rescue mode - let RH to mount the partition in /mnt/sysimage - do : cd /mnt/sysimage chroot /mnt/sysimage - change your password : passwd - sync the disk : sync - reboot your system in normal mode good bye A 11:05 08/11/2004 +1100, vous avez écrit : >Does anyone knows how to reset the root password on Redhat 9.0 > >Cheers > >jrio > >_______________________________________________ >pacnog mailing list >pacnog(a)pacnog.org >http://mailman.apnic.net/mailman/listinfo/pacnog

17 years, 8 months

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

pacnog November 2004