Re: Safe bruteforce rule for mobile-friendly website
Thanks guys! I had to disable it as soon as I found out so the relevant logs are probably too far up the buffer, but I'll set up a test server ASAP and study the tcpdump in detail. Somehow your mobiles hit either the fifteen new connections per five seconds max (that's only three new connections per second) or the 100 simultaneous connections. Impossible to say which one without studying the actual session data via tcpdump. Unless the back end is too brittle, consider loosening the rate limiting or discarding it altogether. You could try temporarily removing either the max-src-conn or the max-src-conn-rate setting to see which one trips up the mobiles. Basically it's a social network geared towards teens, who tend to use mobile for everything. I'm guessing properly designed spam bots would go slow and at random intervals, so I'm not so sure how effective bruteforce for httpd would actually be? Do you want to block 15/5 clients? I'm not so sure anymore. Possibly relevant question: do all clients receive the same content, or is there a separate version you serve to mobile clients? Currently it's all the same content. I'm planning to use Nginx to redirect to a dedicated mobile site later on though. Thank you! Mikkel 2013/2/6 Peter N. M. Hansteen pe...@bsdly.net Mikkel Bang facebookman...@gmail.com writes: Turns out this (http://home.nuug.no/~peter/pf/en/long-firewall.html) bans any IP connecting from mobile devices: Well, that document says a lot of other stuff too, so please be more specific. pass in on $ext_if inet proto tcp from any to any port 80 keep state (max-src-conn 100, max-src-conn-rate 15/5, overload bruteforce flush global) Works fine when connecting from regular PCs though. Why is that? Do mobile devices connect differently somehow? Somehow your mobiles hit either the fifteen new connections per five seconds max (that's only three new connections per second) or the 100 simultaneous connections. Impossible to say which one without studying the actual session data via tcpdump. Unless the back end is too brittle, consider loosening the rate limiting or discarding it altogether. You could try temporarily removing either the max-src-conn or the max-src-conn-rate setting to see which one trips up the mobiles. Possibly relevant question: do all clients receive the same content, or is there a separate version you serve to mobile clients? - P -- Peter N. M. Hansteen, member of the first RFC 1149 implementation team http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/ Remember to set the evil bit on all malicious network traffic delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
syncing hardware clock
I've got a small system running 5.2-stable and the clock seems off. NTP is making entries like this on startup: Jan 31 10:15:31 net5501 ntpd[20060]: adjusting local clock by 93.846882s I've looked around in the mail archives for various mailing lists and have the impression that a proper shutdown (using shutdown) will sync the hardware clock. However, this looks like it is not described in the manual page for shutdown. Does shutdown sync the clock and if so would 'shutdown -k' suffice or is a full reboot / poweroff required? Regards, /Lars
Re: UNIX A to Z List RFC
On 02/02/2013 01:59 PM, Chris Hettrick wrote:
Hi Misc,
I made a list of the most classical UNIX commands / utilities from section one
where there is only one per letter of the english alphabet (it's for my OpenBSD
obsessed five year old son :) ). I know that this subject is very personal and
steeped in tradition and history, so I was looking for your opinions and
suggestions.
A quick note about the list: some hard choices were made concerning letters
such as c, p, m, etc. For instance, kill(1) is not included for two reasons: it
is included in the shell, and it needs ps(1) to be properly used (which
conflicts with pwd(1) which I think is _more_ useful for a UNIX beginner).
mv(1) was not included because a cp(1) and rm(1) can suffice.
snip
heh there is a fortune for that
A is for awk, which runs like a snail, and
B is for biff, which reads all your mail.
C is for cc, as hackers recall, while
D is for dd, the command that does all.
E is for emacs, which rebinds your keys, and
F is for fsck, which rebuilds your trees.
G is for grep, a clever detective, while
H is for halt, which may seem defective.
I is for indent, which rarely amuses, and
J is for join, which nobody uses.
K is for kill, which makes you the boss, while
L is for lex, which is missing from DOS.
M is for more, from which less was begot, and
N is for nice, which it really is not.
O is for od, which prints out things nice, while
P is for passwd, which reads in strings twice.
Q is for quota, a Berkeley-type fable, and
R is for ranlib, for sorting ar table.
S is for spell, which attempts to belittle, while
T is for true, which does very little.
U is for uniq, which is used after sort, and
V is for vi, which is hard to abort.
W is for whoami, which tells you your name, while
X is, well, X, of dubious fame.
Y is for yes, which makes an impression, and
Z is for zcat, which handles compression.
-- THE ABC'S OF UNIX
which got me thinking and I came with this terrifying monstrosity
find $(echo ${PATH} | tr ':' ' ') -perm -0100 -maxdepth 1 ! -type d \
| sed -E -f basename.sed \
| awk -f tag.awk \
| sort -n -k 1,1 \
| sort -u -k 2,2 \
| awk -f display.awk
with
basename.sed:
s/.*\/([^\/]*)$/\1/
#much faster then my first attempt | xargs -n 1 basename
tag.awk:
{
printf %s %s %s\n, int(rand() * 1000), substr($0, 1, 1), $0
}
display.awk:
{
man_cmd = man -f $3 | tail -n 1
man_cmd | getline man_str
printf %s is for %s\n, $2, man_str
}
Now, the prose is a little off, but I blame the documentation writers.
I am certain mdoc(7) has a section about the rhyming characteristics
needed for .Nm on alternate lettered commands.
And let me just say I was quite pleased with my
random pick one per letter group system(the tag-sort nonsense)
First attempt was with awk associative arrays and that was getting nasty
quick.
So I just wanted to thank you for reminding me how much fun unix can be.
and I wish you and your son many hours of happy hacking togther.
relayd and icecast
Hi,
I'm trying to use an OB server as an icecast streaming server. I'm also
trying to use relayd
as a relay between the client and icecast server to limit access to
admin pages of icecast.
I have a problem with relayd closing connections. I believe it does that
because of the session timeout.
Here are some details:
# relayctl show sessions
session 0:4 client_IP:49387 - 127.0.0.1:8002 RUNNING
age 00:00:38, idle 00:00:38, relay 1, pid 9275
relayd thinks it is idle although there are syn/ack packets going both
directions.
relayd debug:
relay icecastproxy, session 4 (1 active), 0, client_IP -
127.0.0.1:8002, hard timeout
tcpdump:
15:34:48.116939 server.8000 client.49387: P 695922:696058(136) ack 524
win 2172 nop,nop,timestamp 2916967890 1128121967 (DF)
15:34:48.117150 server.8000 client.49387: . 696058:697506(1448) ack
524 win 2172 nop,nop,timestamp 2916967890 1128121967 (DF)
15:34:48.117197 server.8000 client.49387: . 697506:698954(1448) ack
524 win 2172 nop,nop,timestamp 2916967890 1128121967 (DF)
15:34:48.117251 client.49387 server.8000: . ack 693026 win 83
nop,nop,timestamp 1128122687 2916967890 (DF)
15:34:48.117275 client.49387 server.8000: . ack 694474 win 82
nop,nop,timestamp 1128122687 2916967890 (DF)
15:34:48.117291 client.49387 server.8000: . ack 695922 win 80
nop,nop,timestamp 1128122687 2916967890 (DF)
15:34:48.117307 client.49387 server.8000: . ack 696058 win 80
nop,nop,timestamp 1128122687 2916967890 (DF)
15:34:48.117663 client.49387 server.8000: . ack 697506 win 83
nop,nop,timestamp 1128122687 2916967890 (DF)
15:34:48.117691 client.49387 server.8000: . ack 698954 win 82
nop,nop,timestamp 1128122687 2916967890 (DF)
15:34:48.117744 server.8000 client.49387: P 698954:700215(1261) ack
524 win 2172 nop,nop,timestamp 2916967890 1128122687 (DF)
15:34:48.118333 client.49387 server.8000: . ack 700215 win 83
nop,nop,timestamp 1128122688 2916967890 (DF)
*15:34:48.168128 server.8000 client.49387: F 700215:700215(0) ack 524
win 2172 nop,nop,timestamp 2916967890 1128122688 (DF)*
15:34:48.168467 client.49387 server.8000: F 524:524(0) ack 700216 win
83 nop,nop,timestamp 1128122738 2916967890 (DF)
15:34:48.168529 server.8000 client.49387: . ack 525 win 2172
nop,nop,timestamp 2916967890 1128122738 (DF)
The server sends the FIN packet and closes the connection.
my relayd.conf looks like this:
relay icecastproxy {
listen on $ext_addr port $ext_port
# protocol adminfilter # limit access to admin pages
forward to $icecast_host port $icecast_port
session timeout 10 # seconds
}
pf is simple:
anchor relayd/* all
pass in quick all flags S/SA
pass out all flags S/SA
If I increase the session timeout to a BIG value then I have no problem.
However I don't think this is the right approach.
Shouldn't relayd treat the connection as NOT idle thus not close it?
regards,
Giannis
Re: syncing hardware clock
Lars Nooden lars.noo...@gmail.com wrote: I've got a small system running 5.2-stable and the clock seems off. NTP is making entries like this on startup: Jan 31 10:15:31 net5501 ntpd[20060]: adjusting local clock by 93.846882s I've looked around in the mail archives for various mailing lists and have the impression that a proper shutdown (using shutdown) will sync the hardware clock. The shutdown(8) command doesn't directly sync the RTC; boot(9) does. You need to perform an actual halt or reboot for this to happen. -- Christian naddy Weisgerber na...@mips.inka.de
Re: syncing hardware clock
On Thu, Feb 07, 2013 at 03:36:43PM +, Christian Weisgerber wrote: Lars Nooden lars.noo...@gmail.com wrote: I've got a small system running 5.2-stable and the clock seems off. NTP is making entries like this on startup: Jan 31 10:15:31 net5501 ntpd[20060]: adjusting local clock by 93.846882s I've looked around in the mail archives for various mailing lists and have the impression that a proper shutdown (using shutdown) will sync the hardware clock. The shutdown(8) command doesn't directly sync the RTC; boot(9) does. You need to perform an actual halt or reboot for this to happen. -- Christian naddy Weisgerber na...@mips.inka.de And remember ntpd takes it's time to adjust the clock. Set the clock once by hand or use rdate once if you are impatient. -Otto
Re: syncing hardware clock
On Thu, 7 Feb 2013, Otto Moerbeek wrote: On Thu, Feb 07, 2013 at 03:36:43PM +, Christian Weisgerber wrote: Lars Nooden lars.noo...@gmail.com wrote: I've got a small system running 5.2-stable and the clock seems off. NTP is making entries like this on startup: Jan 31 10:15:31 net5501 ntpd[20060]: adjusting local clock by 93.846882s I've looked around in the mail archives for various mailing lists and have the impression that a proper shutdown (using shutdown) will sync the hardware clock. The shutdown(8) command doesn't directly sync the RTC; boot(9) does. You need to perform an actual halt or reboot for this to happen. -- Christian naddy Weisgerber na...@mips.inka.de And remember ntpd takes it's time to adjust the clock. Set the clock once by hand or use rdate once if you are impatient. -Otto Thanks. It looks like my drift was due to not using halt / shutdown. I have now switched to using ntpd -s, since the box gets turned on almost every day. But because my ISP can take 3 to 5 minutes to cough up a DHCP address, ntpd was getting started way before the public NTP servers were available. I've moved ntpd startup to /etc/rc.local after a check for connectivity. Regards, /Lars
Re: syncing hardware clock
On Thu, Feb 07, 2013 at 05:52:08PM +0200, Lars Nooden wrote: On Thu, 7 Feb 2013, Otto Moerbeek wrote: On Thu, Feb 07, 2013 at 03:36:43PM +, Christian Weisgerber wrote: Lars Nooden lars.noo...@gmail.com wrote: I've got a small system running 5.2-stable and the clock seems off. NTP is making entries like this on startup: Jan 31 10:15:31 net5501 ntpd[20060]: adjusting local clock by 93.846882s I've looked around in the mail archives for various mailing lists and have the impression that a proper shutdown (using shutdown) will sync the hardware clock. The shutdown(8) command doesn't directly sync the RTC; boot(9) does. You need to perform an actual halt or reboot for this to happen. -- Christian naddy Weisgerber na...@mips.inka.de And remember ntpd takes it's time to adjust the clock. Set the clock once by hand or use rdate once if you are impatient. -Otto Thanks. It looks like my drift was due to not using halt / shutdown. I have now switched to using ntpd -s, since the box gets turned on almost every day. But because my ISP can take 3 to 5 minutes to cough up a DHCP address, ntpd was getting started way before the public NTP servers were available. I've moved ntpd startup to /etc/rc.local after a check for connectivity. Regards, /Lars Note that in this case the clock might be set backwards in multi-user mode. Some programs might get confused by that. -Otto
Re: openbsd and vmware
I also tried the socket trick in different setups but couldn't make it work. I tried a smp 4,threads 1 cores 1 sockets 4. Sysctl tells cpus are found but not used. Did you pass any special cpu information to qemu ? Virtio: i'm not following current right now, but this are great news. Thank you.
Re: openbsd and vmware
On Thu Feb 7 2013 05:33, Jan Lambertz wrote: problems i found using kvm and openbsd: SMP not working as it should. I usually increase the number of virtual sockets to get those extra cores recognised by OpenBSD. This seems to make the hypervisor produce better ACPI routing information ... No virto drivers for openbsd(disk i miss the most) Hm? On -current: virtio2 at pci0 dev 5 function 0 Qumranet Virtio Storage rev 0x00: Virtio Block Device vioblk0 at virtio2 scsibus1 at vioblk0: 2 targets sd0 at scsibus1 targ 0 lun 0: VirtIO, Block Device, SCSI3 0/direct fixed sd0: 8192MB, 512 bytes/sector, 16777216 sectors virtio2: apic 1 int 10 ... and these ... virtio0 at pci0 dev 3 function 0 Qumranet Virtio Network rev 0x00: Virtio Network Device vio0 at virtio0: address 00:1a:4a:15:00:1f virtio0: apic 1 int 11 virtio6 at pci0 dev 9 function 0 Qumranet Virtio Memory rev 0x00: Virtio Memory Balloon Device viomb0 at virtio6 virtio6: apic 1 int 10
Re: Safe bruteforce rule for mobile-friendly website
I had to disable it as soon as I found out so the relevant logs are probably too far up the buffer, but I'll set up a test server ASAP and study the tcpdump in detail. I forget if mobiles do more prefetching on dns and/or tcp on mobiles but perhaps that's worth considering as a culprit. Does the page have more than 15 links? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
softraid RAID1 + CRYPTO error writing metadata
I get a rather curious error when shutting down a machine with a RAID 1 setup that contains a crypto partition and a normal partition: syncing disks... done sd3 detached softraid0: I/O error 5 on dev 0x433 at block 16 softraid0: could not write metadata to sd3d sd4 detached rebooting... When the machine starts up again, I see: softraid0: sd4 was not shutdown properly (twice) The funny thing is that everything works just fine. No problems whatsoever. That said, the error message is more than a little unsettling and I'm worried that one day I'm going to access files on the crypto volume only to find the data isn't available. Any hints on what I did wrong when setting this up? Details: The RAID volume, sd3, is made up from two 3TB as sd0 and sd1: # disklabel -pg sd0 # /dev/rsd0c: type: SCSI disk: SCSI disk label: ST3000DM001-1CH1 duid: ec7586498efe98b8 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 364801 total sectors: 5860533168 # total bytes: 2794.5G boundstart: 64 boundend: 4294961685 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 2794.5G 64RAID c: 2794.5G0 unused # disklabel -pg sd1 # /dev/rsd1c: type: SCSI disk: SCSI disk label: ST3000DM001-1CH1 duid: 0372b77b79b2e168 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 364801 total sectors: 5860533168 # total bytes: 2794.5G boundstart: 64 boundend: 4294961685 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 2794.5G 64RAID c: 2794.5G0 unused Those two drives then become sd3: (sd2 is an SSD boot drive) # disklabel -pg sd3 # /dev/rsd3c: type: SCSI disk: SCSI disk label: SR RAID 1 duid: 6ca0888211d57886 flags: bytes/sector: 512 sectors/track: 255 tracks/cylinder: 511 sectors/cylinder: 130305 cylinders: 44975 total sectors: 5860532576 # total bytes: 2794.5G boundstart: 0 boundend: 5860532576 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 1397.3G0 4.2BSD 8192 655361 # /st2 c: 2794.5G0 unused d: 1397.3G 2930266240RAID from which a crypto volume was created, becoming sd4: # disklabel -pg sd4 # /dev/rsd4c: type: SCSI disk: SCSI disk label: SR CRYPTO duid: 6c6e53ab843ef6c8 flags: bytes/sector: 512 sectors/track: 63 tracks/cylinder: 255 sectors/cylinder: 16065 cylinders: 182400 total sectors: 2930265808 # total bytes: 1397.3G boundstart: 0 boundend: 2930265808 drivedata: 0 16 partitions: #size offset fstype [fsize bsize cpg] a: 1397.3G0 4.2BSD 8192 655361 c: 1397.3G0 unused I'm running a snapshot from Jan 21. Full dmesg: OpenBSD 5.2-current (GENERIC.MP) #20: Mon Jan 21 17:23:23 MST 2013 t...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 12613910528 (12029MB) avail mem = 12255641600 (11687MB) mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.5 @ 0x9f400 (68 entries) bios0: vendor American Megatrends Inc. version 2105 date 07/23/2010 bios0: ASUSTeK Computer INC. M4A785TD-V EVO acpi0 at bios0: rev 2 acpi0: sleep states S0 S1 S3 S4 S5 acpi0: tables DSDT FACP APIC MCFG OEMB SRAT HPET SSDT acpi0: wakeup devices PCE2(S4) PCE3(S4) PCE4(S4) PCE5(S4) PCE6(S4) PCE7(S4) PCE9(S4) PCEA(S4) PCEB(S4) PCEC(S4) SBAZ(S4) PS2M(S4) PS2K(S4) UAR1(S4) P0PC(S4) UHC1(S4) UHC2(S4) UHC3(S4) USB4(S4) UHC5(S4) UHC6(S4) UHC7(S4) acpitimer0 at acpi0: 3579545 Hz, 32 bits acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: AMD Phenom(tm) II X6 1100T Processor, 3300.74 MHz cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu0: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache cpu0: ITLB 32 4KB entries fully associative, 16 4MB entries fully associative cpu0: DTLB 48 4KB entries fully associative, 48 4MB entries fully associative cpu0: AMD erratum 721 detected and fixed cpu0: apic clock running at 200MHz cpu1 at mainbus0: apid 1 (application processor) cpu1: AMD Phenom(tm) II X6 1100T Processor, 3300.25 MHz cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,MMX,FXSR,SSE,SSE2,HTT,SSE3,MWAIT,CX16,POPCNT,NXE,MMXX,FFXSR,LONG,3DNOW2,3DNOW,LAHF,CMPLEG,SVM,EAPICSP,AMCR8,ABM,SSE4A,MASSE,3DNOWP,OSVW,IBS,SKINIT,ITSC cpu1: 64KB 64b/line 2-way I-cache, 64KB 64b/line 2-way D-cache, 512KB 64b/line 16-way L2 cache, 6MB 64b/line 48-way L3 cache cpu1: ITLB 32 4KB entries fully associative, 16 4MB
pf blocking active connections
Hello misc, Today I watch the current connections on my small home server and I noticed an unfamiliar ftp-connection. Upon inspecting the connection I noticed it was a brute force attack, so I fired up my pfctl-utility and tried to block the attack by adding the ip to my quick drop table. After adding the ip to the table I noticed that the connection was still happily active and even reloading my entire ruleset with pfctl -f /etc/pf.conf didn't help, so I resorted to tcpdrop. My question is, is it possible to destroy an active connection by something like adding an ip to a drop quick table (did I miss a certain flag?) or do I, in an event that something like this happens again, always have to perform a two stage drop? Sincerely, Martijn
Re: pf blocking active connections
look in 'man pfctl' and search for killing active sessions. On Thu, Feb 7, 2013 at 12:13 PM, Martijn van Duren martijn...@gmail.com wrote: Hello misc, Today I watch the current connections on my small home server and I noticed an unfamiliar ftp-connection. Upon inspecting the connection I noticed it was a brute force attack, so I fired up my pfctl-utility and tried to block the attack by adding the ip to my quick drop table. After adding the ip to the table I noticed that the connection was still happily active and even reloading my entire ruleset with pfctl -f /etc/pf.conf didn't help, so I resorted to tcpdrop. My question is, is it possible to destroy an active connection by something like adding an ip to a drop quick table (did I miss a certain flag?) or do I, in an event that something like this happens again, always have to perform a two stage drop? Sincerely, Martijn
Re: pf blocking active connections
On 02/07/13 15:13, Martijn van Duren wrote: Hello misc, Today I watch the current connections on my small home server and I noticed an unfamiliar ftp-connection. Upon inspecting the connection I noticed it was a brute force attack, so I fired up my pfctl-utility and tried to block the attack by adding the ip to my quick drop table. After adding the ip to the table I noticed that the connection was still happily active and even reloading my entire ruleset with pfctl -f /etc/pf.conf didn't help, so I resorted to tcpdrop. My question is, is it possible to destroy an active connection by something like adding an ip to a drop quick table (did I miss a certain flag?) or do I, in an event that something like this happens again, always have to perform a two stage drop? Sincerely, Martijn I've seen this before. The attack continued because you have an existing state entry on the firewall that is allowing packets to continue. Use 'pfctl -k (host)' to kill off existing states. -- Scott McEachern https://www.blackstaff.ca
Re: pf blocking active connections
Thanks for all the quick responses, but if I understand you all correctly there is no way to cut off an established connection by adding an ip address to a blocked table, so I'm still left with my two stage drop off the connection (both adding the the ip to the table and killing the connection manually). Martijn On Thu, 2013-02-07 at 21:21 +0100, Peter J. Philipp wrote: Someone on this list once helped me a great deal by mentioning the following: I bet you have a pf state left after reloading your firewall rules and since they don't get reset you have to kill them. Use pfctl -ss -vv to identify the state by id and use pfctl -k id -k id to kill it. That's how I do it these days. Cheers, -peter Am 07.02.2013 um 21:13 schrieb Martijn van Duren martijn...@gmail.com: Hello misc, Today I watch the current connections on my small home server and I noticed an unfamiliar ftp-connection. Upon inspecting the connection I noticed it was a brute force attack, so I fired up my pfctl-utility and tried to block the attack by adding the ip to my quick drop table. After adding the ip to the table I noticed that the connection was still happily active and even reloading my entire ruleset with pfctl -f /etc/pf.conf didn't help, so I resorted to tcpdrop. My question is, is it possible to destroy an active connection by something like adding an ip to a drop quick table (did I miss a certain flag?) or do I, in an event that something like this happens again, always have to perform a two stage drop? Sincerely, Martijn
Re: pf blocking active connections
On 02/07/13 15:31, Martijn van Duren wrote: Thanks for all the quick responses, but if I understand you all correctly there is no way to cut off an established connection by adding an ip address to a blocked table, so I'm still left with my two stage drop off the connection (both adding the the ip to the table and killing the connection manually). Martijn Yes. But it's not like it's hard to type pfctl -ef /etc/pf.conf pfctl -k 192.168.1.1 either. :) -- Scott McEachern https://www.blackstaff.ca
Re: OpenBSD 5.2 isakmpd sequence number problem
On Wed, Jan 30, 2013 at 14:59 +0100, Bartosz Brzozowski wrote:
Hi Misc.
I have two location A i B in my lab.
In the location A there is isakmpd + carp + pfsync + sasync cluster
on which there is installed OpenBSD 5.2 GENERIC.MP#339 i386
In the location B there is single OpenBSD 5.2 GENERIC#278 i386 installation.
I have successfully established IPsec site-to-site connection
between those two location and everything works fine until failover
occurs in the cluster in location A ( I am using ifconfig -g carp
carpdemote 128 command on the MASTER node to force the failover).
When failover occurs pfsync increase sequence number on the new
MASTER node by 16384 and cluster continues sending ESP packets with
the new, increased value (for example if the last seq number on the
old MASTER was sent with the value equal to 100 the new MASTER will
send his first packet with seq number equal to 16484).
On the OpenBSD 5.2 in location B, using tcpdump I am able to see ESP
packets, with the new increased seq number, on the phisical
interface, but I do not see any transmition on enc0 interface. The
ESP packets are continuously going out of the cluster A and are
continuously, silently dropped on OpenBSD in location B. All IPsec
transmition is broken until new SA are established and seq number is
reset to 0.
I noted that starting from version OpenBSD 5.2 there is added
support for Extended Sequence Numbers in the IPsec stack, so I go
back with the version of OpenBSD on the server located in B from 5.2
to 5.1 GENERIC#160 i386, copied all configuration files to it,
established once again IPsec beetwen A and B and from that point
everything started to work perfectly. Now I am able to switch nodes
in cluster A (ofcourse seq number, everytime I switch nodes is
increased by 16384) and OpenBSD 5.1 in location B successfully
decrypt and encrypt connection. I am able to see packets, going in
both directions, on interface enc0 as well I am able to see ESP
packet on phisical interface on OpenBSD 5.1.
Is there bug in inplementation ESN in new IPsec stack on OpenBSD 5.2
or do I need additional configuration to make above setup to started
to work properly.
Please let me know if You need any additional information.
Thanks for advise regards,
Bartosz Brzozowski
hi,
your observations are correct. the problem should be resolved by
this commit:
http://www.openbsd.org/cgi-bin/cvsweb/src/sys/net/if_pfsync.c.diff?r1=1.189;r2=1.190
trying 5.3 beta might be a good idea as well to make sure it doesn't
have the aforementioned problem. i'm also waiting for a review of a
change that will improve the anti-replay window handing and merge in
a diff from markus@ to increase the anti-replay window to 2100 packets.
i'll update this thread once the change will be in. but in case you
have some time to play with it, you could try the diff below.
diff --git sys/netinet/ip_ah.c sys/netinet/ip_ah.c
index 243c82a..9ea6534 100644
--- sys/netinet/ip_ah.c
+++ sys/netinet/ip_ah.c
@@ -149,7 +149,6 @@ ah_init(struct tdb *tdbp, struct xformsw *xsp, struct
ipsecinit *ii)
tdbp-tdb_xform = xsp;
tdbp-tdb_authalgxform = thash;
- tdbp-tdb_bitmap = 0;
tdbp-tdb_rpl = AH_HMAC_INITIAL_RPL;
DPRINTF((ah_init(): initialized TDB with hash algorithm %s\n,
diff --git sys/netinet/ip_esp.c sys/netinet/ip_esp.c
index 40553c9..77e16ae 100644
--- sys/netinet/ip_esp.c
+++ sys/netinet/ip_esp.c
@@ -242,7 +242,6 @@ esp_init(struct tdb *tdbp, struct xformsw *xsp, struct
ipsecinit *ii)
}
tdbp-tdb_xform = xsp;
- tdbp-tdb_bitmap = 0;
tdbp-tdb_rpl = AH_HMAC_INITIAL_RPL;
/* Initialize crypto session */
@@ -1114,33 +1113,7 @@ esp_output_cb(void *op)
return error;
}
-static __inline int
-checkreplay(u_int64_t *bitmap, u_int32_t diff)
-{
- if (*bitmap (1ULL diff))
- return (1);
- return (0);
-}
-
-static __inline void
-setreplay(u_int64_t *bitmap, u_int32_t diff, u_int32_t window, int wupdate)
-{
- if (wupdate) {
- if (diff window)
- *bitmap = ((*bitmap) diff) | 1;
- else
- *bitmap = 1;
- } else
- *bitmap |= 1ULL diff;
-}
-
-/*
- * To prevent ESN desynchronization replay distance specifies maximum
- * valid difference between the received SN and the last authenticated
- * one. It's arbitrary chosen to be 1000 packets, meaning that only
- * up to 999 packets can be lost.
- */
-#define REPLAY_DISTANCE (1000)
+#define SEEN_SIZE howmany(TDB_REPLAYMAX, 32)
/*
* return 0 on success
@@ -1153,21 +1126,26 @@ checkreplaywindow(struct tdb *tdb, u_int32_t seq,
u_int32_t *seqhigh,
int commit)
{
u_int32_t tl, th, wl;
- u_int32_t seqh, diff;
- u_int32_t window = tdb-tdb_wnd;
- u_int64_t *bitmap = tdb-tdb_bitmap;
- int esn = tdb-tdb_flags TDBF_ESN;
+
Re: pf blocking active connections
On Feb 07 21:31:11, martijn...@gmail.com wrote: Thanks for all the quick responses, but if I understand you all correctly there is no way to cut off an established connection by adding an ip address to a blocked table, so I'm still left with my two stage drop off the connection (both adding the the ip to the table and killing the connection manually). Yes; these are two distinct actions: 1. killing an active connection (pfctl -k) 2. adding a host to a table (pfctl -t) (whatever it may mean in the ruleset)
Re: Safe bruteforce rule for mobile-friendly website
I forget if mobiles do more prefetching on dns and/or tcp on mobiles but perhaps that's worth considering as a culprit. My God Kevin, that's gotta be it! Does the page have more than 15 links? Yep, like 16-17 or so :) Mikkel 2013/2/7 Kevin Chadwick ma1l1i...@yahoo.co.uk I had to disable it as soon as I found out so the relevant logs are probably too far up the buffer, but I'll set up a test server ASAP and study the tcpdump in detail. I forget if mobiles do more prefetching on dns and/or tcp on mobiles but perhaps that's worth considering as a culprit. Does the page have more than 15 links? -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___
Re: pf blocking active connections
On Feb 7, 2013 11:20 PM, Jan Stary h...@stare.cz wrote: On Feb 07 21:31:11, martijn...@gmail.com wrote: Thanks for all the quick responses, but if I understand you all correctly there is no way to cut off an established connection by adding an ip address to a blocked table, so I'm still left with my two stage drop off the connection (both adding the the ip to the table and killing the connection manually). Yes; these are two distinct actions: 1. killing an active connection (pfctl -k) 2. adding a host to a table (pfctl -t) (whatever it may mean in the ruleset) Swap the order.
