How would i log the source MAC address w/ iptables?
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.
How would i log the source MAC address w/ iptables?
OK, i'm getting a lot of spoofed IP attacks from the internet and i'm wondering if theres a way to log the source MAC address? Now i see in my normal log it seems the MAC address seems the length of 2 which i'm guessing is the source and destination MAC, but, they're all the same which i'm sure would be because its probally my dsl router or isp's router mac address. So is there any way to log the originating mac address?
Anyway, depending on the type of attack/fall-out, in the end you better ignore spoofs because you then would be "tracing 'em up the wrong tree" :-]
If you OTOH are for instance hosting on commercial base and DOS attacks are filling the pipe, you talk to your ISP. They (are supposed to) know how to work their Cisco filtering, or will cut you off for a while to let it die down.
well thanks for the help, i'm sure i get a lot of more spoofed IP's than i realize in my logs, but these of course stand out because they're using private IP's. I just realized looking through these logs that they're all from src port 80 except from the last one, so maybe thats just from a misconfigured network? I remember checking my logs before and they weren't all from the same port, unfortianatly when i was creating a changelog script the other day i deleted all my logs so i can't post any of those, heres a little bit of what i have though. One last thing; in my old logs that i've lost, i've seen more than just the 192.168 network, i've seen 10.0.0 and i believe i've even seen 127.0.0, and my network is 10.0.0 so i know the majority which are 192.168 spoofs arent because of me.
Dec 11 16:08:39 gt kernel: SPOOFED IP: IN=eth1 OUT= MAC=00:e0:18:28:c3:d4:00:20:
6f:0d:e9:67:08:00 SRC=192.168.11.56 DST=00.00.00.00 LEN=40 TOS=0x00 PREC=0x00 T
TL=46 ID=19023 DF PROTO=TCP SPT=80 DPT=4681 WINDOW=32768 RES=0x00 ACK FIN URGP=0
This is all I can come up with, a crude attempt at passive fingerprinting mixed with a dash of log analyzing..:
# 00:20:6f(:0d:e9:67)=card by Flowpoint
# 00:e0:18(:28:c3:d4)=card by Asustek
# 08:00=IP dgram over ethernet
# Traffic received from IP.
# This traffic destined for 0.0.0.0?. Isn't routable. Can't be good. Block.
# No TOS bits set
# Got 46 hops left to reach destination
# Wintendo base TTL=128, NIX=64, so this host is # either 82(!) or 18 hops away.
# Looking at the way of IP ID incrementing I'm guessing we're pitted against a Wintendo box, but that isnt consistent with the rest of the PF (TTL, Windowsize).
# "Don't frag" set
(PROTO=TCP SPT=80 DPT=4681 )
# The windowsize would fit FTX, Netware(intel) or Unisys exactly.
# No reserved bits set.
# Acknowledge last action received from source, Im gonna close this connection.
# No urgency pointer bits set.
Anyway, I suggest you (in/fwd/out)block the usual IANA ranges associated with traffic that shouldnt be considered routable outside LAN's (depending on your network config).
This is from my chains:
#Section 3: Private Address Space
..and lo as well, since this can't be coming in on the eth interface...
thanks for the analysis, it cleared up some things for me, and btw the 00.00.00.00 was just what i replaced my IP with. And yah i am blocking those already except for the class D and E which i'll block now.
I've also taken a look at the log file to see if I can add some extra pointers on top of unSpawns informative post.
The Mac addresses are from:
Your inbound router "00:20:6f:0d:e9:67"
Your eth1 NIC "00:e0:18:28:c3:d4"
To trace the source you'll need access to each router hop from the source. "yes 18 of them" By looking at the arp cache you could trace a fresh attack in about 10 minutes. "which you won't have, this would be how the FBI would do it with the ISP's and telcos help"
The windows size would suggest that the source of the packets are on a good sized connection and the box is a NIX system of some sort.
The Packet size was = 40 bytes
The IP Header size was = 20 bytes
The IP Payload size = 20 bytes, including the IP header size.
So what does this say to me.
It looks like someone is trying to scan you with nmap or a similar utility to create log entries from a trusted service "httpd" without a TCP handshake taking place.
"However this type of scan would be of no use to someone unless they could have access to your LAN traffic via a promiscuous network card."
The payload tells us that it's unlikely to be a blind-man tcp injection attack. "i.e craft tcp packets from a spoofed address to break in"
It's probably one of your mates having a laugh, after you told em you had a stateful firewall up and logging.
thanks to both of you for all the info, one more question though, as long as i'm blocking all these spoofed address's i should be safe right? I mean, theres probally not anything along those lines of what their trying to do, that my logs arent picking up as long as i'm blocking all inbound with private IP's on my internet NIC. My logs log all private IP inbound attempts, all attempts with the new state to common ports i.e. 21,22,23,79,80; and logs all new states without the syn flag, not to mention all the packets that just die. So is there anything else i should be logging?
Can't think of anything, but when Im gonna deploy iptables (RSN) I'll be using the --log-prefix stuff to number/name my output for easier grepping, and --log-ip-options, --log-tcp-sequence and --log-tcp-options to make sure I get all the IP/TCP header stuff into the logs, might come in handy some day Im sure, cuz IMO its better to trim off later than to start with nearly nuttin...
Btw, for that 'lil bit extra, you might want to have a look at Snort, which extends logging capabilities into packet*load*, this way you've got a good view on what they're trying to ship (if any), like shellcode, worms and other malware "goodies". Making your own rules ain't that hard either.
well, from what i've read the netfilter module ipt_string can read the packet load, though it is experimental and i've already had 1 bad experience trying to get it running, i think i'll try again when i get some free time.