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?

No, TCP/IP doesn't permit MAC addy's to travel outside the LAN.

crap, that sucks. there any other way to trace it back? i'm kinda clueless on how spoofing works.

You could be DOSsed yourself, but you *could* also be seeing the "fall-out" from an attack on others.
It would be kewl if you could post a piece of sanitized log... (keep your own IP addy out of it).

For some explanation on spoofing here's Phrack's good 'ol "IP spoofing demistified".

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

Dec 11 16:08:59 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.63 DST=00.00.00.00 LEN=40 TOS=0x00 PREC=0x00 TTL=46 ID=31377 DF PROTO=TCP SPT=80 DPT=25328 WINDOW=32768 RES=0x00 ACK FIN URGP=0

Dec 11 16:09:22 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.63 DST=00.00.00.00 LEN=40 TOS=0x00 PREC=0x00 TTL=46 ID=57638 DF PROTO=TCP SPT=80 DPT=25328 WINDOW=32768 RES=0x00 ACK FIN URGP=0

Dec 11 16:09:46 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.63 DST=00.00.00.00 LEN=40 TOS=0x00 PREC=0x00 TTL=46 ID=57640 DF PROTO=TCP SPT=80 DPT=25328 WINDOW=32768 RES=0x00 ACK FIN URGP=0

Dec 11 16:10:13 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 TTL=46 ID=64788 DF PROTO=TCP SPT=80 DPT=4681 WINDOW=32768 RES=0x00 ACK FIN URGP=0

Dec 11 17:36:24 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.1.2 DST=00.00.00.00 LEN=78 TOS=0x00 PREC=0x00 TTL=115 ID=37292 PROTO=UDP SPT=137 DPT=137 LEN=58

This is all I can come up with, a crude attempt at passive fingerprinting mixed with a dash of log analyzing..:

MAC=00:e0:18:28:c3:d4:00:20:6f:0d:e9:67:08:00
# 00:20:6f(:0d:e9:67)=card by Flowpoint
# 00:e0:18(:28:c3:d4)=card by Asustek
# 08:00=IP dgram over ethernet

SRC=192.168.11.56
# Traffic received from IP.

DST=00.00.00.00
# This traffic destined for 0.0.0.0?. Isn't routable. Can't be good. Block.

(LEN=40 )

TOS=0x00 PREC=0x00
# No TOS bits set

TTL=46
# Got 46 hops left to reach destination
# Wintendo base TTL=128, NIX=64, so this host is # either 82(!) or 18 hops away.

ID=19023
# 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).

DF
# "Don't frag" set

(PROTO=TCP SPT=80 DPT=4681 )

WINDOW=32768
# The windowsize would fit FTX, Netware(intel) or Unisys exactly.

RES=0x00
# No reserved bits set.

ACK FIN
# Acknowledge last action received from source, Im gonna close this connection.

URGP=0
# 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
CLASS_B="172.16.0.0/12"
CLASS_C="192.168.0.0/16"
CLASS_D_MULTICAST="224.0.0.0/4"
CLASS_E_RESNET="240.0.0.0/5"
BROADCAST_SRC="0.0.0.0"
BROADCAST_DEST="255.255.255.255"
..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.

Hi phek,

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.

also note:
(LEN=40 )
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"

Conclusion:
It's probably one of your mates having a laugh, after you told em you had a stateful firewall up and logging.

/Raz

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.

If you have IPtables running or are going to get it going, add this to your script. This is from the IPTABLES tutorial .

##########################
# PREROUTING chain.
#
# Do some checks for obviously spoofed IP's
#

$IPTABLES -t nat -A PREROUTING -i $INET_IFACE -s 192.168.0.0/16 -j DROP
$IPTABLES -t nat -A PREROUTING -i $INET_IFACE -s 10.0.0.0/8 -j DROP
$IPTABLES -t nat -A PREROUTING -i $INET_IFACE -s 172.16.0.0/12 -j DROP

yah i've already got that, one thing though, its NEVER a good thing to put DROPS/REJECTS/ACCEPTS in your prerouting or postrouting table, it can cause strange things to happen.