What is this?

SPAM is a product of the Hormel company - I think you mean spam.

Often messenger spam.

No

man traceroute and look at the -p option. I must not that it's pushing the odds to see the same source port used on two different hosts. Also, if that is traceroute, the TTL should be at zero or one, and Atlanta is four or six hops away. Without looking at the tcpdump to see what is in the headers, I can't say much more, but I'd also be looking at a '-D' option of nmap as a possible cause.

Search the news groups 'news.admin.net-abuse.*' particularly 'blocklisting' and 'sightings' - these guys don't have the cleanest reputation.

Old guy

That would be a reasonable assumption. It may not be right, but it's possible.

Yeah, there's not much you can do about UDP. It's still going to waste your bandwidth up to the router that drops/blocks it.

I already do. They also have a few other address blocks, like

4.20.90.0 - 4.20.90.255 206.98.113.0 - 206.98.113.255 63.175.174.0 - 63.175.175.255 206.191.128.0 - 206.191.191.255 63.251.0.0 - 63.251.255.255 206.229.153.0 - 206.229.153.255 64.74.0.0 - 64.74.255.255 206.253.192.0 - 206.253.223.255 64.94.0.0 - 64.95.255.255 208.33.216.0 - 208.33.219.255 65.209.66.0 - 65.209.66.255 208.146.32.0 - 208.146.47.255 66.150.0.0 - 66.151.255.255 209.191.128.0 - 209.191.191.255 69.25.0.0 - 69.25.255.255 212.118.224.0 - 212.118.255.255 69.25.12.0 - 69.25.13.255 216.52.0.0 - 216.52.255.255 72.5.0.0 - 72.5.159.255 216.223.0.0 - 216.223.63.255 206.64.105.0 - 206.64.105.255

Sorry - didn't mean for you to try to download those newsgroups. What I was suggesting was using

and going to the Advanced Group Search function. Out the words 'Internap' and / or 'PNAP' as the term to search for in those news groups.

Results 1 - 10 of 434 from Jan 1, 2005 to Sep 24, 2005 for Internap group:news.admin.net-abuse.* (0.14 seconds)

Results 1 - 10 of 136 from Jan 1, 2005 to Sep 24, 2005 for PNAP group:news.admin.net-abuse.* (0.14 seconds)

The thing that bothered me is that the packets came from two different addresses, but with the same source port. That is hard to believe.

I looked at your headers, and it said:

If you are running X, you are probably using a *nix. Not all come with tcpdump, but it's fairly common. 'nmap' - yeah, that's less common.

Old guy

Eh, sorry for my miss spelling I try to make use of my Swedish/English lexicon as much as I can.

snip

"base UDP port number used in probes (default is 33434)"

So this mean that "64.94.45.18 (fcp-4.chg.pnap.net)/64.94.45.26 (fcp-6.chg.pnap.net)" just done a traceroute on me?

It's pushing me too. ;-)

I think I will block 64.94.0.0 - 64.95.255.255 any way even if they are decoys.

"blocklisting" there was only around 1200 heads I downloded 500 of them and com up with nothing. "sightings" there was over 170,000 heads I downloded 500 of them with the same result.

I think I go for the traceroute becuse it happend at almost the same time and I haven´t seen it again in my log.'

Thank you for taking the time and too force me too downlode and read man traceroute and man nmap.

regards Anders.

snip

69.25.0.0 - 69.25.255.255 69.25.12.0 - 69.25.13.255

It looks to me that this two IP range´s doing the same job, or am I wrong? Any way they are in my own blocklist now.

snip

Results 1 - 10 of 9 710 for (Internap). (0,26 seconds)

Results 1 - 10 of 5 730 for "PNAP" (0,16 seconds)

As you stated before they realy don´t have the greatest reputation.

snip

I have tcpdump, both on my Linux (desktop) and my BSD (firewall), did look at the tcpdump -i on my desktop while I was checking out my firewall and it com up with almost ridiculous much information. I think I gonna take a look at my firewall later this day just for the fun of it, checking the var log.

Regards and ones again thank you for the time taken.

Anders

Thanks - 69.25.12.0/23 was added as a result of abusive traffic from that block. I later received additional spam from two other blocks, and just expanded the firewall block to all of Internap/PNAPs space there - the /16. I had never gone back and deleted the original block. Looks like it's time to go through the firewall rules to locate duplicates/overlaps. Ah, the magic of UNIX and pipes - two minutes, and I found two other overlaps.

Yes. I was also only searching in the news.admin.net-abuse.* groups.

You can use the built-in filtering terms in tcpdump to narrow that down a lot. For example 'tcpdump -n udp and not port 53' should only give you UDP traffic in either direction, but not DNS lookups. The -n is also to avoid adding even more traffic (DNS lookups to identify traffic by hostname).

Normally, I don't look very close at the perimeter firewall. It blocks this and that, and that is all I care to know. I'm really not interested in knowing that some host in Korea or Kenya tried to connect to a windoze trojan that I don't have installed - mainly because I don't have windoze on any system. They did not connect - and that is all that matters.

Old guy

I have run the -n option now, both then I was checking my mail on my ISP and my acount on hotmail, I also did some reading on some newspapers, and I can say that there is, as far as I now, no UDP traffic on my LAN side, but on the WAN side there´s a different story.

Well I do make use of XP from time to time butt mostley for printing/scanning and recording my old LP´s, so I don´t let it conect to internet any more, and some time in the future I will get ride of it one´s and for all.

By the way I did find this in my firewall log to day, it is from China and I have blocked them long time ago, but it is a litle interesting to see that they do make use of ICMP to see if I´am really is on the net.

Datum: 09/26 09:10:08 Namn: ICMP PING NMAP Prioritet: 2 Typ:: Attempted Information Leak IP-info: 219.134.72.108:n/a -> my IP :n/a Referenser: saknas SID: 469

09:10:17 INPUT eth1 TCP 219.134.72.108 2465 my IP 25(SMTP) 09:10:11 INPUT eth1 TCP 219.134.72.108 2465 my IP 25(SMTP) 09:10:08 INPUT eth1 TCP 219.134.72.108 2465 my IP 25(SMTP)

Anders

At my home, I really don't see that much UDP on any of my ISPs (I have three), and it's mainly messenger spam attempts. At work, the perimeter firewall is used to translate outgoing UDP (mainly DNS queries) to source ports above (roughly) 1100. As this is the only normal use we have for UDP, any _inbound_ UDP to ports below that number (excluding to port 53 to the externally visible DNS servers) is dropped - it can not be wanted traffic.

Guangdong province network (formerly Kuangtung - capital is Canton, now spelled Guangzhou). While CHINANET is run by the Army, they are leasing IPs to "business men" who make money renting IP space and hosts to any one who wants it.

Ping can be run in parallel - and takes less CPU cycles than trying to connect to a host that may or may not exist. This reduces the number of processes running on the spammers host.

Standard TCP behaviour - hello, wait 3 seconds, hello, wait 6 seconds, hello, wait 12 seconds, give up and try the next address.

Old guy

Lucky You, I have to go to a friend and use his conection to see my network from the outside.

Moe, one´s again you forced me too read, this time about DNS and traceroute, and I stumble up on this RFC´s 1034,1035 and the older one´s

882,883 I have not been able to read them yet, but as soon as I get time for it I will. One thing I read about was that it is common that someone who want to figure out about a systemcofiguration can make use of traceroute -S udp p53, so for time being I happely block that one.

Anders.

One of then isn't that much of a benefit, as they block a most traffic that isn't "normal". The second has a very restrictive AUP, so I can't (for example) use nmap to scan my other addresses.

RFC0882 and 0883 are obsolete - not worth reading except for historical reasons. For gaining understanding of DNS, the DNS-HOWTO has a lot of good information:

-rw-rw-r-- 1 gferg ldp 91563 Dec 23 2001 DNS-HOWTO

