Re: msk0: watchdog timeout interface hang
On Wed, Jan 25, 2012 at 3:26 PM, Kim Culhan wrote: > Running 10-curent from 01-20-12 > the msk0 interface hung, on the console: > > msk0: watchdog timeout > msk0: prefetch unit stuck? > msk0: initialization failed: no memory for Rx buffers > > Verbose boot dmesg output attached. This additional datapoint found, at boot after the last line in the verbose dmesg this line was logged to messages: Jan 25 15:21:19 foo kernel: interrupt storm detected on "irq257:"; throttling interrupt source Hope this helps. thanks -kiim ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/145934: [patch] add count option to netstat(1)
The following reply was made to PR bin/145934; it has been noted by GNATS. From: Dmitry Banschikov To: bug-follo...@freebsd.org Cc: Subject: Re: bin/145934: [patch] add count option to netstat(1) Date: Thu, 26 Jan 2012 16:09:45 +0300 --001636ed74f71f7ceb04b76e18c4 Content-Type: text/plain; charset=ISO-8859-1 It seems, that this PR can be closed, as r202060 introduced similiar changes. -- Dmitry Banshchikov --001636ed74f71f7ceb04b76e18c4 Content-Type: text/html; charset=ISO-8859-1 It seems, that this PR can be closed, as r202060 introduced similiar changes.-- Dmitry Banshchikov --001636ed74f71f7ceb04b76e18c4-- ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: bin/145934: [patch] add count option to netstat(1)
Synopsis: [patch] add count option to netstat(1) State-Changed-From-To: open->closed State-Changed-By: pluknet State-Changed-When: Thu Jan 26 13:54:57 UTC 2012 State-Changed-Why: Close per submitter request. Similar functionality is available since 8.1 using the -q option. http://www.freebsd.org/cgi/query-pr.cgi?pr=145934 ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
stateful firewall implementation in FreeBSD
Hi, I have question regarding stateful firewall implementation of FreeBSD. IPF has stateful “keep state” option. Stateful filtering treats traffic as a bi-directional exchange of packets comprising a session conversation. When activated, keep-state dynamically generates internal rules for each anticipated packet being exchanged during the bi-directional session conversation. It has sufficient matching capabilities to determine if the session conversation between the originating sender and the destination are following the valid procedure of bi-directional packet exchange. Any packets that do not properly fit the session conversation template are automatically rejected as impostors. I have question regarding the size of the state table kept in FreeBSD for stateful packet inspection. Say we have a valid senario where we have stateful firewall rule for HTTP and we get lot of incoming new HTTP session and state table is filled full. In that case I guess FreeBSD would reject new sessions. Just want to know what is the latest on this. How does FreeBSD would handle if the state table is full and we get valid new HTTP connection. What are options in terms of configuration or new feature in BSD would address this issue. Thanks, Satish K Amara ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: stateful firewall implementation in FreeBSD
On 1/26/2012 12:24 PM, satish amara wrote: > Hi, > I have question regarding stateful firewall implementation of FreeBSD. > IPF has stateful “keep state” option. Hi, Take a look at pf, not ipf. ipf is not really maintained or used much any more under FreeBSD. With respect to dealing with congestion, there are many params you can tune in pf. Take a look at the man pages for pf.conf for details as you can control how this situation is dealt with to some degree. ---Mike -- --- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, m...@sentex.net Providing Internet services since 1994 www.sentex.net Cambridge, Ontario Canada http://www.tancsa.com/ ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: stateful firewall implementation in FreeBSD
Hi-- On Jan 26, 2012, at 9:24 AM, satish amara wrote: > I have question regarding the size of the state table kept in FreeBSD for > stateful packet inspection. Say we have a valid senario where we have > stateful firewall rule for HTTP and we get lot of incoming new HTTP session > and state table is filled full. In that case I guess FreeBSD would reject > new sessions. Just want to know what is the latest on this. How does > FreeBSD would handle if the state table is full and we get valid new HTTP > connection. What are options in terms of configuration or new feature in > BSD would address this issue. A securely designed firewall will drop connections when the state table is full. You can increase the size of the state table by following the IPF FAQ: http://www.phildev.net/ipf/IPFques.html#ques25 ...but in point of fact, keeping state for high-volume traffic is generally a losing game, and you are better off (IMHO) setting up stateless bidirectional rules which permit such high volume traffic. HTTP isn't generally too much of a problem, though-- something like a popular stratum-1 or 2 public NTP timeserver will easily blow out a stateful firewall if you try to keep state for NTP's UDP traffic. Regards, -- -Chuck ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: stateful firewall implementation in FreeBSD
On Thu, Jan 26, 2012 at 11:41 AM, Chuck Swiger wrote: > Hi-- > > On Jan 26, 2012, at 9:24 AM, satish amara wrote: >> I have question regarding the size of the state table kept in FreeBSD for >> stateful packet inspection. Say we have a valid senario where we have >> stateful firewall rule for HTTP and we get lot of incoming new HTTP session >> and state table is filled full. In that case I guess FreeBSD would reject >> new sessions. Just want to know what is the latest on this. How does >> FreeBSD would handle if the state table is full and we get valid new HTTP >> connection. What are options in terms of configuration or new feature in >> BSD would address this issue. > > A securely designed firewall will drop connections when the state table is > full. > > You can increase the size of the state table by following the IPF FAQ: > > http://www.phildev.net/ipf/IPFques.html#ques25 > > ...but in point of fact, keeping state for high-volume traffic is generally > a losing game, and you are better off (IMHO) setting up stateless > bidirectional > rules which permit such high volume traffic. > > HTTP isn't generally too much of a problem, though-- something like a popular > stratum-1 or 2 public NTP timeserver will easily blow out a stateful firewall > if you try to keep state for NTP's UDP traffic. To put it very clearly, a stateful firewall "protecting" a server is an open invitation to DOS. It is trivial to generate enough UDP traffic to overflow any limit on connections in a stateful firewall. Various tricks have been tried but the reality is that none has really succeeded. Some do help, but nowhere near enough to solve the problem. Stateful firewalls are for clients and systems that don't provide publicly accessible services. Servers require stateless filters along with IDS/IPS for effective protection. And I do expect to get people saying that you HAVE to have a stateful firewall is a basic requirement for a device on the Internet. I can only say htat I know of many well known servers that do not have them and few that do. There is a reason for that. At my old employer we were under government security oversight and I can remember the auditors back a few years ago who had a fit when told that no firewall was employed, just an IDS/IPS with RTBH. The problem is that their red team of attackers never could successfully attack which really annoyed them to the point that they tryed toi order that the IDS be disabled for their attack attempts. (We refused, siting terms of the testing agreement.) Today, auditors still are a bit surprised that they don't use a firewall, but are no longer upset by it as they are seeing it more often. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: stateful firewall implementation in FreeBSD
On Jan 27, 2012, at 4:41 AM, Kevin Oberman wrote: > On Thu, Jan 26, 2012 at 11:41 AM, Chuck Swiger wrote: >> Hi-- >> >> On Jan 26, 2012, at 9:24 AM, satish amara wrote: >>> I have question regarding the size of the state table kept in FreeBSD for >>> stateful packet inspection. Say we have a valid senario where we have >>> stateful firewall rule for HTTP and we get lot of incoming new HTTP session >>> and state table is filled full. In that case I guess FreeBSD would reject >>> new sessions. Just want to know what is the latest on this. How does >>> FreeBSD would handle if the state table is full and we get valid new HTTP >>> connection. What are options in terms of configuration or new feature in >>> BSD would address this issue. >> >> A securely designed firewall will drop connections when the state table is >> full. >> >> You can increase the size of the state table by following the IPF FAQ: >> >> http://www.phildev.net/ipf/IPFques.html#ques25 >> >> ...but in point of fact, keeping state for high-volume traffic is generally >> a losing game, and you are better off (IMHO) setting up stateless >> bidirectional >> rules which permit such high volume traffic. >> >> HTTP isn't generally too much of a problem, though-- something like a popular >> stratum-1 or 2 public NTP timeserver will easily blow out a stateful firewall >> if you try to keep state for NTP's UDP traffic. > > To put it very clearly, a stateful firewall "protecting" a server is > an open invitation to DOS. It is trivial to generate enough UDP > traffic to overflow any limit on connections in a stateful firewall. > Various tricks have been tried but the reality is that none has really > succeeded. Some do help, but nowhere near enough to solve the problem. > > Stateful firewalls are for clients and systems that don't provide > publicly accessible services. Servers require stateless filters along > with IDS/IPS for effective protection. > > And I do expect to get people saying that you HAVE to have a stateful > firewall is a basic requirement for a device on the Internet. I can > only say htat I know of many well known servers that do not have them > and few that do. There is a reason for that. At my old employer we > were under government security oversight and I can remember the > auditors back a few years ago who had a fit when told that no firewall > was employed, just an IDS/IPS with RTBH. The problem is that their red > team of attackers never could successfully attack which really annoyed > them to the point that they tryed toi order that the IDS be disabled > for their attack attempts. (We refused, siting terms of the testing > agreement.) > > Today, auditors still are a bit surprised that they don't use a > firewall, but are no longer upset by it as they are seeing it more > often. > -- > R. Kevin Oberman, Network Engineer > E-mail: kob6...@gmail.com > In my experience (and I've had a few DDoS attacks), the state table was never an issue (unless left at default settings), the machine would either die from interrupt/cpu overload, or the pipe will be filled. For example the pf(4) firewall can be tuned to have millions of state entries, then you can configure thresholds which reached will make the existing state entries expire sooner, leaving room for new ones. P.S.: Stateful firewalls are required by the PCI DSS (requirement 1.3.6) ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Ethernet Switch Framework
Ok, I do like the idea of: * mdiobus/miibus proxy tidyup; * then the switch API; * then the switch devices themselves. Can we get some consensus/agreement from Marius (and others) about the first step? Adrian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
