7:39 a.m.
Hi,
When a network interface goes into promiscuous mode, its an important security
issue. The attached patch is intended to capture that action and send an
event to the audit system.
The patch carves out a new block of numbers for kernel detected anomalies.
These are events that may indicate suspicious activity. Other examples of
potential kernel anomalies would be: exceeding disk quota, rlimit violations,
changes to syscall entry table.
Signed-off-by: Steve Grubb <sgrubb(a)redhat.com>
8:54 a.m.
New subject: [redhat-lspp] [PATCH] promiscuous mode
On Sat, 2005-12-03 at 08:39 -0500, Steve Grubb wrote:
@@ -2121,6 +2122,12 @@ void dev_set_promiscuity(struct net_devi
printk(KERN_INFO "device %s %s promiscuous mode\n",
dev->name, (dev->flags & IFF_PROMISC) ?
"entered" :
"left");
+ audit_log(current->audit_context, GFP_KERNEL,
+ AUDIT_ANOM_PROMISCUOUS,
+ "dev=%s prom=%d old_prom=%d auid=%u",
+ dev->name, (dev->flags & IFF_PROMISC),
+ (old_flags & IFF_PROMISC),
+ audit_get_loginuid(current->audit_context));
}
}
Looking at this printk(KERN_INFO ...) and audit_log(...).
As long as it's just a small handful of isolated anomalous events that
we need to feed to the audit subsystem, I think we'll be okay. But if
we start following lots of printk(KERN_INFO ...) calls with
audit_log(...) calls, we should probably consider if the printk() should
just do the audit_log() if some auditing flag has been raised.
This isn't bothering me yet, but something to think about if there are
dozens of places in the kernel that start calling printk and audit_log.
:-Dustin
--
Dustin Kirkland <dustin.kirkland(a)us.ibm.com>
9:04 a.m.
New subject: [redhat-lspp] [PATCH] promiscuous mode
On Monday 05 December 2005 09:54, Dustin Kirkland wrote:
This isn't bothering me yet, but something to think about if
there are
dozens of places in the kernel that start calling printk and audit_log.
The only places I want to get my hands on are: promiscuous mode change, quota
violations, and rlimit violations. Its a short list.
-Steve
9:07 a.m.
New subject: [redhat-lspp] [PATCH] promiscuous mode
On Mon, 2005-12-05 at 10:04 -0500, Steve Grubb wrote:
The only places I want to get my hands on are: promiscuous mode
change, quota violations, and rlimit violations. Its a short list.
In which case I think your approach is fine.
:-Dustin
9:16 a.m.
New subject: [redhat-lspp] [PATCH] promiscuous mode
Hi Steve,
Why these three?
-- ljk
Steve Grubb wrote:
On Monday 05 December 2005 09:54, Dustin Kirkland wrote:
>This isn't bothering me yet, but something to think about if there are
>dozens of places in the kernel that start calling printk and audit_log.
The only places I want to get my hands on are: promiscuous mode change, quota
violations, and rlimit violations. Its a short list.
-Steve
--
redhat-lspp mailing list
redhat-lspp(a)redhat.com
https://www.redhat.com/mailman/listinfo/redhat-lspp
9:33 a.m.
New subject: [redhat-lspp] [PATCH] promiscuous mode
On Monday 05 December 2005 10:16, Linda Knippers wrote:
Why these three?
Because quota and rlimit events represent violations of system resource usage
policy set forth by the administrator. I want promiscuous mode because that
means the user is now capable of sniffing passwords and other important
traffic.
-Steve
9:48 a.m.
New subject: [redhat-lspp] [PATCH] promiscuous mode
Steve Grubb wrote:
On Monday 05 December 2005 10:16, Linda Knippers wrote:
>Why these three?
Because quota and rlimit events represent violations of system resource usage
policy set forth by the administrator.
They aren't really violations of a policy because the operation didn't
succeed. Its really a case of someone bumping into a resource limit.
Isn't that why for quotas the message just goes to the user's tty
rather than to syslog?
I want promiscuous mode because that
means the user is now capable of sniffing passwords and other important
traffic.
I'd want to know of some other system on my network went into
promiscuous mode, but that system probably isn't being being
audited. :-)
-- ljk
-Steve
10:04 a.m.
New subject: [redhat-lspp] [PATCH] promiscuous mode
On Monday 05 December 2005 10:48, Linda Knippers wrote:
> Because quota and rlimit events represent violations of system
resource
> usage policy set forth by the administrator.
They aren't really violations of a policy because the operation didn't
succeed.
Just like my editing of /etc/shadow from a normal account won't succeed.
Its really a case of someone bumping into a resource limit.
This is also a known sign of potential intrusion. There needs to be some more
investigation of the circumstances surrounding it, but almost all intrusion
detection system look at both of these.
Isn't that why for quotas the message just goes to the user's
tty
rather than to syslog?
If it went to syslog, it would go to all users. That is not desirable and an
easy way to DoS someone else on the same machine. The messages can scroll so
fast that you can see what you are typing.
I'd want to know of some other system on my network went into
promiscuous mode, but that system probably isn't being being
audited. :-)
That's the basic idea. The events go to a central audit log analyzer in the
data center and the admin can see that a particular machine went into
promiscuous mode.
-Steve
2:11 p.m.
New subject: [redhat-lspp] [PATCH] promiscuous mode
On Mon, 2005-12-05 at 11:04 -0500, Steve Grubb wrote:
> I'd want to know of some other system on my network went
into
> promiscuous mode, but that system probably isn't being being
> audited. :-)
That's the basic idea. The events go to a central audit log analyzer in the
data center and the admin can see that a particular machine went into
promiscuous mode.
If a hostile user puts a machine in promiscuous mode then it's most
likely that the security of the machine in question has been broken, and
there is a possibility that a hostile device has been connected to the
network. In either case it seems likely that an audit message won't
propagate to a central server.
The real solution to this (IMHO) is smart switches that don't permit ARP
spoofing etc.
2:17 p.m.
New subject: [redhat-lspp] [PATCH] promiscuous mode
On Mon, 2005-12-05 at 10:48 -0500, Linda Knippers wrote:
> Because quota and rlimit events represent violations of system
resource usage
> policy set forth by the administrator.
They aren't really violations of a policy because the operation didn't
succeed. Its really a case of someone bumping into a resource limit.
Isn't that why for quotas the message just goes to the user's tty
rather than to syslog?
I think that the real issue is that quota violations are an issue of
quantity that can happen to anyone while inappropriate file access won't
happen in normal use.
If a user has a quota of 100M why should 100M of data be an audit event
while 99M isn't? Surely if you want to deal with such things then
tracking behavior and looking for anomalies is the thing to do. If a
user goes from having only 5M used fir a year to suddenly having 99M
used then it's an event that is interesting regardless of whether their
quota is 99M or 1G. It seems to me that monitoring quota is a good task
for an IDS system (which could then use the audit system to log what it
considers useful).
2:44 p.m.
New subject: [redhat-lspp] [PATCH] promiscuous mode
On 12/5/05, Russell Coker <rcoker(a)redhat.com> wrote:
On Mon, 2005-12-05 at 10:48 -0500, Linda Knippers wrote:
> > Because quota and rlimit events represent violations of system resource usage
> > policy set forth by the administrator.
>
> They aren't really violations of a policy because the operation didn't
> succeed. Its really a case of someone bumping into a resource limit.
> Isn't that why for quotas the message just goes to the user's tty
> rather than to syslog?
I think that the real issue is that quota violations are an issue of
quantity that can happen to anyone while inappropriate file access won't
happen in normal use.
If a user has a quota of 100M why should 100M of data be an audit event
while 99M isn't? Surely if you want to deal with such things then
tracking behavior and looking for anomalies is the thing to do. If a
user goes from having only 5M used fir a year to suddenly having 99M
used then it's an event that is interesting regardless of whether their
quota is 99M or 1G. It seems to me that monitoring quota is a good task
for an IDS system (which could then use the audit system to log what it
considers useful).
Would this Statistical Anomaly Detection System need to have a hold of
similar auditing calls that libaudit is looking at? On its simplest it
could do a 'du -sc $registered_directory' but would any kernel level
auditing areas be needed? This is asked from the very naive viewpoint,
that this problem could be similar to the one mentioned last month
about tracking 'audit' state of millions of files on a system inside
of a directory.
--
Stephen J Smoogen.
CSIRT/Linux System Administrator
4 p.m.
On Sat, 3 Dec 2005, Steve Grubb wrote:
Hi,
When a network interface goes into promiscuous mode, its an important security
issue. The attached patch is intended to capture that action and send an
event to the audit system.
Can you please trace these patches directly back to requirements?
- James
--
James Morris
<jmorris(a)redhat.com>
9:18 a.m.
On Saturday 03 December 2005 08:39, Steve Grubb wrote:
When a network interface goes into promiscuous mode, its an
important
security issue. The attached patch is intended to capture that action and
send an event to the audit system.
I think we need to decide on this patch. Include it or not?
I think the best reason to include it is that when an interface goes into
promiscuous mode, the user can see packets for any role and sensitivity
regardless of what they are currently using. This message would note that an
exception to the information normal flow rules has occurred and is
potentially being captured to a file of unknown role and sensitivity.
-Steve
6946
days inactive
6958
days old
linux-audit@lists.linux-audit.osci.io
12 comments
6 participants
participants (6)
-
Dustin Kirkland -
James Morris -
Linda Knippers -
Russell Coker -
Stephen J. Smoogen -
Steve Grubb