As you are looking at RFCs, you may want to scan RFC1180

1180 TCP/IP tutorial. T.J. Socolofsky, C.J. Kale. Jan-01-1991. (Format: TXT=65494 bytes) (Status: INFORMATIONAL)

which is also a good read.

What version of traceoute? I don't recognize the options from either the original Van Jacobson (LBL) version, Olaf Kirch's re-written version, or the TCP version from Michael Toren.

Old guy

I make use of callcontrol, this way I can have all my port´s in dropp/block mode even the more common one like ftp, mail and web. But I do realise that if I want to make use of my one mail/web and ftp server I do have to open up a litle.

I do like history, but I will read the more current ones first.

It´s downloded, and I will not only scan them.

Well, in this book (Hacking Exposed, Fourth Edition printed in 2003 by Stuart McClure, Joel Scambray, and George Kurtz), I did find this about locking traceroute to use only one particular port of you´re own desire. Traceroute 1.4a5 (ftp.cerias.purdue.edu/pub/tools/unix/netutils/traceroute/old) is what they clamed should work, they also declare that it is a modifyed verion of traceroute, made by Michael Schiffman 1997.

is the home page of the book, my copy is in Swedish and it is a litle difficult for me to translate it back in to English.

Anders

Don't forget that if you have nothing running on a port, it's closed. No firewall is needed. For example;

[compton ~]$ netstat -atu Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 *:ssh *:* LISTEN [compton ~]$

Not much to exploit there. In fact SSH is only accepting connections from a handful of addresses on the LAN. So, if I try to connect to a port without a listener, I see

[compton ~]$ telnet localhost Trying 127.0.0.1... telnet: Unable to connect to remote host: Connection refused [compton ~]$

Yes, but you can restrict the range of addresses allowed to connect. Depending on the application, this may be a local configuration file, or it may be done with tcp_wrappers (man 5 hosts_access) if the application is run out of inetd/xinetd or is compiled with libwrap, or it may have to be done with a firewall setup. As far as mail goes, unless your host is published as a MX server (see the DNS stuff), no one other than the port scanners are going to know you have a mail server, and your ISP could be blocking inbound 25 anyway (all three of mine do) for spam control.

The basic concept of DNS is relatively simple, but there are a lot of details to look at. Running a DNS server for a home LAN of less than 10 systems is often a waste of effort (just put everything in /etc/hosts), but popular Linux distributions often have tools to set up a simple server that is authoritative for the local LAN, and forwards all other requests to the ISP, caching the result. For example, Red Hat (Fedora FC4) has

-rw-r--r-- 1 mirror mirror 22749 Jan 5 23:04 caching-nameserver-7.3-3.noarch.rpm

to configure ISC Bind for this purpose.

[compton ~]$ whatis hping2 hping2 (8)- send (almost) arbitrary TCP/IP packets to network hosts [compton ~]$

That's June 1997. Not much changed in the later versions (1.4a6 to 1.4a12 came out in the last quarter of 2000), and the differences are not very significant.

I looked around the web site, but didn't find anything useful relating to the modification.

Old guy

I am planning to make use of Debian (on an older Celeron) for my server experiments, after I am finished with this LFS I am working on, I am a litle bit lazy so it will take some time. I also have to read up a lot on the DNS and find out what it is I want to do.

I dit apt-get my own hping, and after that I had played a litle with it, I had to look in my snort log, becuse I dident get any respond from my firewall. I did find over 700 hits. One of the explanation for what had hapend on snort.org was this:

""BAD-TRAFFIC tcp port 0 traffic This event is generated when TCP traffic to port 0 is detected. This should not be seen in normal TCP communications. This may be an attempt to verify the existance of a host or hosts at a particular address or address range. TCP traffic to port 0 is not valid under normal circumstances.""

Have to be careful with this tool.

First, I have to apologize for the "traceroute -S udp p53", the udp part should not be in there at all, it is an blunder made by me, I can only blame my self for that, did not dubbel check it,I am sorry.

Second, yes you are rigth, I did start to looking after anything related to Michael Schiffman and traceroute, and on this site, "

" I find this:

""traceroute Michael Schiffman patch stops increment enabling user to use 1 fixed UDP port number (i.e. port 53)

"", but the link does not seem to work. I even downloded the traceroute 1.4a5 from the ftp site and looked in the packet but there is nothing about him in there.

But I find this insted on "

":__________________________ ""You will notice that the scan terminates immediately after the target port is passed. This is due to the fact that traceroute continues to increase the port numbers for each probe sent. The probe immediately after the successful one will be denied by the ACL on the firewall. To possibly get further, a simple modification to traceroute can be done to add a command line switch to stop port incrementation (Figure 5). This allows us to force every probe we send to be acceptable to the firewall?s ACL (a side effect being that we might not get the normal ICMP unreachable message from the ultimate destination due to the fact that there might actually be something listening on the other end). See appendix A for the source code patch.

zuul:~>traceroute -S ?p53 10.0.0.15

traceroute to 10.0.0.15 (10.0.0.15), 30 hops max, 40 byte packets

1 10.0.0.1 (10.0.0.1) 0.516 ms 0.396 ms 0.390 ms

2 10.0.0.2 (10.0.0.2) 2.516 ms 2.476 ms 2.431 ms

3 10.0.0.3 (10.0.0.3) 5.060 ms 4.848 ms 4.721 ms ....

....

12 10.0.0.12 (10.0.0.12) 192.196 ms 185.265 ms *

13 10.0.0.13 (10.0.0.13) 168.151 ms 183.238 ms 183.458 ms

14 10.0.0.14 (10.0.0.14) 218.972 ms 209.388 ms 195.686 ms

15 10.0.0.15 (10.0.0.15) 236.102 ms 237.208 ms 230.185 ms

Figure 5""

___________________________

Anders

There are 12 bytes of "stuff" other than the IP addresses in an IP header and 16 bytes of "stuff" other than port numbers in a TCP header that can be "played" with. Only a few combinations are normally used. Fyodor of nmap fame makes use of other combinations to explore networks. hping2 is the manual version that lets you do even more.

Yes

OK - there are several different implementations of traceroute out there, and they differ in which option does what. The LBL (original) version does not have a -S option, and the version from Olaf Kirch (then Caldera, now SuSE) uses that as the LBL -s option for [Ss]ource address, which should have an IP address appended. The udp was also not a normal option.

OK - there are other tools that can do that ;-)

This fails on a properly set up firewall. If there are no name servers meant to be publicly accessible behind the firewall, there is no reason to all traffic to port 53 inbound. Where I work, we have three publicly accessible DNS servers - one in the DMZ, and two located at our upstream. All internal DNS requests go to servers behind the firewall, but as there is no reason for external hosts to know internal names, the external DNS servers are set to return "generic" answers to requests - so that when a request comes in for the name of 192.0.2.2, the answer returned is "192.0.2.2.example.com" rather than "file_server.example.com". That answer satisfies those who "must" have a "valid" hostname to put into their logs - (and if someone does the reverse lookup, and follows it with a forward lookup of 192.0.2.2.example.com, they get the 192.0.2.2 answer), but those answers don't provide useful information about the layout of our internal LAN. Creating those zonefiles is trivial - just a couple of dumb shell scripts. An external request for a public system (such as

does return the valid IP address of the web server in the DMZ (and a reverse lookup of that IP does return the ''), so the public can go there, but no further.

Old guy

Now I have readed the "DNS-HOWTO", and in there was this link to "How to secure my DNS server"

and that will probable cover secureity issues, but I have not had the time for it rigth now. But I have "dig" my ISP and that work as it should and also the localhost (127.0.0.1).

This link did not work

so that have I not been able to read up about, maybe it just is down temporary.

Thank You for time taken, and al useful info about DNS and traceroute.

Regards Anders

has address 216.158.54.131

version 1.03 updated March 5, 2000

Site is up for me at 19:45 UTC..

Old guy