Bikeshedding, and inject chaos! Mon, 26 Jul 1997 05:00:00 GMT - 2^756839

home | blog | Teh Internet | guest blog |rants | political | projects | Gwen and Liam | Citadel patched | Tools | Scouts


- Careful Chrome users, this search box might be "Not secure"


16 December 2018, 6:03 UTCRIP Timothy C. May - December 2018

Without further ado : cyphernomicon.txt

[permalink]


11 December 2018, 12:43 UTCFirewalld - what is it?

Firewalld seems to be a way to "magic away" some of the manual configuration iptables rules of old.
Here are the main points that I have found:
This is for the "zones" and magic pre-configuration https://fedoraproject.org/wiki/Firewalld?rd=FirewallD
This is for the more granular rules https://fedoraproject.org/wiki/Features/FirewalldRichLanguage



So, it would seem there are a set of "zones" that per-configure the traffic assumptions...
I have repeated them here, so I have a snapshot should that link go away:
drop: Any incoming network packets are dropped, there is no reply. Only outgoing network connections are possible.

block: Any incoming network connections are rejected with an icmp-host-prohibited message for IPv4
and icmp6-adm-prohibited for IPv6. Only network connections initiated within this system are possible.

public: For use in public areas. You do not trust the other computers on networks to not harm your
computer. Only selected incoming connections are accepted.

external: For use on external networks with masquerading enabled especially for routers. You do not trust
the other computers on networks to not harm your computer. Only selected incoming connections are accepted.

dmz: For computers in your demilitarized zone that are publicly-accessible with limited access to your
internal network. Only selected incoming connections are accepted.

work: For use in work areas. You mostly trust the other computers on networks to not harm your computer. Only
selected incoming connections are accepted.

home: For use in home areas. You mostly trust the other computers on networks to not harm your computer. Only
selected incoming connections are accepted.

internal: For use on internal networks. You mostly trust the other computers on the networks to not harm your
computer. Only selected incoming connections are accepted.

trusted: All network connections are accepted. 

So, rather than setting some defaults as you would with iptables, you just set the default zone.
The choice of the zone depends on how locked down outbound and inbound traffic needs to be.
It looks like it may interact with network-manager (should you be using that), to set the default zone.
Zones can be filled with services, ports, and protocols using the easy rules from that first link.
firewall-cmd sets them up. The services are not from /etc/services, but rather xml files in its config.
You need to define your own should they not exist for the many services that are not in the defaults.
For the harder work, you need to use the "Rich Language" bit. Looks pretty much like iptables or ip6tables.
If you don't use the --permanent flag to firewall-cmd, your added rule won't survive a reboot / reload, but they
be applied immediately.

So, if you want them to stick, do use the --permanent flag, but with a follow up:
firewall-cmd --reload


So, for example, to add rules to the default zone (public) -
- first make sure it is installed:
apt install firewalld
- make sure it is running (and running at boot):
systemctl enable firewalld
systemctl start firewalld
firewall-cmd --state
- now check for what is what:
firewall-cmd --list-all-zones
-Now to restrict things in the default (public) zone:
firewall-cmd --add-rich-rule='rule family="ipv4" service name="ssh" source address="your.ip.add.ress" accept' --permanent
- do the same for ipv6, and remove the defaults (have a back way in!):
firewall-cmd --zone=public --remove-service=ssh --permanent
firewall-cmd --reload

So you can see how to restrict some of the defaults by adding a "rich-rule", and removing the default allow access.
Don't forget to check the other zones and rules that are in by default, so you can tweak the zone that most closely
matches the level of blocking for your use case.
You might not find a zone that matches what you want to do, so you might need to make one, and tweak it.
To put things back:
# put back the blanket allow from the default public zone, and reload the saved rule:
firewall-cmd --zone=public --add-service=ssh --permanent
firewall-cmd --reload
# note, the more restrictive rule is still in there, but the allow all ssh overrides it, it would seem.  Not sure about order.
# To remove it:
firewall-cmd --zone=public --remove-rich-rule='rule family="ipv4" service name="ssh" source address="your.ip.add.ress" accept' --permanent
# and of course, reload to make the saved rules the default you are currently running:
firewall-cmd --reload
# and recheck:
firewall-cmd --list-all-zones

[permalink]


5 December 2018, 15:05 UTCPolicyKit - uid's > max_int allows unprivileged user to run systemctl commands.

Seems that unprivileged users with a uid > int will hold will be allowed to run anything.
https://gitlab.freedesktop.org/polkit/polkit/issues/74
You might want to check your uid's!
Should not happen by default, but there might be buggy software out there.

[permalink]


30 November 2018, 3:35 UTCOld Sonicwall - nogo ssh?

Are you getting the following error when trying to ssh to an ancient Sonicwall?

ssh_dispatch_run_fatal: Connection to ip.of.sonic.wall port 22: DH GEX group out of range

