Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Distribution: Fedora, Debian, OpenSuSE and Android
Posts: 1,820
Rep:
Well said, and right on the money. I do make the assumption (wrongly I guess) that people learn Iptables the way I did, through reading the books and writing scripts themselves. I normally focus on the Internet as the biggest threat to our network, even though we could have problems from the inside. The reason behind the outside-in focus toward security is the sheer numbers of actual intrusion attempts we get from the Internet compared to the normal network problems we see, which is downloading porn and a bit of file sharing.
In my time working with Iptables I have found the following to be critical.
1. Write your own scripts!
2. If you don't understand what the script does (line by line) you cannot trust it!
3. Write a line - Test it - Write a line - Test again
3. Read the Books (I started with Red Hat Linux Firewalls which is pretty newbie friendly.
4. Use LQ when (not if) you get stuck, and always post the rule that is broken.
Chort, it is obvious to me you understand Iptables better than I, and for that I am thankful, expect future Iptables questions from me
Distribution: OpenBSD 4.6, OS X 10.6.2, CentOS 4 & 5
Posts: 3,660
Rep:
Quote:
Originally posted by Pcghost
1. Write your own scripts!
2. If you don't understand what the script does (line by line) you cannot trust it!
3. Write a line - Test it - Write a line - Test again
3. Read the Books (I started with Red Hat Linux Firewalls which is pretty newbie friendly.
4. Use LQ when (not if) you get stuck, and always post the rule that is broken.
Words to live by, especially the reading books part. You can't just copy some script and expect to know how to use a packet filter. If you don't understand the problem or the solution, there's a strong chance you're just making things worse. I would have to take issue with the comment about the Red Hat firewall, though. At least the Lokkit scripts I've seen were completely backwards (explicitly blocking ports instead of denying by default).
Quote:
Chort, it is obvious to me you understand Iptables better than I, and for that I am thankful, expect future Iptables questions from me
Hah, I'm thinking this is sarcasm because I certainly don't know iptables well at all (OpenBSD pf(4), or maybe a little PIX yes, but not iptables). I do know the fundamentals of packet filtering and building secure networks, though, and I've had a chance to see more firewalls than most people that don't do managed security or consulting (Checkpoint, PIX, Netscreen, Raptor, Gauntlet, etc).
Distribution: Fedora, Debian, OpenSuSE and Android
Posts: 1,820
Rep:
I forgot one fundamental rule.
The words lokkit and iptables should never be used in the same sentence. Red Hat Lokkit is one of the single worst crutches I have come across in dealing with iptables. The book I was referring to actually deals with iptables rules without emphasizing lokkit, which despite the fact that I don't use Red Hat much anymore, it is still a handy book to have. It explains the rules in newbie friendly terms.
Hmmm, so I get the "don't turn off martian logging" bit, it makes sense, but no where did anyone actually say how to make the martians stop. I'm getting the following message every 4 seconds...
May 24 00:20:27 KFEN kernel: martian source 255.255.255.255 from 192.168.0.1, on dev eth1
May 24 00:20:27 KFEN kernel: ll header: ff:ff:ff:ff:ff:ff:00:20:e0:0e:42:e6:08:00
Eth1 is the external interface, so it's not a problem with my internal network at least. Strange messages such as this make my boss nervous, so I have to do something about them. If not turn off the logging, what else can I do? I already told my firewall to block packets from 255.255.255.255 and 192.168.0.1 from the external interface, and they still haven't stopped.
Any help is appreciated, and I'm sorry for digging up an old thread, but it described my concerns rather well.
-Dewar
I think have a similar problem. My external interface is eth0 and my internal interface is eth1. My internal network is 192.168.0.0/24.
I keep getting
Code:
May 31 15:25:25 amun kernel: martian source 192.168.0.15 from 192.168.0.1, on dev eth1
May 31 15:25:25 amun kernel: ll header: ff:ff:ff:ff:ff:ff:00:40:05:2f:2d:03:08:06
(The first ip address always changes. It's an address from 192.168.0.10 to 192.168.0.24--the Windows XP client machines)
At this point, 192.168.0.15 can no longer access the Internet. To temporarily restore Internet access I ping 192.168.0.15 from 192.168.0.1 (firewall/router machine running Fedora Core 1). An "/etc/init.d/network restart" does the trick too. Once I do this, the martians stop for a while.
They come back after a few minutes of inactivity though, and they are always back the next morning. And no one has Internet access in the morning untill I get in to ping them from the router.
I am confused about the ll header. first of all ff:ff:ff:ff:ff:ff doesn't seem like a valid MAC address. Second, I can't find any device on my network with the MAC address of 00:30:05:2f:2d:03 (maye my ADSL modem?).
As for the 08:06, that means something, but I can't find out what.
The difference between my problem and yours is that it the problem is liste d on the internal interface. And I get a valid first ip address
Distribution: RedHat from 4 -9, Fedora, Ubuntu, Centos 3 - 7, Puppy Linux, and lots of raspberry pi
Posts: 142
Rep:
There are lots of people here who know a lot more than me, however if this helps, it was worth trying. (If it is wrong, please don't shoot me down!).
Are you using a cable modem rather than ADSL?
If so, your cable modem is part of a network (all the other cable modems in your area). My understanding is that you can receive a lot of traffic from compromised machines on your network (which would explain why some people see it on eth1 too). I get them all the time from my cable connection.
Oddly enough, my limited understanding says that they are called martian because they are alien to the network adapter - ie if they pretend to come from an internal ip , such as a 10.x .x..x and are recieved on an "external" network adapter - they are on the wrong side. If you receive an internal ip (again 192.168.x.x as an example) on an internal network adapter, I don't know why that would show up as martian.
But I guess that's why I'm not a serious techie!
Good luck and hope it helped and might have been correct
Distribution: Fedora, Debian, OpenSuSE and Android
Posts: 1,820
Rep:
As I may have mentioned, I get martian source messages all the time on my external interface at home. The Satellite modem is the cause, as it is on a cross-over cable to my firewall/proxy machine. This seems like a good time to recommend my two favorite software packages for Linux. The first is Snort, the packet-sniffer/intrusion detection system, and the second is tripwire, a file system monitor/intrusion detection system. Between the two, if set up correctly (LQ can help) you can sleep better at night. Always send the output to a different machine on your network, and only give the Snorted machine Insert rights on the SQL server if you go that way. This way if the box is compromised the attacker is less likely to be able to hide their tracks.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
