On Saturday 04 Oct 2003 14:45, del-SLE wrote:

On Saturday 04 Oct 2003 13:25, Carlos E. R. wrote:

...

That's why they named them "martian" source.

It must be some new worm, virus, or whatever.

It is not a worm or virus! It's something to do with firewalling and localhost, I looked into this a couple of years ago. I've not used the Linux firewall tools for a long time, all hardware walls here now. Google has more info and, I think, that Suse has some on its own help dbase.

And first hit on google "martian source" http://cert.uni-stuttgart.de/archive/focus-linux/2003/05/ msg00001.html> -- del suse-linux-e

On Saturday 04 October 2003 15:32, Carlos E. R. wrote: <snip>

And the strange thing is that several people are noticing them recently: I have none listed for a whole year, they started this last September. Why? That's why I'm guessing at a virus or worm or exploit of some sort using those packets.

Carlos, I've been getting hit at DPT 135 at a rate of about 50-100 a day, for the last month or two. Then all of a sudden yesterday, I started getting hit with this Martian source. Bernd -- "If you want to build a ship, don't drum up the men to gather wood, divide the work, and give orders. Instead, teach them to yearn for the vast and endless sea." Antoine de St. Exupery

The 03.10.04 at 20:56, Bernd Koepsell wrote:

I've been getting hit at DPT 135 at a rate of about 50-100 a day, for the last month or two.

Yes, that's "normal". It is a windows thing. I get a lot more (several per minute), considering I use a modem and I connect only for minutes a day.

Then all of a sudden yesterday, I started getting hit with this Martian source.

That's why I think it must be some new kind of virus, worm, script, whatever. -- Cheers, Carlos Robinson

On Saturday 04 Oct 2003 15:31, Buck wrote:

Thank you for the Google reference, it was interesting reading.

Glad it helped. <snip>

These are very small networks. In one network, the server is mission critical and has no need to access the internet except for updates and when I am on it looking for something.

You could always load the updates to another machine first and get the server to update from that. It'll give you the chance to make sure the patches are what they say they are, virus scans etc. Maybe test them before using them on the server.

I am wondering if there is any benefit in activating the Linux firewall on that server even though it's behind a hardware firewall. We have had no problems with intruders coming through the firewall up until now, but a firewall log on one network reveals that it receives about 500 port probes every day (not the list of ports, just one or two) many of which are related to Trojans port addresses. The source IP addresses are unique so I am assuming they are just script-kiddies.

If you can spare the CPU cycles why not use the firewall on the server. On the one hand it's another level of security, no bad thing if the server is important. But it's also a point of failure that may cause the server to not work properly and more searching for the fix. It'll also provide another log to examine, you may not want the extra work/info.

Do you think I am sufficiently safe or should I take additional measures to insure the safety of the server?

That's a tough question for me, sitting approximately 3500 miles away. A political answer is yes, no and never! You should lean toward no and never!!! If you have been running this setup for 2-3 months with no problems, leave as is, keep the patching upto date and maybe see if an extra firewall is worth it. If this is a newish setup you'll need to way up the pros and cons of the different variations that are possible. Pick your best choice, suck it and see! Be flexible, 'cos you won't get it just right first time round. It will probably be secure but you'll need to tweak to get the best out of it. A spare machine is a good thing here, then you could use that to test things out before making it live for the rest of the network. All the best, -- del suse-linux-e

The 03.10.06 at 00:36, Micxz wrote:

If these are coming from your external interface than I think they are still misconfigured computers sendingout bunk packets.

Perhaps :-? But I have the feeling they are intentionally spoofed. What for? I have no idea.

I've recently seen a few on my box on the external dialup ppp0 like you. But I've yet to find a virus of worm in my searches on the net/google that has these simptoms. Have you?

No, I haven't looked.

Do you have a wireless network?

No, no, a modem line, connected only for minutes a day, except perhaps when downloading patches, like right now. -- Cheers, Carlos Robinson

The 03.10.09 at 15:05, Togan Muftuoglu wrote:

IIRC one of the recent worms were using windowsupdate.com with an address of 127.0.0.1 and microsoft had to drop the DNS record for windowsupdate.com

Aha! I knew there was some thing out there. :-)

If you have "snort" installed and configured and running you may see the following in your alert file

Now that you mention it... I had it running on my older machine, but for some reason, not on this system. I'm firing up Yast right now :-)