Give this a try:
ssh -l admin -o KexAlgorithms=diffie-hellman-group1-sha1 -oHostKeyAlgorithms=+ssh-rsa ip.of.sonic.wall

[permalink]


27 November 2018, 20:33 UTCBracketed paste mode \e[200~ (and) \e[201~ (or) 30 7E ... 31 7E (or) ~0 ... 1~

Middle chord not giving you what you expect when pasting?
Check to make sure some misbehaving program did not get your term in to bracketed paste mode.



More here: https://cirw.in/blog/bracketed-paste

In short, put junk in your cut and paste to save yourself from yourself.
To fix in a term, try reset.
Seems to happen quite a bit for me with Ubuntu 18.04 sessions (after cut and paste in that session - especially with VIM 8).
Gotta love progress. Thanks for the extra protection Ubuntu package managers. Please, screw up the
local terminal session with the stuff going on the remote session, so further cut 'n paste stops working!

Can make you think you lost the ability to middle chord paste for passwords.

Might be more to this than I thought: https://github.com/vim/vim/pull/3579

You might want to consider trying: bind 'set enable-bracketed-paste off'
If that works, chuck it in your inputrc (local or globally) depends on who shares your computer :-)

A quick way to test your term is to issue:
To turn it on;
printf '\e[?2004h'
To turn it off:
printf '\e[?2004l'

[permalink]


28 September 2018, 19:31 UTCAnybody seeing a pattern here? - SYN flood spoofing

So far, I have had the following IP's become what I assume is the brunt end of a spoofed SYN flood attack:

139.99.118.123 <- observed from a server where I could not block - lasted almost 4 hours!
45.195.133.8
149.56.180.254

Not sure what the connection is, but if someone knows, feel free to let me know.
Not sure what to make of it yet.

Update Oct 1 2018
The spoofing continues.
Seems to now include some Cloudflare, Google User Content, and random other targets.
The rotating behavior is new as well.
Much of the hate seems directed at:
104.27.154.184 - with other hosts in rotation (off and then on again short burst attacks).
35.229.174.32 - seems to be in second place for the disdain.
others... (the burst ones that seem only to be attacked from 1 to 5 minutes at a shot over a 20 to 40 minute interval)
23.247.6.249
35.201.183.114
35.229.174.32
103.37.233.28
103.239.30.128
103.37.233.28
103.49.209.135
103.74.194.188
103.91.58.12
134.175.181.91
149.56.154.192
149.56.154.193
149.56.154.194
149.56.154.195
149.56.180.252
149.56.180.252
149.56.180.253
149.56.180.255
154.85.11.21
167.114.41.148
167.114.41.149
167.114.41.150
167.114.41.150
198.44.230.98
203.205.158.12
203.205.158.22
203.205.158.24
203.205.158.25
203.205.158.44

[permalink]


14 September 2018, 16:48 UTCUbuntu 18.04.1 - Libvirt/KVM/Qemu setup with Wok/Kimchi

Here is what I did to get things working...
Big thanks to github user aluvare for his patch work here:
https://github.com/kimchi-project/kimchi/issues/1242
As always, links to needed bits included here in case the sources go away.

Install Ubuntu 18.04.1 x64 server on a computer with a processor that has AMD-V or Intel VT-x extensions (and can be enabled via the bios).

Add packages (see virt-packages.sh)
apt install qemu-kvm libvirt-clients libvirt-daemon-system bridge-utils virt-manager

Modify the networking to use as a bridge interface (assuming you want bridge networking to your local lan):
bridge version changed in network config:
/etc/netplan/01-netcfg.yaml

Grab the debs:
ginger-base.noarch.deb - not needed if you won't be controlling the host from the interface.
kimchi-2.5.0-0.noarch.deb
wok-2.5.0-0.noarch.deb

Patch the kimchi-2.5.0-0.noarch.deb to get a patched version to work with the replaced Python PIL with Python Imaging (thanks again aluvare!)
- see fixdeb.sh

Sprinkle in installs for dependent packages:
- see install-kimchi.sh

Hopefully get a wonderful interface at:
https://host.ip.addr:8001
- might need services to be restarted...

And here are the files:
virt-packages.sh
01-netcfg.yaml-bridgeversion
ginger-base.noarch.deb
kimchi-2.5.0-0.noarch.deb
wok-2.5.0-0.noarch.deb
install-kimchi.sh

[permalink]


23 August 2018, 21:04 UTCOk, now disable SMT / Hyper-threading? This is getting old.

At least that seems to be what Theo de Raadt says
Link to list here: https://marc.info/?l=openbsd-tech&m=153504937925732&w=2
and of course, if that should break, cut and paste as always:

List:       openbsd-tech
Subject:    Disable SMT/Hyperthreading in all Intel BIOSes
From:       Theo de Raadt <deraadt () openbsd ! org>
Date:       2018-08-23 18:35:22
Message-ID: 87827.1535049322 () cvs ! openbsd ! org

Two recently disclosed hardware bugs affected Intel cpus:

	 - TLBleed

	 - T1TF (the name "Foreshadow" refers to 1 of 3 aspects of this
	         bug, more aspects are surely on the way)

Solving these bugs requires new cpu microcode, a coding workaround,
*AND* the disabling of SMT / Hyperthreading.

SMT is fundamentally broken because it shares resources between the two
cpu instances and those shared resources lack security differentiators.
Some of these side channel attacks aren't trivial, but we can expect
most of them to eventually work and leak kernel or cross-VM memory in
common usage circumstances, even such as javascript directly in a
browser.

There will be more hardware bugs and artifacts disclosed.  Due to the
way SMT interacts with speculative execution on Intel cpus, I expect SMT
to exacerbate most of the future problems.

A few months back, I urged people to disable hyperthreading on all
Intel cpus.  I need to repeat that:

    DISABLE HYPERTHREADING ON ALL YOUR INTEL MACHINES IN THE BIOS.

Also, update your BIOS firmware, if you can.

OpenBSD -current (and therefore 6.4) will not use hyperthreading if it
is enabled, and will update the cpu microcode if possible.

But what about 6.2 and 6.3?

The situation is very complex, continually evolving, and is taking too
much manpower away from other tasks.  Furthermore, Intel isn't telling
us what is coming next, and are doing a terrible job by not publically
documenting what operating systems must do to resolve the problems.  We
are having to do research by reading other operating systems.  There is
no time left to backport the changes -- we will not be issuing a
complete set of errata and syspatches against 6.2 and 6.3 because it is
turning into a distraction.

Rather than working on every required patch for 6.2/6.3, we will
re-focus manpower and make sure 6.4 contains the best solutions
possible.

So please try take responsibility for your own machines: Disable SMT in
the BIOS menu, and upgrade your BIOS if you can.

I'm going to spend my money at a more trustworthy vendor in the future.

[permalink]


20 August 2018, 20:53 UTCUh, yeah, good one Microsoft: Auto updating AD Sync, and wow....

Directory_Synchronization The program stopped because an alternate diskette was not inserted.

Stop! Don't copy that floppy!

[permalink]


6 August 2018, 20:02 UTCGet ready for the SegmentSmack and FragmentSmack TCP vulnerabilities.

Follow along here: https://people.canonical.com/~ubuntu-security/cve/2018/CVE-2018-5390.html
More here: https://www.kb.cert.org/vuls/id/962459
Very brief bit from kb.cert.org -

Linux kernel versions 4.9+ can be forced to make very expensive calls to tcp_collapse_ofo_queue()
and tcp_prune_ofo_queue() for every incoming packet which can lead to a denial of service.
An attacker can induce a denial of service condition by sending specially modified packets within
ongoing TCP sessions. Maintaining the denial of service condition requires continuous two-way
TCP sessions to a reachable open port. Thus, the attacks cannot be performed using spoofed IP addresses.

https://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git/commit/?id=1a4f14bab1868b443f0dd3c55b689a478f82e72e

[permalink]



31 July 2018, 22:19 UTCO Superman - Laurie Anderson
26 July 2018, 16:41 UTCBroken, but just wait! - High CPU usage issue in Azure AD Connect Health for Sync - update - 8/16/18
11 July 2018, 16:50 UTCBeginning of the end
6 July 2018, 5:24 UTCDuff's device
21 June 2018, 20:33 UTCosquery - extensions
16 June 2018, 4:54 UTCTariffs, what can we make of them.
11 June 2018, 4:50 UTCDigital vs analog world
5 June 2018, 15:50 UTCMore Backups... WindowsImageBackup to a share.
4 June 2018, 18:31 UTCNow that Github is on the dark side, here is how to back up your new Gitlab instance :-)
31 May 2018, 19:37 UTCCheck your SSL at the door, and keep your POODLE inside.
30 May 2018, 5:09 UTCDon't give up!
8 May 2018, 15:08 UTCVery Magic! VIM needs hand holding for some sed replacments:
4 May 2018, 4:56 UTCYea! Amateur Radio gets a mention in a scientific paper!
2 May 2018, 3:53 UTCbell labs, xerox parc, (mitre?)
18 April 2018, 19:57 UTCTrusov Ilya Igorevych
29 March 2018, 21:11 UTCDrupalgeddon2
5 March 2018, 17:40 UTCMicrosoft - you don't correctly run MTA's either.
29 January 2018, 14:32 UTCThe most current Microsoft advice on configuration documentation:
25 January 2018, 17:10 UTCApple calls it (mostly) quits on the Server App...
20 January 2018, 4:00 UTCI wonder...

All older entries




[atom feed]  
[æ]