[Oisf-users] Question on combined protocols
Leonard Jacobs
ljacobs at netsecuris.com
Thu May 30 20:11:29 UTC 2013
Update on IPS mode and SonicWALL Adventail SSL VPN issues
SonicWALL looked at the pcaps we sent them. They say it looks like to them that the IPS is taking too long to disassemble the packets, reassemble, and forward them on. They also say their SSL VPN is RFC compliant now.
I am wondering if the SSL VPN traffic is being interrogate by all the signatures and that is just too slow. Is there a way to just bypass the SSL VPN traffic? Do I need to create a signature that just passes the traffic?
I still don't understand the console error message we get when there is SSL VPN traffic.
Thanks.
Leonard
_____
From: Leonard Jacobs [mailto:ljacobs at netsecuris.com]
To: 'Victor Julien' [mailto:lists at inliniac.net]
Cc: oisf-users at openinfosecfoundation.org
Sent: Mon, 27 May 2013 11:08:17 -0600
Subject: Re: [Oisf-users] Question on combined protocols
It did not seem to matter what the flow timeouts for tcp were set to. Error messages on console still appear when using the SSL VPN.
However, when we have both Linux bridging and af-packet IPS turned on, the SSL VPN works correctly without speed issues even though error warnings still appearing on console.
My concern is will the IPS actually drop packets based on signature despite the Linux bridging also passing the packet from interface to interface?
-----Original Message-----
From: Victor Julien [mailto:lists at inliniac.net]
Sent: Wednesday, May 15, 2013 5:28 AM
To: Leonard Jacobs
Cc: oisf-users at openinfosecfoundation.org
Subject: Re: [Oisf-users] Question on combined protocols
On 05/14/2013 08:50 PM, Leonard Jacobs wrote:
> So I am trying to understand the flow timeouts better. So flow
> timeouts are the maximum time Suricata has to process the packets,
> correct? So increasing the flow timeout gives a better chance to
> getting the packets completely processed, correct?
No, the flow timeout controls how long Suricata keeps tracking a flow after the last packet was received. So if you have a TCP connection that sees no packets for 1 hour, Suricata cleans it up internally. Each time a packet is received, the timer is reset.
If a packet comes in for a already cleaned up TCP session it will be rejected if you use the stream.inline option. This could cause connections to fail (time out).
> IPS takes longer to process packets than IDS, correct? Could explain
> why packets are being dropped and not making it through the processing
> chain so that the SSL VPN is not getting the packets, correct?
IPS may take a little bit more time per packet as we have to reinject/verdict them, but this is not related to flow timeouts.
Cheers,
Victor
>
> Thanks.
>
> Leonard
>
> ------------------------------------------------------------------------
> *From:* Victor Julien [mailto:lists at inliniac.net]
> *To:* oisf-users at openinfosecfoundation.org
> *Sent:* Tue, 14 May 2013 09:06:00 -0600
> *Subject:* Re: [Oisf-users] Question on combined protocols
>
> Btw you mail server still rejects my emails, very annoying to get an
> error each time I mail you:
>
> he original message was received at Tue, 14 May 2013 15:46:19 +0200
> from a80-101-90-58.adsl.xs4all.nl [80.101.90.58]
>
> ----- The following addresses had permanent fatal errors -----
> <ljacobs at netsecuris.com <mailto:ljacobs at netsecuris.com>>
> (reason: 550 5.7.1 Service unavailable; Client host [83.215.238.27]
> blocked using Trend Micro RBL+. Please
> s...ail-abuse.com/cgi-bin/lookup?ip_address=83.215.238.27; User defined
> policy matched for 83.215.238.27)
>
> ----- Transcript of session follows -----
> ... while talking to in.sjc.mx.trendmicro.com.:
> >>> DATA
> <<< 550 5.7.1 Service unavailable; Client host [83.215.238.27] blocked
> using Trend Micro RBL+. Please see
> http://www.mail-abuse.com/cgi-bin/lookup?ip_address=83.215.238.27; User
> defined policy matched for 83.215.238.27
> 550 5.1.1 <ljacobs at netsecuris.com
> <mailto:ljacobs at netsecuris.com>>... User unknown
> <<< 554 5.5.1 Error: no valid recipients
>
>
> On 05/14/2013 04:02 PM, Victor Julien wrote:
> > On 05/14/2013 02:52 PM, Leonard Jacobs wrote:
> >> According to references on the web, SonicWALL Adventail SSL VPN
> uses non-RFC compliant SSL VPN by using SOCKS over HTTPS. The
> references refer to problems similar to what we experience with
> af-packet IPS mode where packets are getting dropped (not due to IPS
> but just flow stops). When doing a packet capture, we see a lot of
> TCP Retransmissions. According to references, turning off statefull
> inspection for 443 on firewall solves the problem but Suricata is
> not a firewall so there is no stateful inspection.
> >>
> >> I am suggesting to the firewall folks that they need to turn off
> stateful inspection for this SSL VPN traffic because the SSL VPN
> device is in a DMZ on their firewall. They are checking with
> firewall vendor.
> >
> > Suricata's inspection is definitely stateful.
> >
> >> IDS mode with Suricata works fine.
> >>
> >> We have tried decreasing the TCP flow timeouts but that does not
> solve the problem. We have considered using an alternative IPS to
> Suricata as a test to see if the problem goes away.
> >
> > I would suggest /increasing/ the time outs, not decreasing.
> >
> >> Do you have any ideas or suggestions?
> >
> > To me it sounds like your SSL product is broken, so I'd push them
> for a
> > fix. If their answer is to disable stateful inspection, you know they
> > have problems for sure.
> >
> > Cheers,
> > Victor
> >
> >
> >>
> >> Thanks.
> >>
> >> -----Original Message-----
> >> From: oisf-users-bounces at openinfosecfoundation.org
> <mailto:oisf-users-bounces at openinfosecfoundation.org>
> [mailto:oisf-users-bounces at openinfosecfoundation.org
> <mailto:oisf-users-bounces at openinfosecfoundation.org>] On Behalf Of
> Victor Julien
> >> Sent: Tuesday, May 14, 2013 5:43 AM
> >> To: oisf-users at openinfosecfoundation.org
> <mailto:oisf-users at openinfosecfoundation.org>
> >> Subject: Re: [Oisf-users] Question on combined protocols
> >>
> >> On 05/13/2013 08:47 PM, Leonard Jacobs wrote:
> >>>
> >>> Would Suricata and af-packet in IPS mode have difficulty processing
> >>> network traffic using combined protocols such as SOCKS over HTTPS?
> >>
> >> It shouldn't have. Are you seeing problems?
> >>
> >> --
> >> ---------------------------------------------
> >> Victor Julien
> >> http://www.inliniac.net/
> >> PGP: http://www.inliniac.net/victorjulien.asc
> >> ---------------------------------------------
> >>
> >> _______________________________________________
> >> Suricata IDS Users mailing list:
> oisf-users at openinfosecfoundation.org
> <mailto:oisf-users at openinfosecfoundation.org>
> >> Site: http://suricata-ids.org | Support:
> http://suricata-ids.org/support/
> >> List:
> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> >> OISF: http://www.openinfosecfoundation.org/
> >>
> >
> >
>
>
> --
> ---------------------------------------------
> Victor Julien
> http://www.inliniac.net/
> PGP: http://www.inliniac.net/victorjulien.asc
> ---------------------------------------------
>
> _______________________________________________
> Suricata IDS Users mailing list:
> oisf-users at openinfosecfoundation.org
> <mailto:oisf-users at openinfosecfoundation.org>
> Site: http://suricata-ids.org | Support:
> http://suricata-ids.org/support/
> List:
> https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
> OISF: http://www.openinfosecfoundation.org/
>
>
>
--
---------------------------------------------
Victor Julien
http://www.inliniac.net/
PGP: http://www.inliniac.net/victorjulien.asc
---------------------------------------------
_______________________________________________
Suricata IDS Users mailing list: oisf-users at openinfosecfoundation.org
Site: http://suricata-ids.org | Support: http://suricata-ids.org/support/
List: https://lists.openinfosecfoundation.org/mailman/listinfo/oisf-users
OISF: http://www.openinfosecfoundation.org/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openinfosecfoundation.org/pipermail/oisf-users/attachments/20130530/93882d87/attachment-0002.html>
More information about the Oisf-users
mailing list