Yet this is all I can say :-(

Well, it's more than I knew. -- Cheers, Carlos Robinson

The 03.10.09 at 15:05, Togan Muftuoglu wrote: Mmm, I don't know if you are off-line still...

If you have "snort" installed and configured and running you may see the following in your alert file

It doesn't start: Oct 16 14:49:45 nimrodel snort: FATAL ERROR: ERROR: Unable to open rules file: /etc/rules/bad-traffic.rules or /etc/snort//etc/rules/bad-traffic.rules There is no directory '/etc/rules/', nor '/etc/snort//etc/rules/'. There is a '/etc/snort/bad-traffic.rules', however. I wonder if the problem is: # Path to your rules files (this can be a relative path) var RULE_PATH /etc/rules in the 'snort.conf'. I have changed it, and it seems to work. I'll see... -- Cheers, Carlos Robinson

On Wed, Oct 22, 2003 at 01:04:46PM -0700, Micxz wrote:

Has anyone else figured out what this was? Today I got:

Oct 22 12:54:50 mars kernel: martian source xx.xxx.xx.xxx from 127.0.0.1, on dev ppp0 Oct 22 12:54:50 mars kernel: ll header: 45:08:00:28

I recieved a dozen of those yesterday on my home system. What's more strange, the company's Checkpoint firewall started receiving same spoofed packets this morning at 8. Something weird is really going on on the Internet.

mars:~ # tcpdump -X -s 0 -n -vvv net 127.0.0.1 -i any tcpdump: WARNING: Promiscuous mode not supported on the "any" device tcpdump: listening on any 12:54:50.901690 127.0.0.1.80 > xx.xxx.xx.xxx.1947: R [tcp sum ok] 0:0(0) ack 1759903745 win 0 (ttl 126, id 61929, len 40) 0x0000 4500 0028 f1e9 0000 7e06 3050 7f00 0001 E..(....~.0P.... 0x0010 42f8 589d 0050 079b 0000 0000 68e6 0001 B.X..P......h... 0x0020 5014 0000 2468 0000 P...$h..

Where xx.xxx.xx.xxx is my dialup IP on ppp0. I'm not sure what this means and I cannot read much of this packet info. Does anyone know why it's happening?

It's an ack packet sent (or pretending to have been sent) from port 80 from a spoofed localhost address. I got another question. I have both FW_LOG_CRITICAL and FW_LOG_ALL set to "yes" but SuSEfirewall is not logging those spoofed packets from localhost. Does it mean that kernel drops martian source packets before they reach iptables? Thanks, -Kastus

On Thu, Oct 23, 2003 at 08:04:46AM +0800, Joe Morris (NTM) wrote:

On 10/23/2003 06:37 AM, Kastus wrote:

...

I have both FW_LOG_CRITICAL and FW_LOG_ALL set to "yes" but SuSEfirewall is not logging those spoofed packets from localhost.

Does it mean that kernel drops martian source packets before they reach iptables?

Check FW_KERNEL_SECURITY. This needs to be Yes to log the martian sources messages.

Just checked, it is set to yes. I still wonder if martian source packets ever reach iptables or they are dropped before that so iptables wee nothing. I looked at the source, /usr/src/linux/net/ipv4/route.c, and here is what is done to martian source packets: martian_source: rt_cache_stat[smp_processor_id()].in_martian_src++; #ifdef CONFIG_IP_ROUTE_VERBOSE if (IN_DEV_LOG_MARTIANS(in_dev) && net_ratelimit()) { /* * RFC1812 recommendation, if source is martian, * the only hint is MAC header. */ printk(KERN_WARNING "martian source %u.%u.%u.%u from " "%u.%u.%u.%u, on dev %s\n", NIPQUAD(daddr), NIPQUAD(saddr), dev->name); if (dev->hard_header_len) { int i; unsigned char *p = skb->mac.raw; printk(KERN_WARNING "ll header: "); for (i = 0; i < dev->hard_header_len; i++, p++) { printk("%02x", *p); if (i < (dev->hard_header_len - 1)) printk(":"); } printk("\n"); } } #endif goto e_inval; e_inval: err = -EINVAL; goto done; done: if (free_res) fib_res_put(&res); if (dev_out) dev_put(dev_out); out: return err; Does it mean at this point that the packet is dropped? Thanks, -Kastus

The 03.10.23 at 17:34, Joe Morris (NTM) wrote:

...

Just checked, it is set to yes. I still wonder if martian source packets ever reach iptables or they are dropped before that so iptables wee nothing.<snip> Does it mean at this point that the packet is dropped?

From my experience with SuSEfirewall and SuSEfirewall2, if FW_KERNEL_SECURITY is set to Yes, it will record martian source packets. I know mine does record them, i.e. Oct 1 17:59:31 jmorris kernel: martian source 169.254.255.255 from 169.254.234.16, on dev eth1 Oct 1 17:59:31 jmorris kernel: ll header: ff:ff:ff:ff:ff:ff:00:e0:4c:3b:a3:34:08:00

Notice that line above is not logged by the firewall, it doesn't have the "SuSE-FW-" prefix. It is dropped before it reaches the firewall code. martian packets can simply not be routed (no real address to respond to), thus it makes no sense to pass them on. According to '/usr/src/linux/Documentation/filesystems/proc.txt': 2.8 /proc/sys/net/ipv4 - IPV4 settings File '/proc/sys/net/ipv4/conf/*/log_martians' log_martians ------------ Log packets with source addresses with no known route to kernel log. And according to '/usr/src/linux/Documentation/networking/ip-sysctl.txt': log_martians - BOOLEAN Log packets with impossible addresses to kernel log. log_martians for the interface will be enabled if at least one of conf/{all,interface}/log_martians is set to TRUE, it will be disabled otherwise -- Cheers, Carlos Robinson

Hey guys' I finally tried to compile the linux kernel from src for my first time. I took the simple steps as in: 1. make clean; make mrproper 2. make xconfig 3. make dep 4. make 5. make bzImage 6. make modules 7. make modules_install 8. make install 9. configure LILO or GRUB. 10.Optional - make clean (If you want to free up disk space) OK all seems to go well and take a while too. But during the 8th command, "make install" I get: fs/fs.o(.text+0xbc276): In function `user_get': : undefined reference to `reiserfs_permission_locked' fs/fs.o(.text+0xbc32a): In function `user_set': : undefined reference to `reiserfs_permission_locked' fs/fs.o(.text+0xbc3d1): In function `user_del': : undefined reference to `reiserfs_permission_locked' make: *** [vmlinux] Error 1 Hum' I have no idea what to think of this error/oops or how to read it. Is there an official SuSE kernel recompile how to? I reading: file:/usr/share/doc/howto/en/html/Kernel-HOWTO.html Any suggestions for me to help in the first time SuSE kernel compile? -- Micxz

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thursday 23 October 2003 12:31 pm, Micxz wrote:

Hey guys'

I finally tried to compile the linux kernel from src for my first time. I took the simple steps as in:

1. make clean; make mrproper 2. make xconfig 3. make dep 4. make 5. make bzImage 6. make modules 7. make modules_install 8. make install 9. configure LILO or GRUB. 10.Optional - make clean (If you want to free up disk space)

OK all seems to go well and take a while too. But during the 8th command, "make install" I get:

fs/fs.o(.text+0xbc276): In function `user_get': : undefined reference to `reiserfs_permission_locked'

fs/fs.o(.text+0xbc32a): In function `user_set': : undefined reference to `reiserfs_permission_locked'

fs/fs.o(.text+0xbc3d1): In function `user_del': : undefined reference to `reiserfs_permission_locked'

make: *** [vmlinux] Error 1

running suse8.1 I had less than stellar results using make xconfig (if I remember right the errors were similar to what you report), you might try make menuconfig instead good luck - -- dh Don't shop at GoogleGear.com! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE/mKhdBwgxlylUsJARAtpXAJ9zFt7/qqcquFYklcFhfDT8Uc2zRwCfRxLU ojQrhKP9j9dGfoF9VMqF45U= =SAtO -----END PGP SIGNATURE-----

I finally tried to compile the linux kernel from src for my first time. I took the simple steps as in:

1. make clean; make mrproper 2. make xconfig 3. make dep 4. make 5. make bzImage 6. make modules 7. make modules_install 8. make install 9. configure LILO or GRUB. 10.Optional - make clean (If you want to free up disk space)

wow.. i've been compiling my own kernel for a long time, and i've never seen anyone using that process (especially the 'make install').. what i've always done: 1. su to root (usually 'su -') 2. cd /usr/src 3. extract kernel source and/or apply any patches (if applying patches, i always created a new kernel source tree to apply them against) 4. ln -s linux-<kernelversion> linux 5. cd linux 6. vi Makefile (change EXTRAVERSION to something to make the kernel unique) 7. make menuconfig (always liked it better than xconfig) 8. make dep && make clean && make bzImage && make modules && \ make modules_install (the '&&' means that if any step fails, it stops the whole process) 9. cp arch/i386/boot/bzImage /boot/vmlinuz-<kernelversion> 10. cp System.map /boot/System.map-<kernelversion> 11. cp .config /boot/config-<kernelversion> 12. configure lilo/grub 13. boot into new kernel it's always been my understanding that 'make mrproper' wasn't something the end user should ever have to do and that it will basically give you a completely cleaned source tree (just like fresh from a tarball). i've also been told that you can drop the 'make modules' step and just do 'make modules_install', but i still do it out of habit. the reason i make a new kernel tree and change EXTRAVERSION in the Makefile is so that 'make modules_install' doesn't wipe out modules of a working kernel (in case something goes wrong). for instance, if i have a working 2.4.20-1, and i build 2.4.20-2 and it doesn't work, i want to be able to go back to 2.4.20-1 with no problems.

OK all seems to go well and take a while too. But during the 8th command, "make install" I get:

fs/fs.o(.text+0xbc276): In function `user_get': : undefined reference to `reiserfs_permission_locked'

fs/fs.o(.text+0xbc32a): In function `user_set': : undefined reference to `reiserfs_permission_locked'

fs/fs.o(.text+0xbc3d1): In function `user_del': : undefined reference to `reiserfs_permission_locked'

make: *** [vmlinux] Error 1

Hum' I have no idea what to think of this error/oops or how to read it. Is there an official SuSE kernel recompile how to? I reading: file:/usr/share/doc/howto/en/html/Kernel-HOWTO.html Any suggestions for me to help in the first time SuSE kernel compile?

if you're getting past 'make bzImage' and 'make modules', there shouldn't be any more compiling needed. perhaps there is something wrong with 'make install'? (never having used it, i can't be sure what it's supposed to do) -- trey

On Wednesday 22 October 2003 23:37, Kastus wrote:

On Wed, Oct 22, 2003 at 01:04:46PM -0700, Micxz wrote:

...

Has anyone else figured out what this was? Today I got:

Oct 22 12:54:50 mars kernel: martian source xx.xxx.xx.xxx from 127.0.0.1, on dev ppp0 Oct 22 12:54:50 mars kernel: ll header: 45:08:00:28

I recieved a dozen of those yesterday on my home system.

What's more strange, the company's Checkpoint firewall started receiving same spoofed packets this morning at 8.

Something weird is really going on on the Internet.

...

mars:~ # tcpdump -X -s 0 -n -vvv net 127.0.0.1 -i any tcpdump: WARNING: Promiscuous mode not supported on the "any" device tcpdump: listening on any 12:54:50.901690 127.0.0.1.80 > xx.xxx.xx.xxx.1947: R [tcp sum ok] 0:0(0) ack 1759903745 win 0 (ttl 126, id 61929, len 40) 0x0000 4500 0028 f1e9 0000 7e06 3050 7f00 0001 E..(....~.0P.... 0x0010 42f8 589d 0050 079b 0000 0000 68e6 0001 B.X..P......h... 0x0020 5014 0000 2468 0000 P...$h..

Where xx.xxx.xx.xxx is my dialup IP on ppp0. I'm not sure what this means and I cannot read much of this packet info. Does anyone know why it's happening?

It's an ack packet sent (or pretending to have been sent) from port 80 from a spoofed localhost address.

Yes, I'm getting a bunch of these on Sun machines, fortunately squelched by ipfilter, as well as on the SuSE machines. A timely reminder to tighten up your SuSEfirewall, I reckon. Some baleful scam in progress, no doubt, I'd be interested to hear more. Best Fergus

I got another question.

I have both FW_LOG_CRITICAL and FW_LOG_ALL set to "yes" but SuSEfirewall is not logging those spoofed packets from localhost.

Does it mean that kernel drops martian source packets before they reach iptables?

Thanks, -Kastus

-- Fergus Wilde Chetham's Library Long Millgate Manchester M3 1SB Tel: +44 161 834 7961 Fax: +44 161 839 5797 http://www.chethams.org.uk