Re: What's the best way to wiretap a network?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (Although I now what the NA...stands for I have to ask) >> From the initial discussions in Sweden around the new electronic >> communications act, it seems as if the operators are obliged to >> provide >> tapping free of charge. If this turns out to be the case, I guess it >> is >> pretty much the same all over Europe as the law is supposed to be >> based >> on a EU framework. > > There's nothing in the new EU Communications Framework (or indeed > elsewhere in EU law) that controls whether or not operators can charge > for wiretaps. It's a country by country thing. Complicated by some > countries that claim to re-imburse, actually being chronically bad at > paying the invoices. So the EU part is only the tapping requirement? The charging scheme is local? Or did I miss all of this? - kurtis - -BEGIN PGP SIGNATURE- Version: PGP 8.0.3 iQA/AwUBQBC5ZKarNKXTPFCVEQIXMgCgx9GfYC+KS43lvfqUAW94bwRGH8sAoLk7 Pss7/MQctcapaNOWAL0Au6V1 =Ei2W -END PGP SIGNATURE-
Re: sniffer/promisc detector
> > > My results vary from 15 minuts to 1 hour. > > Mine too. So nmap sucks if you want to quickly identify daemons running on > strange ports. No big deal. This discussion wasn't about nmap to start with. > The point of the discussion was wether it made sense to run services on > non-standard ports to deter cr4x0rs. Right anser is _it depends_ - do not rule out such option and do not use it as a panacea.
Re: AT&T carrying rfc1918 on the as7018 backbone?
> > Wasn't it established that they did infact not leak it but just routed it > inside their own network? Sorry, shouldn't have said "leaked".
Re: Large Mail Provider Throttling
Aaron Thomas [1/23/2004 8:28 AM] : Sender Permitted From (http://spf.pobox.com/) attempts to eliminate Joe Dropping from domain.com by doing a look up on a TXT record similar to [...] As this project is fairly new, there aren't many large domains making use of it, and the tools available aren't mature enough for some email What I described in my earlier email (helo filtering) is aimed at the same result. Only, it has to be done on a case by case basis. And it does allow road warriors. The second way (slightly more radical, prone to a little more collateral damage, but does stop a LOT of spam) - stop accepting mail from commonly forged freemail domains if the mail originates from an IP with either * no rDNS * generic (dialup / cable / dsl) pattern rDNS -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
RE: Large Mail Provider Throttling
There is a package that is being developed right now that basically will squelch emails received from some domain.com address if the sending IP address isn't in the list of permitted addresses. Sender Permitted From (http://spf.pobox.com/) attempts to eliminate Joe Dropping from domain.com by doing a look up on a TXT record similar to dccnet.com. IN TXT "v=spf1 mx ptr ip4:24.207.1.0/24 -all". This would block mail, with a FROM: address of [EMAIL PROTECTED] that didn't relay through any of the MX hosts, originate from any broadband client address (from the prt record) or from the 24.207.1.0 Class C address space. As this project is fairly new, there aren't many large domains making use of it, and the tools available aren't mature enough for some email implementations (mobile users making use of Hot Spots with SMTP Hijacking and no submit port opened) for which the sending users IP address isn't known. However, I do believe this project will pick up favor to help eliminate one source of address forgery, which I believe would have helped in your situation. AOL had made use of this for 24 hours earlier this month and it resulted in the blocking of a large volume of spam addressed from aol.com (not originating from aol.com address space). Hopefully sites like yahoo, hotmail and others Of course the cows have left the barn, but its definitely worth looking at. Cheers, Aaron -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Suresh Ramasubramanian Sent: January 22, 2004 6:15 PM To: Edward Gray Cc: [EMAIL PROTECTED] Subject: Re: Large Mail Provider Throttling Edward Gray wrote: > To protect ourselves from delayed mail, we have implemented several > system wide rules to block Autoreplies and Undeliverable messages from > being sent to the large providers. Unfortunately, this has resulted in > many complaints from customers (since it's all or nothing). We have so > far, left these rules enabled 24x7 since, the system already becomes > degraded by the time we realize an event is occurring. You might want to * Use a mailserver that can reject rather than bounce email (that is, a mailserver where the smtpd process has a view of the userdb) * Use a "current spam source" blocklist like cbl.abuseat.org, as well as a good open proxy blocklist like opm.blitzed.org * Set up spamassasin to trash rather than later bounce email that does get through your filters, and has a high enough spam score. * Do some HELO filtering (HELO hotmail.com from an IP with rDNS that doesn't say hotmail? HELO your.own.ip or HELO your.own.domain from an untrusted IP that you don't relay for / that someone hasn't authenticated from? REJECT) :) * I'd add that a simple header check to reject (or preferably, discard) any mail with the string ".mr.outblaze.com" in any Received: header will get rid of a lot of spam for you. There are a few other things, but these will be off topic here. Please feel free to mail me offlist. srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: AT&T carrying rfc1918 on the as7018 backbone?
On Thu, 22 Jan 2004, Brett Watson wrote: > I was just having a hard time believing AT&T was leaking 10/8 and that > any other large provider was accepting it so wanted to verify. Wasn't it established that they did infact not leak it but just routed it inside their own network? //tlund
Re: Large Mail Provider Throttling
Edward Gray wrote: To protect ourselves from delayed mail, we have implemented several system wide rules to block Autoreplies and Undeliverable messages from being sent to the large providers. Unfortunately, this has resulted in many complaints from customers (since it's all or nothing). We have so far, left these rules enabled 24x7 since, the system already becomes degraded by the time we realize an event is occurring. You might want to * Use a mailserver that can reject rather than bounce email (that is, a mailserver where the smtpd process has a view of the userdb) * Use a "current spam source" blocklist like cbl.abuseat.org, as well as a good open proxy blocklist like opm.blitzed.org * Set up spamassasin to trash rather than later bounce email that does get through your filters, and has a high enough spam score. * Do some HELO filtering (HELO hotmail.com from an IP with rDNS that doesn't say hotmail? HELO your.own.ip or HELO your.own.domain from an untrusted IP that you don't relay for / that someone hasn't authenticated from? REJECT) :) * I'd add that a simple header check to reject (or preferably, discard) any mail with the string ".mr.outblaze.com" in any Received: header will get rid of a lot of spam for you. There are a few other things, but these will be off topic here. Please feel free to mail me offlist. srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
Re: sniffer/promisc detector
+++ Jason Slagle [22/01/04 19:13 -0500]: > > The point of the discussion was wether it made sense to run services on > > non-standard ports to deter cr4x0rs. And I feel it doesn't. > I've sat here and watched this discussion and kept my thoughts to myself > because I'm thinking "Maybe I'm missing something", but I don't think I > am. > sshd exploit is known to the kiddies for 3 weeks before getting public. The k1dd13 isn't able to feed a single packet to my exploitable sshd. If I were to run that sshd on a non-standard port, and he wants my ass *and* knows his way around with nmap or such I would gain between minutes and an hour, as shown by others. Thanks to paranoid iptables I would gain days, weeks, months or more, depending on the luck he has with finding out which and 0wn1ng those boxes I use to gain access to the box he wants to cr4x0r. By the way: those boxes run other OSses on different architectures, just as a precaution. Hosted by others. Different networks, different accountnames and passwords. .bash_history linked to /dev/null, you know the works. That hours delay won't save my ass, as it takes three weeks for others to piece together the vulnerability. Those iptables *will* save my ass. More often than a non-standard port, at least. And now for running named on port 54 as a defense against buffer-overflows in bind.. :P -- Ruben van der Leij
Re: sniffer/promisc detector
> Mine too. So nmap sucks if you want to quickly identify daemons running on > strange ports. No big deal. This discussion wasn't about nmap to start with. > The point of the discussion was wether it made sense to run services on > non-standard ports to deter cr4x0rs. And I feel it doesn't. I've sat here and watched this discussion and kept my thoughts to myself because I'm thinking "Maybe I'm missing something", but I don't think I am. I don't think the OP ever hinted at the fact that he runs VUNERABLE services on another port. He just states that running SERVICES on alternative ports makes the automated worms/etc miss you. This may give you the time you need to get patched. It's part of a whole group of defenses, not the only one. sshd exploit is known to the kiddies for 3 weeks before getting public. By the time it's public, a worm is out to own systems with it. The worm targets 22. If you are running there and don't upgrade before the worm hits you, you're infected. If you were on another port, you'd likely have a bit more time to upgrade. This isn't about hiding the safe and leaving it unlocked, it's about not putting it out in the middle of a busy intersection frequented by crooks. If they target your safe, you're in trouble anyways - having it out of the way makes it less likely the casual crook will go "Oh that safe can be opened like this" and walk away with your money. Jason -- Jason Slagle - CCNP - CCDP /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . X - NO HTML/RTF in e-mail . / \ - NO Word docs in e-mail .
Re: AT&T carrying rfc1918 on the as7018 backbone?
> RFC1918 addresses are unpredictable on any network other than your own. > You shouldn't make assumptions about them. Anyone may use them for any > purpose on their network. If you send packets into their network using > RFC1918 addresses, you get whatever you get. If you require certaintity > its up to you to impose your policy at your edge. > > Does sending packets to RFC1918 addresses on other networks meet the "be > conservative in what you send" credo? I understand all that. We're working with the customer to harden the border (ACLs) and possibly take a bogon feed, etc. I was just having a hard time believing AT&T was leaking 10/8 and that any other large provider was accepting it so wanted to verify. -b
Re: AT&T carrying rfc1918 on the as7018 backbone?
On Thu, 22 Jan 2004, Brett Watson wrote: > The customer installed a "network mapping tool" today and suddenly > discovered they were seeing RFC1918 addresses in the map (hundreds of them) > that were *not* part of the customer's internal network. It turns out that > from what we can tell, insightbb.com (an AT&T sub or customer) is probably > unintentionally leaking 10/8 and AT&T is propogating that across their > network.Since the customer defaults for any "unknown" destination, > they're crossing the AT&T network. RFC1918 addresses are unpredictable on any network other than your own. You shouldn't make assumptions about them. Anyone may use them for any purpose on their network. If you send packets into their network using RFC1918 addresses, you get whatever you get. If you require certaintity its up to you to impose your policy at your edge. Does sending packets to RFC1918 addresses on other networks meet the "be conservative in what you send" credo?
Re: AT&T carrying rfc1918 on the as7018 backbone?
On Thu, 22 Jan 2004, Brett Watson wrote: > > The router at route-server.ip.att.net shows about 25 10.0.0.0/8 > > prefixes, most showing up over 4 weeks ago. > > Odd. I didn't see this when looking at at&t's looking glass via web > browser. I was looking for some smaller prefixes though and didn't just > look for 10/8 :-/ Btw, I was wrong in saying Level3 was one of the sources. They are announcing 8/8 which was just above the 10.X announcements. I was off by a line. Sorry if this caused any confusion. Btw, the announcements we are seeing are sized from /12 to /24. bye, ken emery
Large Mail Provider Throttling
As probably many of you have already experienced, we have been hit with mailbombs with forged Hotmail (or other large provider) addresses recently. This has resulted in the large provider throttling our mail flow which forces messages to be placed into our local queue for retry at a later time. This ultimately has resulted in our customers reporting delays in emailing such large providers (ie. Hotmail). To protect ourselves from delayed mail, we have implemented several system wide rules to block Autoreplies and Undeliverable messages from being sent to the large providers. Unfortunately, this has resulted in many complaints from customers (since it's all or nothing). We have so far, left these rules enabled 24x7 since, the system already becomes degraded by the time we realize an event is occurring. I was interested to see what other techniques or steps people have taken to protect themselves from these types of threats and whether they have managed to handle a large #of accounts without preventing AutoReplies and Undeliverable messages to large providers. For instance, has anyone been able to approach such large providers and request special handling of mail coming from their system (higher throttling threshold for example)? Thanks in advance, Edward Gray Director, Operations & Networks Tucows.com Co. [EMAIL PROTECTED]
Re: AT&T carrying rfc1918 on the as7018 backbone?
On Jan 22, 2004, at 5:53 PM, Brett Watson wrote: The router at route-server.ip.att.net shows about 25 10.0.0.0/8 prefixes, most showing up over 4 weeks ago. Odd. I didn't see this when looking at at&t's looking glass via web browser. I was looking for some smaller prefixes though and didn't just look for 10/8 :-/ show ip bgp 10.0.0.0/8 longer-prefixes is your friend in this case. -b -- Matt Levine <[EMAIL PROTECTED]> @Work: http://www.cachenetworks.com/ GPG Key: 0xC581FB64 "The Trouble with doing anything right the first time is that nobody appreciates how difficult it was." -BIX
Re: sniffer/promisc detector
+++ Alexei Roudnev [22/01/04 09:05 -0800]: > My results vary from 15 minuts to 1 hour. Mine too. So nmap sucks if you want to quickly identify daemons running on strange ports. No big deal. This discussion wasn't about nmap to start with. The point of the discussion was wether it made sense to run services on non-standard ports to deter cr4x0rs. And I feel it doesn't. However: nmap can be tweaked, if you want to operate with an axe. The default timeout per port is 5 seconds. You could shorten that. You could pre-scan networks, to find only interesting ports, and version-scan those. You could scan large subnets in parallel. You could re-write parts of it, or start from scratch. As long as a sshd yells "SSH-1.99" at you the moment you connect to it's port there's no hiding sshd. A well-tuned iptables or equivalent, on the other hand, might hide the presence of daemons completely for anyone except the designated users. How is that for obscurity? Unless you're coming from one of a very few permissible hosts, and connect to a specific IP on the machine you will get a normal RST, and think the port is unused. Even H4x0rsc4n Pr0 won't tell you that port is actually a way in, unless you happen to scan it from the right machine. -- Ruben van der Leij
Re: AT&T carrying rfc1918 on the as7018 backbone?
> > The router at route-server.ip.att.net shows about 25 10.0.0.0/8 > prefixes, most showing up over 4 weeks ago. Odd. I didn't see this when looking at at&t's looking glass via web browser. I was looking for some smaller prefixes though and didn't just look for 10/8 :-/ -b
Re: AT&T carrying rfc1918 on the as7018 backbone?
Once upon a time, Stephen Fisher <[EMAIL PROTECTED]> said: > The router at route-server.ip.att.net shows about 25 10.0.0.0/8 > prefixes, most showing up over 4 weeks ago. They do not appear to be announcing those routes to customers however (at least not this customer), but setting a static route pointing at our AT&T link does show that they will route 10.0.0.0/8 traffic (at least a few random IPs I tried). -- Chris Adams <[EMAIL PROTECTED]> Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble.
Re: AT&T carrying rfc1918 on the as7018 backbone?
On Thu, 22 Jan 2004, Matthew S. Hallacy wrote: > ATTBB (Now Comcast) uses ATT.net for connectivity, Comcast has to reach > all their cable modems across the USA from their outsourced tech support > centers, thus, att.net routes 10/8 across their network. Okay, that's fine. However why are there routes from Level3? Also I'm not Comcast so why am I seeing the routes? Also if Comcast needs this they should be paying for a tunnel over AT&T network (like the rest of us would have to do). bye, ken emery
Re: AT&T carrying rfc1918 on the as7018 backbone?
On Thu, Jan 22, 2004 at 03:21:01PM -0700, Brett Watson wrote: > > First, yes I know I should call AT&T but I want to know if anyone else sees > this problem: [snip] [random destinations chosen, first few hops removed on purpose] traceroute to 10.150.5.1 (10.150.5.1), 30 hops max, 38 byte packets 4 bic04-p2-0.rosehe1.mn.attbb.net (24.31.2.46) 9.621 ms 12.405 ms 8.635 ms 5 12.118.239.77 (12.118.239.77) 21.055 ms 22.684 ms 17.674 ms 6 tbr1-p012301.cgcil.ip.att.net (12.123.6.9) 21.249 ms 18.653 ms 32.055 ms 7 tbr1-cl1.sffca.ip.att.net (12.122.10.6) 60.504 ms 65.109 ms 63.290 ms 8 gbr1-p10.sffca.ip.att.net (12.122.11.66) 60.401 ms 62.929 ms 59.776 ms 9 gar1-p360.sffca.ip.att.net (12.123.13.57) 60.556 ms 60.769 ms 63.278 ms 10 12.126.195.122 (12.126.195.122) 62.064 ms 60.966 ms 64.617 ms 11 12.244.67.25 (12.244.67.25) 75.027 ms 68.277 ms 66.029 ms 12 12.244.67.21 (12.244.67.21) 66.410 ms 67.539 ms 67.902 ms 13 12.244.98.215 (12.244.98.215) 68.285 ms 69.883 ms 83.187 ms 14 10.150.5.1 (10.150.5.1) 72.288 ms 72.797 ms 70.952 ms traceroute to 10.240.0.1 (10.240.0.1), 30 hops max, 38 byte packets 4 bic04-p2-0.rosehe1.mn.attbb.net (24.31.2.46) 12.024 ms 9.476 ms 9.918 ms 5 12.118.239.77 (12.118.239.77) 30.056 ms 20.397 ms 17.087 ms 6 tbr2-p012301.cgcil.ip.att.net (12.123.6.13) 19.700 ms 36.509 ms 20.223 ms 7 tbr2-cl7.sl9mo.ip.att.net (12.122.10.46) 27.903 ms 37.704 ms 24.727 ms 8 tbr2-cl6.dlstx.ip.att.net (12.122.10.90) 39.469 ms 39.656 ms 39.857 ms 9 tbr1-p013601.dlstx.ip.att.net (12.122.9.161) 39.150 ms 41.235 ms 38.007 ms 10 tbr2-cl1.attga.ip.att.net (12.122.2.90) 59.744 ms 58.258 ms 58.824 ms 11 gbr2-p20.attga.ip.att.net (12.122.12.38) 56.180 ms 62.450 ms 55.442 ms 12 gar1-p370.attga.ip.att.net (12.123.21.5) 74.746 ms 59.692 ms 57.531 ms 13 12.244.72.90 (12.244.72.90) 60.589 ms 62.514 ms 60.926 ms 14 c-66-56-66-73.atl.client2.attbi.com (66.56.66.73) 57.664 ms ATTBB (Now Comcast) uses ATT.net for connectivity, Comcast has to reach all their cable modems across the USA from their outsourced tech support centers, thus, att.net routes 10/8 across their network. -- Matthew S. HallacyFUBAR, LART, BOFH Certified http://www.poptix.net GPG public key 0x01938203
Re: AT&T carrying rfc1918 on the as7018 backbone?
The router at route-server.ip.att.net shows about 25 10.0.0.0/8 prefixes, most showing up over 4 weeks ago. --- ken emery <[EMAIL PROTECTED]> wrote: > On Thu, 22 Jan 2004, Brett Watson wrote: > > So I just wanted to see if anyone that is defaulting to AT&T is > > seeing this same problem just to verify that what we're seeing is > > correct (for my customer's edification). Yes, I'm calling AT&T > > now :) > > Yep, they are sending 10.X.X.X routes to customers. From several > places > actually, Level3, Comcast (multiple AS's), AT&T, MediaOne, and > AccessPoint. >
Re: AT&T carrying rfc1918 on the as7018 backbone?
On Thu, 22 Jan 2004, Brett Watson wrote: > > First, yes I know I should call AT&T but I want to know if anyone else sees > this problem: > > I have a customer that is multi-homed to AT&T and WCOM. They accept > "default" via BGP from both providers and announce a handful of prefixes to > both providers. > > Given that they receive default, it's just the same as if they had a > *static* default to both providers. > > The customer installed a "network mapping tool" today and suddenly > discovered they were seeing RFC1918 addresses in the map (hundreds of them) > that were *not* part of the customer's internal network. It turns out that > from what we can tell, insightbb.com (an AT&T sub or customer) is probably > unintentionally leaking 10/8 and AT&T is propogating that across their > network.Since the customer defaults for any "unknown" destination, > they're crossing the AT&T network. > > If my customer had been taking full routing, with appropriate filters of > course, they wouldn't be seeing this. But given that they are taking > default, they see it. > > So I just wanted to see if anyone that is defaulting to AT&T is seeing this > same problem just to verify that what we're seeing is correct (for my > customer's edification). Yes, I'm calling AT&T now :) Yep, they are sending 10.X.X.X routes to customers. From several places actually, Level3, Comcast (multiple AS's), AT&T, MediaOne, and AccessPoint. bye, ken emery
AT&T carrying rfc1918 on the as7018 backbone?
First, yes I know I should call AT&T but I want to know if anyone else sees this problem: I have a customer that is multi-homed to AT&T and WCOM. They accept "default" via BGP from both providers and announce a handful of prefixes to both providers. Given that they receive default, it's just the same as if they had a *static* default to both providers. The customer installed a "network mapping tool" today and suddenly discovered they were seeing RFC1918 addresses in the map (hundreds of them) that were *not* part of the customer's internal network. It turns out that from what we can tell, insightbb.com (an AT&T sub or customer) is probably unintentionally leaking 10/8 and AT&T is propogating that across their network.Since the customer defaults for any "unknown" destination, they're crossing the AT&T network. If my customer had been taking full routing, with appropriate filters of course, they wouldn't be seeing this. But given that they are taking default, they see it. So I just wanted to see if anyone that is defaulting to AT&T is seeing this same problem just to verify that what we're seeing is correct (for my customer's edification). Yes, I'm calling AT&T now :) -b
Re: sniffer/promisc detector
My results vary from 15 minuts to 1 hour.
Microsoft Product Informational Resources
After reading NANOG for a few years now and I have found the information here to be very helpful. After sharing the wealth of information I have found here with some of the members of the MIS department here, they asked if there might be some similar organizations with a focus on Microsoft system and network administration. They have access to the MSDN services; however, they were particularly interested in an organization not directly affiliated with Microsoft that might have a comparable level of knowledge as those in NANOG do regarding networking. If anyone has any ideas for such resources, the suggestions would be greatly appreciated. Also if there are past threads that I might have overlooked regarding this subject and someone will point me that direction, I will gladly search the archives again. Thank you to all for the great information in the past and any future suggestions. Sincerely, Ben Arnold Network Operations [EMAIL PROTECTED] VPNtranet, L.L.C.
Re: sniffer/promisc detector
I started such scan 10 - 20 minutes ago; it did not completed yet, so I do not have exact time (it is DSL -> 100 Mbit link + firewall). But you results shows just what I am saying - 99% of all attacks was caused by automated tools, and non-standard ports effectively blocks all such attacks. I agree to spend some time and set up non-standard ports (and even explain them to customers), if I decrease rate of attacks 100 - 1000 times (what really happen if ports are non-standard). If you are not a bank, do not host IRC server, and are not SCO, attack rate decreases to absolute 0. If you run nmap -p1-65000 in automated tool (with 10 minutes / host, and usually much more), you will scan Internet forever. So, it pay off. - Original Message - From: "Fyodor" <[EMAIL PROTECTED]> To: "Alexei Roudnev" <[EMAIL PROTECTED]> Cc: "Ruben van der Leij" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Thursday, January 22, 2004 1:12 AM Subject: Re: sniffer/promisc detector > > On Wed, Jan 21, 2004 at 09:04:40AM -0800, Alexei Roudnev wrote: > > > > Please, do it: > > > > time nmap -p 0-65535 $target > > > > You will be surprised (and nmap will not report applications; to test a > > response, multiply time at 5 ). And you will have approx. 40% of packets > > lost. > > > > Practically, nmap is useless for this purpose. > > Oh, really? I'll do a quick test of your theory that Nmap will be > slow with a 65K port scan, miss 40% of the open ports due to packet > loss, and not be able to report the application/services running on > the port. I may be biased, but anyone who wants to can reproduce this > test (at the risk of pissing off SCO, who admittedly are rather > litigous). To be even more fair, I'll run the scan from a > 128kbps-upstream aDSL line: > > # nmap -sSV -T4 -O -p0-65535 apollo.sco.com > WARNING: Scanning "port 0" is supported, but unusual. > > Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-01-22 00:49 PST > Interesting ports on apollo.sco.com (216.250.128.35): > (The 65524 ports scanned but not shown below are in state: closed) > PORT STATESERVICEVERSION > 0/tcp filtered unknown > 21/tcpopen ftpWU-FTPD 2.1WU(1)+SCO-2.6.1+-sec > 22/tcpopen sshSSH 1.2.22 (protocol 1.5) > 199/tcp open smux? > 457/tcp open http NCSA httpd 1.3 > 615/tcp open http NCSA httpd 1.5 > 1035/tcp filtered unknown > 1521/tcp open oracle-tns Oracle DB Listener 2.3.4.0.0 (for SCO System V/386) > 13722/tcp open inetd inetd (failed to exec /usr/openv/netbackup/bin/bpjava-msvc: No such file or directory) > 13782/tcp open inetd inetd (failed to exec /usr/openv/netbackup/bin/bpcd: No such file or directory) > 13783/tcp open inetd inetd (failed to exec /usr/openv/bin/vopied: No such file or directory) > 64206/tcp open unknown > Device type: general purpose > Running: SCO UnixWare > OS details: SCO UnixWare 7.0.0 or OpenServer 5.0.4-5.0.6 > > Nmap run completed -- 1 IP address (1 host up) scanned in 501.897 seconds > # > > So the full 65K port scan, plus OS and version detection took a little > over 8 minutes over a relatively slow connection. I ran it several > times to ensure ports weren't being missed. A quick test from my > colocated machine took 3 minutes. And it isn't like I had to watch > the whole time -- I was surfing a porn site in another window while it > ran. The services would have still been detected on different ports > as the same probes are done. I don't think using nonstandard ports > will help against any but the most marginal attackers and worms. But > if those are a serious problem, perhaps more time should be spent > patching rather than moving vulnerable services to unusual ports. > > I am not saying you won't get _any_ benefit at all from this > obfuscation, but I seriously doubt it will be worth the headaches. If > ports don't have to be reachable from the outside, filter them at > your firewall/router. If outsiders do need to reach the ports, moving > them around will just be a pain in the @#$ for those legitimate > users. You'll find that your own users are the ones port scanning you > in order to locate the services you've hidden. > > Cheers, > Fyodor > http://www.insecure.org > > PS: Yes, the scan would have been much slower if that host had a > "default deny" policy, but would not have been outrageous. You are > permitted to scan "scanme.insecure.org" to test that scenario. The > time taken is not unreasonable, when I run 65K scans against large > heavily filtered networks, I usually just let it run overnight.
Re: Outbound Route Optimization
On Thu, 22 Jan 2004, Patrick W.Gilmore wrote: > In any case, no matter how many resources or black boxes you have, you > cannot guarantee good performance on the 'Net. Too many people > involved over which you have no control. Even if you had control, BGP > is not the right tool to exert such control in all cases. Even more reason for people to buy the Sugar Mountain RouteMaster5000. No matter how good the claims are, you still end up with humans in the mix dictating "policy" of some sort over packets.
AS number for i.root-servers.net.
-BEGIN PGP SIGNED MESSAGE- Friends, Those of you who treat routing to the root DNS servers in a special way, can you please verify that you treat the routing to i.root-servers.net (the NORDUnet/Autonomica server administrated from Stockholm) the way you intend. Prefix: 192.36.148.0/24 Originating AS: 29216 NOTE: This prefix is anycast from several locations on the net (currently Stockholm, Helsinki, London, and Milan), but in all cases, the originating AS should be 29216. The source AS was changed in October 2003, but we suspect that the change from the old AS (8674) hasn't quite been communicated to all dark corners of the net. Please help us convey that information. Best regards, /Liman [EMAIL PROTECTED] #-- # There are 10 kinds of people in the world. Those who understand # binary numbers, and those who don't. #-- # Lars-Johan Liman, M.Sc. ! E-mail: [EMAIL PROTECTED] # Senior Systems Specialist ! HTTP : //www.autonomica.se/ # Autonomica AB, Stockholm ! Voice : +46 8 - 615 85 72 #-- -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (Darwin) iQCVAwUBQA+gLzySCHj+AqGZAQF32QP9E5ZfmpXVuU9jZULHtOE30sG0SyBBImFK lP90UgKjIj9yFsLtqwzKf8NcwgRDzAfUtiiMNUPCbhItHZPT8dYiEuBXM/96fH/t TqSoG+LfJb5lHfo8BKE1257g/3VC+EKZwYDOyr3O+ceWfl3hL86qXxzqxUxs0Xj7 BY8T6YEy4pc= =SlP3 -END PGP SIGNATURE-
Re: Outbound Route Optimization
On Jan 21, 2004, at 4:20 PM, vijay gill wrote: On Wed, Jan 21, 2004 at 09:05:46PM +, Paul Vixie wrote: My questions are these: "Is sub-optimal routing caused by BGP so pervasive it needs to be addressed?" that depends on your isp, and whether their routing policies (openness or closedness of peering, shortest vs. longest exit, respect for MEDs) are a good match for their technology/tools, skills/experience, and resources/headroom. In practice, all of the above just turn out to be marketing sauce or in some cases, outright lies. There is no substitute for dollar spend (opex and capex) to make a network perform. There is no magic sauce, there is no silver bullet. You have adequate resources, you will have adequate performance. I dunno if the last sentence is a type-o or not, but it is definitely incorrect in at least some cases. Having "adequate resources" in no way guarantees "adequate performance". (Unless you define "resources" to include the political clout to override business decisions which help the bottom line but hurt performance - e.g. not peering with a network because they are too small.) OTOH, having inadequate resources does give you a near perfect chance of having inadequate performance. (experience says they're not going to trust your MEDs even if they're close enough to hear them.) Most people don't trust MEDs for a reason paul, and it is not because they want to mess with your customers. There are a variety of reasons for not listening to MEDs, including political reasons which may not be in the best interest of performance, or even may be detrimental to performance. I've found most people willing to put in the time & effort to give you MEDs will give reasonably good MEDs. It also seems the hight of hubris to assume you know what is happening inside someone else's network better than the people who run that network. At least IMHO In any case, no matter how many resources or black boxes you have, you cannot guarantee good performance on the 'Net. Too many people involved over which you have no control. Even if you had control, BGP is not the right tool to exert such control in all cases. -- TTFN, patrick
Re: sniffer/promisc detector
On Wed, Jan 21, 2004 at 09:04:40AM -0800, Alexei Roudnev wrote: > > Please, do it: > > time nmap -p 0-65535 $target > > You will be surprised (and nmap will not report applications; to test a > response, multiply time at 5 ). And you will have approx. 40% of packets > lost. > > Practically, nmap is useless for this purpose. Oh, really? I'll do a quick test of your theory that Nmap will be slow with a 65K port scan, miss 40% of the open ports due to packet loss, and not be able to report the application/services running on the port. I may be biased, but anyone who wants to can reproduce this test (at the risk of pissing off SCO, who admittedly are rather litigous). To be even more fair, I'll run the scan from a 128kbps-upstream aDSL line: # nmap -sSV -T4 -O -p0-65535 apollo.sco.com WARNING: Scanning "port 0" is supported, but unusual. Starting nmap 3.50 ( http://www.insecure.org/nmap/ ) at 2004-01-22 00:49 PST Interesting ports on apollo.sco.com (216.250.128.35): (The 65524 ports scanned but not shown below are in state: closed) PORT STATESERVICEVERSION 0/tcp filtered unknown 21/tcpopen ftpWU-FTPD 2.1WU(1)+SCO-2.6.1+-sec 22/tcpopen sshSSH 1.2.22 (protocol 1.5) 199/tcp open smux? 457/tcp open http NCSA httpd 1.3 615/tcp open http NCSA httpd 1.5 1035/tcp filtered unknown 1521/tcp open oracle-tns Oracle DB Listener 2.3.4.0.0 (for SCO System V/386) 13722/tcp open inetd inetd (failed to exec /usr/openv/netbackup/bin/bpjava-msvc: No such file or directory) 13782/tcp open inetd inetd (failed to exec /usr/openv/netbackup/bin/bpcd: No such file or directory) 13783/tcp open inetd inetd (failed to exec /usr/openv/bin/vopied: No such file or directory) 64206/tcp open unknown Device type: general purpose Running: SCO UnixWare OS details: SCO UnixWare 7.0.0 or OpenServer 5.0.4-5.0.6 Nmap run completed -- 1 IP address (1 host up) scanned in 501.897 seconds # So the full 65K port scan, plus OS and version detection took a little over 8 minutes over a relatively slow connection. I ran it several times to ensure ports weren't being missed. A quick test from my colocated machine took 3 minutes. And it isn't like I had to watch the whole time -- I was surfing a porn site in another window while it ran. The services would have still been detected on different ports as the same probes are done. I don't think using nonstandard ports will help against any but the most marginal attackers and worms. But if those are a serious problem, perhaps more time should be spent patching rather than moving vulnerable services to unusual ports. I am not saying you won't get _any_ benefit at all from this obfuscation, but I seriously doubt it will be worth the headaches. If ports don't have to be reachable from the outside, filter them at your firewall/router. If outsiders do need to reach the ports, moving them around will just be a pain in the @#$ for those legitimate users. You'll find that your own users are the ones port scanning you in order to locate the services you've hidden. Cheers, Fyodor http://www.insecure.org PS: Yes, the scan would have been much slower if that host had a "default deny" policy, but would not have been outrageous. You are permitted to scan "scanme.insecure.org" to test that scenario. The time taken is not unreasonable, when I run 65K scans against large heavily filtered networks, I usually just let it run overnight.
Re: Outbound Route Optimization
Hello, > I am trying to determine for myself the relevance of Intelligent > Routing Devices like Sockeye, Route Science etc. I am not trying to > determine who does it better, but rather if the concept of optimizing > routes is addressing a significant problem in terms of improved > traffic performance ( not in cost savings of disparate transit pipes ) > An alternative to using such devices would be to tune the BGP configuration of the routers. See below for a description of an algorithm that allows to determine the optimum configuration of BGP routers for some traffic objectives [UBQ03] S. Uhlig, O. Bonaventure, and B. Quoitin. Interdomain traffic engineering with minimal BGP configurations. In 18th International Teletraffic Congress (ITC), September 2003. http://totem.info.ucl.ac.be/publications.html This work is being pursued in the framework of a governement-funded three-years research project, where we are developping an open-source traffic engineering toolbox. This objective of this toolbox is to provide a set of tools that can be used by ISPs and entreprise networks to optimize their intradomain and interdomain traffic flow. The first release of the toolbox is planned for november 2004. To help us fit this toolbox to the needs of ISP and enterprise networks, we would appreciate if you could fill our survey at : http://totem.info.ucl.ac.be/te_form.html Best regards, Olivier Bonaventure -- CSE Dept. UCL, Belgium - http://www.info.ucl.ac.be/people/OBO/
Re: sniffer/promisc detector
> > Yes. But making a bomber "stealth" means designing it to be difficult > to detect by an opponent. It doesn't mean painting "I am Not a > Bomber, I Am The Ice Cream Man" on the side and hoping nobody takes a > second glance at it. This works as well. 6 years ago we set up faked telnet services, which writed out login/password and reported 'no more processes', run a few faked telnet sessions (so that sniffers could record them) and then tracked an attempts to login. 'I am ice cream man' is a pretty good idea. Of course, if anyone will do it., Internet became some kind of 'Made man house' (it is already, isn't it?)
Re: sniffer/promisc detector
I saw such scanners 6 years ago (amazingly, they could not determine very old OS and very oold services...). But, just again, no one use it in automated scans over the Internet. As I was saying, port camuphlaging works as a very first line of defense - it cuts 99% of all attacks and akllow you to deal with the rest 1%. I'll measure time tomorrow... Such tools are usually very slow (and lost 20 - 50% of all packets, so to have a reliable result, you must scan host 2 - 4 times). - Original Message - From: "Crist Clark" <[EMAIL PROTECTED]> To: "Alexei Roudnev" <[EMAIL PROTECTED]> Cc: "Ruben van der Leij" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Wednesday, January 21, 2004 11:26 AM Subject: Re: sniffer/promisc detector > Alexei Roudnev wrote: > > > > Please, do it: > > > > time nmap -p 0-65535 $target > > > > You will be surprised (and nmap will not report applications; to test a > > response, multiply time at 5 ). > > Yes. It will, > > http://www.insecure.org/nmap/versionscan.html > > -- > Crist J. Clark [EMAIL PROTECTED] > Globalstar Communications(408) 933-4387
