LinuxQuestions.org
Support LQ: Use code LQ3 and save $3 on Domain Registration
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Security
User Name
Password
Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.

Notices

Reply
 
Search this Thread
Old 12-11-2001, 04:16 PM   #1
phek
Member
 
Registered: Jul 2001
Location: California, US
Distribution: Slackware
Posts: 196

Rep: Reputation: 30
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?
 
Old 12-11-2001, 04:56 PM   #2
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,319
Blog Entries: 54

Rep: Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860
No, TCP/IP doesn't permit MAC addy's to travel outside the LAN.
 
Old 12-11-2001, 04:59 PM   #3
phek
Member
 
Registered: Jul 2001
Location: California, US
Distribution: Slackware
Posts: 196

Original Poster
Rep: Reputation: 30
crap, that sucks. there any other way to trace it back? i'm kinda clueless on how spoofing works.
 
Old 12-12-2001, 01:33 AM   #4
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,319
Blog Entries: 54

Rep: Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860
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.
 
Old 12-12-2001, 12:50 PM   #5
phek
Member
 
Registered: Jul 2001
Location: California, US
Distribution: Slackware
Posts: 196

Original Poster
Rep: Reputation: 30
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
 
Old 12-12-2001, 05:34 PM   #6
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,319
Blog Entries: 54

Rep: Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860
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...

Last edited by unSpawn; 12-12-2001 at 05:36 PM.
 
Old 12-12-2001, 06:52 PM   #7
phek
Member
 
Registered: Jul 2001
Location: California, US
Distribution: Slackware
Posts: 196

Original Poster
Rep: Reputation: 30
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.
 
Old 12-13-2001, 05:44 AM   #8
raz
Member
 
Registered: Apr 2001
Location: London
Posts: 408

Rep: Reputation: 31
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
 
Old 12-13-2001, 12:09 PM   #9
phek
Member
 
Registered: Jul 2001
Location: California, US
Distribution: Slackware
Posts: 196

Original Poster
Rep: Reputation: 30
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?
 
Old 12-13-2001, 04:22 PM   #10
unSpawn
Moderator
 
Registered: May 2001
Posts: 27,319
Blog Entries: 54

Rep: Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860Reputation: 2860
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.
 
Old 12-13-2001, 04:33 PM   #11
phek
Member
 
Registered: Jul 2001
Location: California, US
Distribution: Slackware
Posts: 196

Original Poster
Rep: Reputation: 30
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.
 
Old 12-14-2001, 10:39 AM   #12
d3funct
Member
 
Registered: Jun 2001
Location: Centralia, WA
Posts: 274

Rep: Reputation: 31
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
 
Old 12-14-2001, 12:18 PM   #13
phek
Member
 
Registered: Jul 2001
Location: California, US
Distribution: Slackware
Posts: 196

Original Poster
Rep: Reputation: 30
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
IPTABLES rules with mac address? xpathfinder Linux - Security 3 12-11-2005 09:23 PM
Iptables/Mac address InJesus Linux - Security 3 11-17-2005 05:57 AM
mac address log lyte Linux - Security 2 12-10-2004 09:14 PM
blocking mac address using iptables Kendo1979 Linux - Networking 9 10-25-2004 04:09 AM
MAC Address + IPTABLES yvesg Linux - Networking 1 05-10-2004 08:36 PM


All times are GMT -5. The time now is 09:32 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration