What is the biggest attack in GBPS you stopped
-
https://forum.pfsense.org/index.php?topic=24337.0
Very interesting thread!
Do we have any that have something else than em driver nics on the boxes?
So it's a driver and an OS issue, you don't say? ;D
-
We dont know yet since we have tuned the damn thing hence a lot of numbers dont add up in the default settings in pfsense.
So we are working on it :D
-
I do think the last link you posted was excellent with a lot of good discussion, and it might be worth testing non-em boxes. All of my interfaces are em's, so I won't be able to help.
-
I've got a usb2 10/100 plugable.com usb nic currently on my wan interface which I can swap with a gigabit usb3 plugable.com usb nic if need be as well as a sole onboard intel nic built into my little Intel D847 dual core celeron with 8Gb of ram and 30Gb msata ssd, so I can test all 3 formats to see how the different network drivers work on the same system by reassigning the wan interface. Avg CPU load is between 30-40% since installing the latest version of snort on it the other day so it should fall over quite quickly without any system tuning if this thread is anything to go by.
I can do it tomorrow later on in the morning as have appointments first thing as I've now found about about dangling states which was holding me up.
-
I've got a usb2 10/100 plugable.com usb nic currently on my wan interface which I can swap with a gigabit usb3 plugable.com usb nic if need be as well as a sole onboard intel nic built into my little Intel D847 dual core celeron with 8Gb of ram and 30Gb msata ssd, so I can test all 3 formats to see how the different network drivers work on the same system by reassigning the wan interface. Avg CPU load is between 30-40% since installing the latest version of snort on it the other day so it should fall over quite quickly without any system tuning if this thread is anything to go by.
I can do it tomorrow later on in the morning as have appointments first thing as I've now found about about dangling states which was holding me up.
Make sure you know exactly which drivers are loading up to support the interface. Some commands to run in FreeBSD to help:
pciconf -lvThat will list the interfaces and classify them for you. Also go to /var/log/dmesg.boot to see your last boot log. You'll see a section in there that will look something like this:
em0: <intel(r) 1000="" pro="" network="" connection="" 7.4.2="">port 0xf060-0xf07f mem 0xf7c00000-0xf7c1ffff,0xf7c38000-0xf7c38fff irq 20 at device 25.0 on pci0 em0: Using an MSI interrupt ehci0: <intel panther="" point="" usb="" 2.0="" controller="">mem 0xf7c37000-0xf7c373ff irq 16 at device 26.0 on pci0 usbus1: EHCI version 1.0 usbus1 on ehci0 hdac0: <intel panther="" point="" hda="" controller="">mem 0xf7c30000-0xf7c33fff irq 22 at device 27.0 on pci0 pcib1: <acpi pci-pci="" bridge="">irq 16 at device 28.0 on pci0 pci1: <acpi pci="" bus="">on pcib1 em1: <intel(r) 1000="" pro="" network="" connection="" 7.4.2="">port 0xe000-0xe01f mem 0xf7bc0000-0xf7bdffff,0xf7b00000-0xf7b7ffff,0xf7be0000-0xf7be3fff irq 16 at device 0.0 on pci1 em1: Using MSIX interrupts with 3 vectors pcib2: <acpi pci-pci="" bridge="">irq 16 at device 28.4 on pci0 pci2: <acpi pci="" bus="">on pcib2 em2: <intel(r) 1000="" pro="" network="" connection="" 7.4.2="">port 0xd000-0xd01f mem 0xf7ac0000-0xf7adffff,0xf7a00000-0xf7a7ffff,0xf7ae0000-0xf7ae3fff irq 16 at device 0.0 on pci2 em2: Using MSIX interrupts with 3 vectors pcib3: <acpi pci-pci="" bridge="">irq 18 at device 28.6 on pci0 pci3: <acpi pci="" bus="">on pcib3 em3: <intel(r) 1000="" pro="" network="" connection="" 7.4.2="">port 0xc000-0xc01f mem 0xf7900000-0xf791ffff,0xf7920000-0xf7923fff irq 18 at device 0.0 on pci3 em3: Using MSIX interrupts with 3 vectors</intel(r)></acpi></acpi></intel(r)></acpi></acpi></intel(r)></acpi></acpi></intel></intel></intel(r)>And of course the ever popular ifconfig.
FreeBSD loads NIC drivers (I think) from the kernel, so it might take some hunting to determine which ones are being used.
-
Who can hit me with the attack? There are few scenarios I would like to see how they respond. Can someone PM or email with available timezone so we could try a few of them ?
F.
-
Who can hit me with the attack? There are few scenarios I would like to see how they respond. Can someone PM or email with available timezone so we could try a few of them ?
F.
Supermule can execute the attack. He's UTC + 1.
-
My skype name is: kontaktnetsupply
Its a lot easier that way :)
-
Just be aware everything you give out over Skype will be investigated by MS as per the Skyper agreement before you installed Skype, which means any web addresses, private ip addresses will see at least the Bing bot turning up at.
-
I know mate.
:)
Exactly the reason why I removed my webcam and microphone :D
The material shared over skype has nothing valuable in it.
-
Make sure you know exactly which drivers are loading up to support the interface. Some commands to run in FreeBSD to help:
[b]pciconf -lv[/b]em0@pci0:0:25:0: class=0x020000 card=0x20448086 chip=0x15038086 rev=0x04 hdr=0x00
class = network
subclass = ethernetThe usb nics are not visible only the USB hubs they are plugged into.
That will list the interfaces and classify them for you. Also go to /var/log/dmesg.boot to see your last boot log. You'll see a section in there that will look something like this:
Motherboard nic
em0: <intel(r) 1000="" pro="" network="" connection="" 7.4.2="">port 0xf080-0xf09f mem 0xf7c00000-0xf7c1ffff,0xf7c29000-0xf7c29fff irq 20 at device 25.0 on pci0
em0: Using an MSI interruptUsb nics ue0 to ue3 same as below have not plugged in the gigabit ones yet.
ukphy0: <generic ieee="" 802.3u="" media="" interface="">PHY 16 on miibus0
ukphy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
ue0: <usb ethernet="">on axe0And of course the ever popular ifconfig.
FreeBSD loads NIC drivers (I think) from the kernel, so it might take some hunting to determine which ones are being used.
em0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=4209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso>ether
inet6 em0 prefixlen 64 scopeid 0x1
inet 192.168.37.1 netmask 0xffffff00 broadcast 192.168.37.255
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (1000baseT <full-duplex>)
status: active
ue0: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=80008 <vlan_mtu,linkstate>ether
inet6 ue0 prefixlen 64 scopeid 0x6
inet 192.168.1.1 netmask 0xffffff00 broadcast 192.168.1.255
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
ue1: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=80008 <vlan_mtu,linkstate>ether
inet6 ue1 prefixlen 64 scopeid 0x7
inet 192.168.60.1 netmask 0xffffff00 broadcast 192.168.60.255
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
ue2: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
options=80008 <vlan_mtu,linkstate>ether
inet6 ue2 prefixlen 64 scopeid 0x8
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
status: active
ue3: flags=8943 <up,broadcast,running,promisc,simplex,multicast>metric 0 mtu 1500
options=80008 <vlan_mtu,linkstate>ether
inet6 ue3 prefixlen 64 scopeid 0x9
inet 192.168.50.50 netmask 0xffffff00 broadcast 192.168.50.255
nd6 options=21 <performnud,auto_linklocal>media: Ethernet autoselect (100baseTX <full-duplex>)
status: activeIf you need any other info let me know.
Supermule if you want to hit me up, my ip is currently 92.29.124.124, VMware is recording the dashboard so traffic graphs for the interfaces, system activity and Status: System logs: Firewall (Dynamic View), with packet capture running on wan. Current CPUP load is 41 as if with nothing really happening other than those browser windows running along with snort so off to make a cup of tea. ;)</full-duplex></performnud,auto_linklocal></vlan_mtu,linkstate></up,broadcast,running,promisc,simplex,multicast></full-duplex></performnud,auto_linklocal></vlan_mtu,linkstate></up,broadcast,running,simplex,multicast></full-duplex></performnud,auto_linklocal></vlan_mtu,linkstate></up,broadcast,running,promisc,simplex,multicast></full-duplex></performnud,auto_linklocal></vlan_mtu,linkstate></up,broadcast,running,promisc,simplex,multicast></full-duplex></performnud,auto_linklocal></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso></up,broadcast,running,promisc,simplex,multicast></usb></generic></intel(r)>
-
Oh and whilst I remember, the wan interface is currently one of the USB nics, the EM0 (Intel nic) using the same drivers as you guys reporting problems is the lan interface so this first test will in effect be a driver test before I swap the wan on the EM0 nic.
-
Hitting you up on port 80 :)
Is it pingable and NAT'ing to something behind it?
-
You can stop it now for that ip address as I'm on another one.
I dont think it was pingable we could for the next test make it pingable but the problem with ADSL is its faster down than up so you may not get consistent pings back anyway.
When you say NAT'able what do you mean by that?
I tried a variety of different settings throughout, like trying to access ip addresses that were closer to me than the ip addresses coming in to port 80, swapped the firewall optimisation around from aggressive to normal to high latency (satellite links) whilst trying to get out but no joy at getting any webpages up throughout, the odd DNS request packet got out seen as a green icon in the dynamic fw log.
Interestingly it seemed to max out at 2.42Mbps yet various speed tests suggest I have a 5Mbps adsl connection. CPU was 100% through out.
FW stayed responsive throughout with snort running, changing various rules made some of the dashboard interface graphs stop updating second by second to maybe updating 10seconds later but I get that anyway when updating some rules or changing things in snort.
The only time I managed to kill the fw was trying to load the RRD graphs for All just a moment ago with the other fw webpages (dashboard, system activity, dynamic fw log) opened along with one or two other fw webpages open when changing rules etc, otherwise I'd have stayed on the old ip address for longer trying different things.
I got to pop out for an hour or so now, but when I get back we can try swapping the USB nic currently handling the wan interface over to the motherboards built in intel nic (em0) to test the driver theory next if you want?
It was funny because this song below was playing in my head throughout the test when I popped my head in to look at the fw as I was cooking some breakfast and eating it at the same time. ;)
www.youtube.com/watch?v=ZHwVBirqD2s
Edit. I could put one of the webservers I have written up if you want port 80 open, but I'd need to load up the relevant vm which I programmed it on and I have hundreds of vm's to go through as I'm in the processes of getting rid of old one's copying necessary code off them where applicable and generally consolidating them which is a lengthy process as I need to make sure I havent missed any source code, dll's, icons, images, help files, etc etc before deleting the vm.
-
No worries mate. Let me know when youre ready. :)
-
The only time I managed to kill the fw was trying to load the RRD graphs for All just a moment ago with the other fw webpages (dashboard, system activity, dynamic fw log) opened along with one or two other fw webpages open when changing rules etc, otherwise I'd have stayed on the old ip address for longer trying different things.
Something to note: When emX runs out of stated the entire pfSense device becomes sluggish. When you increase the states to over 5M, the emX interface goes down but the pfSense box is unaffected.
The console will show the state table getting filled in the first example and during the second test you may see the IRQ interrupt storm. I strongly recommend having the console open during testing because you'll get much more tangible information during testing. I sent almabes a ton of performance links and FreeBSD commands yesterday that should really help. I'm giving him time to digest them and eventually post them.
-
Ran 8M states and it performed well during the tests when it stayed up.
I dont see interrupt storms on the console. I have had a kernel taskq on the core that rises to 100% usage and then packet loss.
-
This is one of the links I sent out last night. http://bsdrp.net/documentation/technical_docs/performance
Use this more for the monitoring tools and the data they capture. It should help immensely. You may have to modify pfSense as some of the tools/modules may not be loaded by default in the distribution. You can grab them from FreeBSD as noted in the article.
-
I've been thinking about this, considering it was the RRD graphs which took out my fw straight away, I dont think the drivers are the issue really but more the SMP support in freebsd 10.1 like Harvy66 mentions in the FreeBSD 11 thread and in post 14 on this thread.
One way I can test this theory is to fire up an old single core AMD laptop with the same usb nics on the wan and see how it performs.
Laptop spec is not identical admittedly to the intel D847 ie only 2 or 4Gb of ram, spin disk instead of msata, but the nics will be the same as will pfsense.
Failing that, if I can get pfsense running on the raspberry pi's I have here, I can test on a RPi1 b (single core) as well as the new RPi2 which is quad core but same 1Ghz, same ram and will have same usb nics although the Arm cpu instruction sets are different.
Worth trying the single core laptop next instead?
-
Just let me know :)