Date: Wed, 12 May 1999 07:06:39 -0700 From: Cy Schubert - ITSD Open Systems Group <Cy.Schubert@uumail.gov.bc.ca> To: Jim Cassata <jim@web-ex.com> Cc: freebsd-security@FreeBSD.ORG Subject: Re: new type of attack? Message-ID: <199905121406.HAA09671@cwsys.cwsent.com> In-Reply-To: Your message of "Tue, 11 May 1999 18:57:38 EDT." <Pine.BSF.4.10.9905111458590.63800-100000@Homer.Web-Ex.com>
index | next in thread | previous in thread | raw e-mail
In message <Pine.BSF.4.10.9905111458590.63800-100000@Homer.Web-Ex.com>,
Jim Cas
sata writes:
> i just received this....
>
> > We have been tracking a long series of subtle network probes that
> >use TCP packets constructed with ACK and RST bits set. This bit
> >combination allows these packets to pass through common packet filters.
> >The attackers have breached many systems around the net, focusing on
> >Linux and FreeBSD systems. These breached systems are used to either
> >receive directly or through packet sniffing the responses from forged
> >packets sent by the attackers. On Sunday (5-9-99), we collected some
> >probe packets from address 209.54.43.133. This host is called
> >sex.fiend.cx and appears to be part of your network. There is a strong
> >possiblity that this host or one very near it has been breached and is
> >being used to collect data probed from other networks. Our logs go back
> >over a month and this is the first time this particular host has been
> >seen on our network. The attackers seem to be able to move on to new
> >systems very quickly as there are apparently plenty of vulnerable
> >systems to breach. Our mail server was breached back in December and
> >was used for similar activities for 2 days. The attackers created 2
> >accounts, udp and reboot. The udp account had root privs and no
> >password.
> >
> >The time of the probe was 14:05 CDT
>
> has anyone seen this kind of thing?
A lot of this depends on how well your packet filter rules are
structured to mitigate the effectiveness of this kind of probing.
Disallowing all outgoing sessions (any and all sessions), except
through a bastion host on a DMZ, would be the best approach. The other
approach would be to place the rules that allow outgoing packets with
SYN at the end of the rule list prior to the global deny rule. All of
this would, of course, depend on the rules prior to the last few rules.
In other words there is no band-aid solution. Your rules need to be
carefully thought out and in a sequence that will make each one
effective, especially the last ones.
Regards, Phone: (250)387-8437
Cy Schubert Fax: (250)387-5766
Open Systems Group Internet: Cy.Schubert@uumail.gov.bc.ca
ITSD Cy.Schubert@gems8.gov.bc.ca
Province of BC
"e**(i*pi)+1=0"
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199905121406.HAA09671>