Re: news from my (probably not) hacked box
Thanks for catching that! Apparently I forgot how pf works... It really is getting late :/ On Thu, Apr 2, 2020, 23:22 jeanfrancois wrote: > It used to be this pf.conf would work (possibly not on latest version): > > block in all > pass out all keep state > > Pass out keeps states from pass in is not required. Packet filter is > stateful and gracefully lets expected packets come trough when > they match a connection initiated. > > Jean-François > > Le 02/04/2020 à 22:26, Kristjan Komlosi a écrit : > > [...] but aren't there supposed to be some rules that pass > > traffic inbound to your interface? > >
Re: Any console SIP client from ports or packages?
pjsua It has audio only, no video part ported yet. I didn't use it with asterisk but was fine with iptel.org.
Re: news from my (probably not) hacked box
It used to be this pf.conf would work (possibly not on latest version): block in all pass out all keep state Pass out keeps states from pass in is not required. Packet filter is stateful and gracefully lets expected packets come trough when they match a connection initiated. Jean-François Le 02/04/2020 à 22:26, Kristjan Komlosi a écrit : [...] but aren't there supposed to be some rules that pass traffic inbound to your interface?
Re: news from my hacked box
On 4/1/20 10:25 PM, Cord wrote: > Hi, > I found something that in my opinion are nearly evidences. What exactly are trying to prove here? > For those who doesn't know my story please read past messages: > https://marc.info/?a=15535526152=1=2 I think I know you from before. You're the guy claiming to be hacked over and over again, right? > Well, as I said previously my laptop was been hacked then I bought a new > laptop because my suspicious are that the uefi or other firmware was been > hacked (I reinstalled openbsd various times) > The old laptop had a wifi usb dongle to connect to the wifi router. > Now the new laptop has a wifi chip that works properly on opnebsd. > The inner IF is iwm0. > And I discovered differences on wifi performance between the on board IF and > the old usb dongle. > Of course the tests were been made from exactly the same physical place. > The following are the results (I used speedtest-cli): > iwm0 with vpn download: 0,46 mbit/s upload: 0,55 mbit/s > iwm0 without vpn download: 0,50 mbit/s upload: 2,53 mbit/s > urtwn0 with vpn download: 20,88 mbit/s upload: 8,49 mbit/s > urtwn0: without vpn download: 24,83 mbit/s upload 9,27 mbit/s What exactly is strange here? Two different cards behave differently. > The following are the results pinging 8.8.8.8 with -c 500: > 500 packets transmitted, 500 packets received, 0.0% packet loss > iwm0: round-trip min/avg/max/std-dev = 18.761/6372.615/72372.495/14987.007 ms > urtwn0: round-trip min/avg/max/std-dev = 24.068/36.489/878.218/48.120 ms > The thing I find funny is that you insist on being spied on or somehow hacked, you act tin-foil paranoid to the point of changing your laptop because of some unexplained behavior, yet you use Speedtest.net and CloudFlare DNS. Are you trolling or delusional? > As I know the traffic shaping is configured by pf with pf.conf, the following > is my pf.conf (I'm sorry I'm not a genius of pf): > ---/etc/pf.conf > if="urtwn0" > #if="iwm0" > dns="{8.8.8.8}" > myvpn="{x.x.x.x, x.x.x.x, x.x.x.x, x.x.x.x, x.x.x.x}" > weird="{239.255.255.250, 224.0.0.1}" > pany="{udp, tcp}" > set skip on tun0 > set skip on lo > set block-policy drop > set loginterface $if > block quick inet6 > block quick on $if from any to $weird > pass quick proto icmp > pass out quick on $if proto $pany from $if to $dns > pass out quick on $if proto udp from $if to $myvpn > pass out quick on $if proto tcp from $if to my01-other-vpn.com > pass out quick on $if proto tcp from $if to my02-other-vpn.com > pass out quick on $if proto tcp from $if to my03-other-vpn.com > block drop in on ! lo0 proto tcp to port 6000:6010 > block drop out log proto {tcp udp} user _pbuild > block log quick on $if > -- Neither am I, but aren't there supposed to be some rules that pass traffic inbound to your interface? > Other strange things that happens on my laptop are the following: > 1) sometimes my openvpn (2 times on 5) fail authentication even I use a saved > file authentication data and pass it the data with --auth-user-pass > /my/path/pass > Then in my opinion it's impossible fails the authentication. Not really. OpenVPN is a temperamental piece of software that doesn't like firewalls very much. In edge cases, it likes to fail, especially if you use UDP. > 2) sometimes KeePassXC fails authentication on random site. If I copy the > password and paste it by hand it works. Both autotype and browser plugins are dependent on so many different technologies to work like they should. Like before, it's easy for things to go wrong in edge cases. > 3) and of course there are people that can spy me and modify suggested videos > on youtube. Please do not comment this because I know it's very subjective. Same as before. Tinfoil hat paranoia yet you still use YouTube? > > As I said previously in my opinion there is 0day on how is implemented the > tcp/ip stack in the kernel. > And the vulnerability can be exploited by a mitm attack from the home router. > Thank you Cord. And the proof is where? You are providing sparse information, impossible PF configuration files, and anecdotal "evidence" that can be easily attributed to user error. Instead of trying to explore how programs you're using work, you blame OpenBSD. The only thing you make evident is your lack of analytical approach to problem solving and ignorance of the mailing list rules. Where is dmesg output? What HW are you using? What browser? What router? Please take the list seriously or go away.
Re: Any console SIP client from ports or packages?
On Thu, April 2, 2020 16:20, Martin wrote: > I'm looking for lightweight console SIP client to perform calls right from > OpenBSD console with asterisk. > > Please suggest. > > Martin > Hi, Take a look at baresip.
RE: news from my hacked box
Haai, "Theo de Raadt" wrote: > Cord wrote: > >> You are free to believe or not to believe, but you are not free to insult me. >> Is that clear ? > > Or what.. you'll throw your tinfoil hat at them? Haven't you yet been diagnosed w/ ODD? :) Cord: you're prolly being overly paranoid, and your assertions are somewhat vague. Many people here have trouble dealing w/ that, me included. Thus: please excuse us if we cannot give you the answers you seek. What mecan say is that some of the problems you identified are a natural consequence of the unreliability of IP. No reason to be a jerk, though. HTH, --zeurkous. -- Friggin' Machines!
Re: news from my hacked box
You are free to believe or not to believe, but you are not free to insult me. Is that clear ? Sent with ProtonMail Secure Email. ‐‐‐ Original Message ‐‐‐ On Thursday 2 April 2020 03:01, Anders Andersson wrote: > On Wed, Apr 1, 2020 at 10:29 PM Cord openbs...@protonmail.com wrote: > > > Hi, > > I found something that in my opinion are nearly evidences. > > For those who doesn't know my story please read past messages: > > https://marc.info/?a=15535526152=1=2 > > Well, as I said previously my laptop was been hacked then I bought a new > > laptop because my suspicious are that the uefi or other firmware was been > > hacked (I reinstalled openbsd various times) > > The old laptop had a wifi usb dongle to connect to the wifi router. > > Now the new laptop has a wifi chip that works properly on opnebsd. > > The inner IF is iwm0. > > And I discovered differences on wifi performance between the on board IF > > and the old usb dongle. > > Of course the tests were been made from exactly the same physical place. > > The following are the results (I used speedtest-cli): > > iwm0 with vpn download: 0,46 mbit/s upload: 0,55 mbit/s > > iwm0 without vpn download: 0,50 mbit/s upload: 2,53 mbit/s > > urtwn0 with vpn download: 20,88 mbit/s upload: 8,49 mbit/s > > urtwn0: without vpn download: 24,83 mbit/s upload 9,27 mbit/s > > The following are the results pinging 8.8.8.8 with -c 500: > > 500 packets transmitted, 500 packets received, 0.0% packet loss > > iwm0: round-trip min/avg/max/std-dev = 18.761/6372.615/72372.495/14987.007 > > ms > > urtwn0: round-trip min/avg/max/std-dev = 24.068/36.489/878.218/48.120 ms > > > > As I know the traffic shaping is configured by pf with pf.conf, the > > following is my pf.conf (I'm sorry I'm not a genius of pf): > > ---/etc/pf.conf > > if="urtwn0" > > #if="iwm0" > > dns="{8.8.8.8}" > > myvpn="{x.x.x.x, x.x.x.x, x.x.x.x, x.x.x.x, x.x.x.x}" > > weird="{239.255.255.250, 224.0.0.1}" > > pany="{udp, tcp}" > > set skip on tun0 > > set skip on lo > > set block-policy drop > > set loginterface $if > > block quick inet6 > > block quick on $if from any to $weird > > pass quick proto icmp > > pass out quick on $if proto $pany from $if to $dns > > pass out quick on $if proto udp from $if to $myvpn > > pass out quick on $if proto tcp from $if to my01-other-vpn.com > > pass out quick on $if proto tcp from $if to my02-other-vpn.com > > pass out quick on $if proto tcp from $if to my03-other-vpn.com > > block drop in on ! lo0 proto tcp to port 6000:6010 > > block drop out log proto {tcp udp} user _pbuild > > block log quick on $if > > > > -- > > > > Other strange things that happens on my laptop are the following: > > > > 1. sometimes my openvpn (2 times on 5) fail authentication even I use a > > saved file authentication data and pass it the data with --auth-user-pass > > /my/path/pass > > Then in my opinion it's impossible fails the authentication. > > > > 2. sometimes KeePassXC fails authentication on random site. If I copy the > > password and paste it by hand it works. > > 3. and of course there are people that can spy me and modify suggested > > videos on youtube. Please do not comment this because I know it's very > > subjective. > > > > As I said previously in my opinion there is 0day on how is implemented the > > tcp/ip stack in the kernel. > > And the vulnerability can be exploited by a mitm attack from the home > > router. > > Thank you Cord. > > Hello Cord, and thank you for the interesting messages. > > Just a thought: Do you have any wall paintings, and have you noticed > something different about them since you got hacked? > > You see, I once talked to a man at the local library who was looking > for literature about computer viruses and he mentioned that the virus > had somehow spread out from the USB ports in his computer onto his > paintings, which had now become dull and grey. His family told him > that he was imagining things and refused to help him, that's why he > was at the library to search for information. > > If your computer has been hacked, maybe it is by the same virus. > > Kind regards, >
Re: news from my hacked box
Cord wrote: > You are free to believe or not to believe, but you are not free to insult me. > Is that clear ? Or what.. you'll throw your tinfoil hat at them?
Any console SIP client from ports or packages?
I'm looking for lightweight console SIP client to perform calls right from OpenBSD console with asterisk. Please suggest. Martin
Ajust or set OpenIKED renegotiation timeout manually if remote ISP reset connections
Remote VPS hoster reset connections after some amount of data has been transferred to/from remote VPS. May I adjust OpenIKED renegotiation timeout down to 1-2s in some way? Currently it takes ~3-4m to reconnect. Right after each 'connection reset' issued by VPS hoster I can restart iked manually by "rcctl restart iked" and iked renegotiate the link immediately after it. The question is how to automate it to have minimal connection loss? Martin
Re: BGP and carp slaves
On 02.04.20 12:34, Luca Bodini wrote: Hi folks, I’m just having a strange issue using OpenBSD 6.6 and BGP . I have two OpenBSD firewalls with a carp configuration, let’s suppose the shared IP is 10.10.10.100, and I am able to announce 10.10.10.100/32 via BGP. Now, here is my /etc/bgpd.conf configuration: prefix-set mynetworks { \ 10.10.10.100/32\ } I’ve asked provider to change BGP configuration and everything now is stetted up correctly, now, the question is: Is the carp slave accepting and forwarding connections by design or is it un “unintended" feature? Just out of curiosity, was that a real config or you've replaced ASn and prefix? if it is real where have you found a provider, agreed to setup session with private ASn anouncing a single private ip? Is that a lab of some kind?
Re: BGP and carp slaves
On Thu, Apr 02, 2020 at 11:34:21AM +0200, Luca Bodini wrote: > Hi folks, > > I’m just having a strange issue using OpenBSD 6.6 and BGP . > I have two OpenBSD firewalls with a carp configuration, let’s suppose the > shared IP is 10.10.10.100, and I am able to announce 10.10.10.100/32 via BGP. > Now, here is my /etc/bgpd.conf configuration: > > # define our own ASN as a macro > ASN=“65000" > rde med compare always > > # global configuration > AS $ASN > router-id 172.10.10.3 > > # list of networks that may be originated by our ASN > prefix-set mynetworks { \ > 10.10.10.100/32\ > } > > # Generate routes for the networks our ASN will originate. > # The communities (read 'tags') are later used to match on what > # is announced to EBGP neighbors > network prefix-set mynetworks set { community $ASN:1 med 10 } > > # upstream providers > group "upstreams" { > remote-as 20746 > neighbor 172.10.10.1 { > descr “provider router 01" > } > neighbor 172.10.10.2 { > descr “provider router 02" > } > } > > ## rules section > allow from group upstreams prefix 0.0.0.0/0 > > # IBGP: allow all updates to and from our IBGP neighbors > allow from ibgp > allow to ibgp > allow to ebgp prefix-set mynetworks > > The problem I’m facing is due to (i guess) provider router misconfiguration, > in fact, routers are forwarding traffic to carp slave and unexpectedly > everything is working fine: firewall is accepting connections and forwarding > traffic, for example if I try to SSH: > ~# ssh -l root 10.10.10.100 > [root@fw-02 root]# ifconfig | grep vhid > carp: BACKUP carpdev vlan100 vhid 10 advbase 1 advskew 10 > > I’ve asked provider to change BGP configuration and everything now is stetted > up correctly, now, the question is: > Is the carp slave accepting and forwarding connections by design or is it un > “unintended" feature? > By default bgpd will just announce mynetworks without checking if something is up or not. You may have more luck with 'network inet connected' or even better use a rtlabel. In that case bgpd should respect the status of the route. I normally use carp on both sides and use 'network X/Y set nexthop $CARPIP' Where $CARPIP is the external carp IP shared between the two routers. In this case both systems announce the same network with the same nexthop (the carp IP) to the next routers and so no rerouting happens if the master dies. This only works if the systems share a lan segement for ebgp sessions. -- :wq Claudio
BGP and carp slaves
Hi folks, I’m just having a strange issue using OpenBSD 6.6 and BGP . I have two OpenBSD firewalls with a carp configuration, let’s suppose the shared IP is 10.10.10.100, and I am able to announce 10.10.10.100/32 via BGP. Now, here is my /etc/bgpd.conf configuration: # define our own ASN as a macro ASN=“65000" rde med compare always # global configuration AS $ASN router-id 172.10.10.3 # list of networks that may be originated by our ASN prefix-set mynetworks { \ 10.10.10.100/32\ } # Generate routes for the networks our ASN will originate. # The communities (read 'tags') are later used to match on what # is announced to EBGP neighbors network prefix-set mynetworks set { community $ASN:1 med 10 } # upstream providers group "upstreams" { remote-as 20746 neighbor 172.10.10.1 { descr “provider router 01" } neighbor 172.10.10.2 { descr “provider router 02" } } ## rules section allow from group upstreams prefix 0.0.0.0/0 # IBGP: allow all updates to and from our IBGP neighbors allow from ibgp allow to ibgp allow to ebgp prefix-set mynetworks The problem I’m facing is due to (i guess) provider router misconfiguration, in fact, routers are forwarding traffic to carp slave and unexpectedly everything is working fine: firewall is accepting connections and forwarding traffic, for example if I try to SSH: ~# ssh -l root 10.10.10.100 [root@fw-02 root]# ifconfig | grep vhid carp: BACKUP carpdev vlan100 vhid 10 advbase 1 advskew 10 I’ve asked provider to change BGP configuration and everything now is stetted up correctly, now, the question is: Is the carp slave accepting and forwarding connections by design or is it un “unintended" feature? thank you for your time! keep rock on! Luca