Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
This is the broadcast IP in hex: ff:ff:ff:ff:ff:ff (255.255.255.255)
This is the MAC address of the offending host: 00:0b:db:93:32:80
The last portion of the header "08:06" defines the type of traffic (ARP).
So what all that translates to, is that you are getting ARP broadcast traffic (which is normal) but it's coming from an IP address - interface combination that the kernel didn't expect. This can be due to a misconfigured host which has the wrong IP address. For example if your system is connected to two networks (say etho is connected to the 10.10.10.0/24 network and eth1 is connected to the 192.168.2.0/24 network). If you were to incorrectly assign a 192.168.0.0/24 address to a system on the 10.10.10.0/24 network, every time it sent packets to the linux box you'd get martian traffic messages because the linux box realizes that the source IP is wrong for that network.
The other side of this coin (and why you should absolutely never, never ignore martian traffic messages or turn off martian logging!!!) is because it can also be due to IP address spoofing. Which is a major red flag that someone is try to do some very nasty things to your network.
Either way, it's important to identify whether it's just a local machine that is misconfigured or if someone is spoofing traffic. If it's the first case, then you can just fix the host and the messages should stop. If it's not a misconfigured local machine, then you need to be on your toes and be alert to the fact that someone is trying to attack your network.
If you are seeing ARP traffic, it suggests that the traffic is coming from inside your network (ARP traffic shouldn't be forwarded from a remote system by properly configured routers).
Last edited by Capt_Caveman; 05-25-2004 at 02:23 PM.
I am confused as to what is going on so I will explain my setup a little more. I have a router as you mentioned that is NAT'd and the arp traffic is coming from the internal network which you seem to understand. eth0 is on the internet side of the router and eth1 is facing the internal network. The confusing thing is that the message is saying that the ip address that I have on eth0 is on eth1. You mentioned that this can happen if it is misconfigured but I did an ifconfig and none of the eth1 interfaces (I have virtual interfaces too) have the ip address that is being mentioned in the martian source message. The other thing is that there is evidence that one of the internal servers was tampered with by a hacker so I am trying to figure out if this error message is related and what can I do to trace why this is happening.
What you will be looking for then is a host inside the LAN the is mis-configured. Probably the best way to track it down will be by the MAC address from the log messages. As root just type arp and that should give you a dump of the current ARP table. Inside that table will be IP and MAC address mappings. If the MAC address from the martian logs (00:0b:db:93:32:80) is in the ARP table, you can likely figure out which host it is coming from. If the MAC isn't in there, you might be able to check the routers ARP table as well. It is possible that the MAC is spoofed as well, but I think that is unlikely.
As far as the compromised host, it's very likely to be the source. I hope that you have taken it offline, performed any forensics analysis you planned on doing, and completely reformated/reinstalled the system from trusted media (not a backup) before putting it back on the network. I'd check the MAC address on that machine as well, to see if it matches the martian entries.
I'm kind of confused about what you are saying about the IP address in the martian entry. Are you saying that the packets source IP was the IP address of the external interface on the linux box? In that case verify that the MAC address isn't one of the interfaces on the linux box.
As a side note, it might be interesting to see a full dump of the packets. As this could be a case of attempted ARP cache poisoning.
I actually have two routers, one is the main and one is the backup router if the primary goes down. They have one virtual ip on both the external side and the internal side that they both share.
The primary router has two interfaces:
<ip1> on eth0:1 - external virtual ip
<ip2> on eth1:1 - internal virtual ip
my internal computer has one interface
<ip3> on eth0
now the martian message says:
kernel: martian source <ip3> from <ip1>, on dev eth1
as you can see this is strange because <ip1> belongs to eth0 not eth1 plus the only logs I am getting of this martian message are from my backup router. Does this have to do with the virtual ip that they share.
I tracked the mac address to <ip2> on eth1 on the primary router.
Does this clear up any confusion and can you draw any more conclusions now. I am starting to believe that maybe something is misconfigured cause of this different setup. That would be a plus cause I am trying to determine if the hacker got access to any other internal computers.
Thank you for all your help, I really appreciate it.
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
It would help a lot more (for clarity) if you didn't censor the IP addresses. I know a lot of people think it's a "security risk" to post actual IPs on the Internet, but there isn't really much that can go wrong if you've properly configured your firewall (especially if you're only posting internal IPs and nothing Internet-routeable). As an alternative, you could just slightly modify the IPs you're using in the example (change 192.168 to 172.16 or something like that).
Basically it looks like you're getting packets on your external interface that have a source address of one of your internal machines. That's either a spoofing attempt, or a badly configured routing table.
If you could also post a description (or diagram) of your network topology, that would also help alot. If you have the primary and secondary routers sharing the same IP addresses, that would likely explain the martian messages, depending on how the network was configured.
I'm not entirely sure why you are seeing ARP traffic with the external IP on the routers internal interface, but considering that the traffic appears to be originating from inside the LAN, I don't believe that it's malicious. Usually assigning the same IP to two systems will cause martian messages and I have a feeling that having two systems with identical IPs on the LAN (eventhough the backup router has those IPs inactive) is the root of the problem. If this was a case of someone trying to inject nasty packets into the LAN, you'd expect to see martian messages on the primary router as well.
I'd also be concerned if the packets were originating from the previously compromised machine (btw you still have not mentioned if that system was properly cleaned and verified to be secure). If you have not properly taken care of that machine, then you definitely need to address that issue as someone could be spoofing MAC addresses (I doubt it, but it certainly is possible) and trying to trace the packets back to the source is pointless. Plus having a cracked system inside your LAN is a major security risk. However, I still think that the problem stems from having identical IPs assigned to the primary and secondary routers.
Thank you for all your input on this case. The martian messages are not originating from the compromised box.
As for the compromised machine, I completely formatted the box and re-installed from the installation CD like you recommended. I have been closely monitoring all the logs from each box and I am pretty sure that the situation has been contained.
My Linux Server is setup to run all HTTP/S protocols through a proxy server. Certain other ports, like game ports for example, are masqueraded. The firewall is configured to drop everything else. Eth0 is configured as the internal interface, and Eth1 as the external interface. Other miscellaneous information about my server is that it is a DHCP, local DNS, and mail server for my local network (192.168.0.x).
My Router is configured to dial the ADSL modem with my account information. Thus, my Router receives a dynamic IP address in addition to the 192.168.1.1 address it always has for HTTP administration.
So... when a Client PC (192.168.0.x) tries to access a web page, the following happens:
1) The request is sent to the proxy on Linux Server (eth0:192.168.0.3).
2) The proxy on Linux Server (via eth1:192.168.1.5) forwards the DNS resolution request to Router (xxx.xxx.xxx.xxx = dynamic IP address assigned after dialing the ADSL modem)
3) The web page is accessed and downloaded to the proxy on Linux Server.
4) The proxy on Linux server forwards the web page to the Client PC.
My question is this: Can martians be caused by the fact that Linux Server eth1:192.168.1.5 is receiving broadcast data intended for the 192.168.0.x network? In the same breath, can martians be caused by the fact that the Linux Server eth0:192.168.0.3 is receiving broadcast data intended for the 192.168.1.x network (the network that the Router and Linux Server eth1 are on)?
If the answer is "yes" to both of those, then I guess my problem is that I'm using two NICs on the same switch.